Field Manual · 14 min read

The Revenue Signal Field Manual

Most revenue signal content pitches one more platform. This is the operational layer underneath: what a first, second and third party signal actually is, how fast each one decays, and the routing logic that turns a signal into a response before it goes cold.

What a revenue signal actually is, and why ownership matters more than volume

A revenue signal is evidence a specific account is more likely to buy now than yesterday. Where it originates decides how much weight it deserves.

We defined the term in full in what a revenue signal actually is: any piece of evidence that a specific account has become more likely to buy right now. That post grouped signals by what kind of event they are, behavioural, organisational or external. This guide groups them a different way, by who owns the underlying data, because ownership is what decides how much a signal deserves to be trusted before anyone acts on it.

Signal is not a side topic in how we operate. It is the second of the five phases in our model, Foundation, Signal, Orchestration, Scale, Agentic, set out in full in the five phases of a real revenue engine. A business that has not built the plumbing to capture, classify and route a signal is still working the first phase, whatever the job titles in its CRM say about revenue operations.

Every signal a team ever acts on comes from exactly one of three places: your own systems, a partner's audience, or an aggregator watching the open web. Buyers are also giving fewer of these away in a conversation. Gartner's June 2025 sales survey found 61% now prefer a rep-free buying experience, which is exactly why the signals a business can read without a call have become so much of the available evidence.

First party signals: the highest fidelity data most teams already have and ignore

First party signals come from your own systems, pricing page visits, product usage, downloads. Highest trust, lowest reach, and usually already sitting unused in the CRM.

A first party signal is behaviour captured directly on something you own: a pricing page visit, a repeat return to a case study, a feature activated inside the product, a webinar registration, a support ticket that names a competitor. Nobody has to buy or licence this data. It already exists, inside the CRM, the product analytics tool, or the marketing automation platform.

It is also the signal type most likely to be sitting dead in a system nobody checks. We covered why in why most CRMs become graveyards: a field populated by a first party event is not the same thing as a field anyone acts on. The gap between the two is exactly what a proper audit surfaces first, which is why it is the opening move in the diagnosis is the deliverable.

The trade-off is reach. First party data only tells you about accounts already engaging with something you own. It says nothing about the much larger set of accounts researching your category before they have ever visited your site, which is where second and third party data earn their place.

Second party signals: a partner's audience becomes your intent data

Second party signals come from a partner's own first party data, most often review platforms, where a buyer's research on your category is shared back to you.

Second party data is someone else's first party data, shared or sold to you directly. In B2B, the clearest example is a review platform: when a buyer researches your category on G2, Capterra, Software Advice or GetApp, that platform's own first party behaviour becomes a signal it can pass on. On 3 June 2026, G2 said it had expanded its Buyer Intent product across all four of those platforms, describing the combined feed as delivering up to twice as many signals as before.

The trust level sits between first and third party. The behaviour is real and explicitly purchase oriented, someone comparing named vendors in your category, but it is one step removed from your own systems, so it earns the same scepticism you would apply to any vendor's own claim about its own product.

Vendors selling directly into this layer make their own claims about what a rep should do with the output, and those claims are worth reading critically rather than adopting wholesale, which is the point we make in what Salesforce told a room of marketers about agentic demand generation.

Third party signals: the widest coverage and the most noise

Third party signals aggregate research activity across thousands of publisher sites. Broadest coverage, weakest individual signal, and only useful once corroborated.

Third party intent data is aggregated across a large network of publisher sites that have nothing to do with you directly. Bombora is the most widely used example: its Company Surge product scores an account's topic level research activity from 0 to 100 each week, comparing the last three weeks of consumption against a rolling twelve week baseline. A score of 50 is average; Bombora's own documentation treats 60 and above as a statistically significant surge in interest.

This is the widest net available. It can surface an account researching your category before that account has visited your site, filled in a form, or engaged with a review platform. It is also the noisiest signal, because one employee reading one article does not mean the account is in a buying window, and the aggregation happens at domain level, not against a named buyer.

Treat a third party surge score as a reason to look, never as a reason to call. It earns a place on a list to check against first and second party signals for the same account, which is the acquisition half of the model we set out in the bowtie: why acquisition is half the story, and it is the input agentic scoring is best suited to triage in bulk, the case we make in self optimising revenue: what agentic actually means.

How fast each signal type goes cold

Decay speed depends on commitment, not on which party owns the signal. In our own operating framework, same day for a pricing visit, months for a relevant hire.

The industry rarely publishes decay windows, because they vary by category and by how a business defines being in market. The framework below is our own operating rule, built from running signal programmes across client engagements rather than from a published study. Treat it as a starting point to calibrate against your own closed-won data, not a fixed constant.

A stale signal is not a harmless leftover. It is what makes a forecast unreliable, because pipeline built on signals nobody re-qualified looks identical in the CRM to pipeline built yesterday. We cover the knock-on effect in the forecast you can defend.

Routing logic: getting a signal to the right owner before it cools

A signal needs a score, a named owner and a response deadline, logged automatically, or it stays a record instead of becoming something anyone acts on.

Scoring and routing are two separate jobs, and treating them as one is a common failure mode. Scoring decides whether a signal is worth acting on at all. Routing decides who acts on it, and by when. A high scoring signal sent to a shared inbox behaves exactly like a low scoring one: ignored.

Most of this can run through an orchestration layer without a person touching every signal, the argument in why 2026 is the year internal apps become the Control Room. What should not run unattended is the judgement call at the point of contact, deciding what to actually say to a specific buyer because of a signal, which is the boundary we set out in what you should never hand an agent, and why. Score and route with automation. Keep the conversation with a person.

Where a routed signal lands matters as much as the routing rule itself. A sales development function built on a fixed weekly cadence cannot absorb a signal that needs a same-day response, the gap we describe in from outsourced SDR to engineered cadence. Team structure has to match the decay window, not the other way round.

None of this replaces a person's judgement about the account. It removes the two failure points that kill most signal programmes before judgement gets a chance: nobody noticed, or nobody was clearly responsible. What AI inside the team actually looks like covers where the split between automated triage and human decision making actually sits, day to day.

How to build a signal stack without buying a platform first

Start with what you already have. Inventory first party events, classify by ownership, assign decay windows, then write routing rules before buying third party data.

Most teams buy a third party intent platform before they have finished using what is already free: their own first party data. The build order below gets the plumbing right before spending on coverage.

1. Inventory what you already capture. List every first party event currently logged: page visits, product events, downloads, form fills. Most of this already exists in the CRM or the analytics tool, unscored and unrouted.
2. Classify each event by ownership. Tag every signal source as first, second or third party. That single tag is what lets you weight a signal correctly later instead of averaging everything into one score.
3. Assign a decay window to each signal type. Use the table above as a starting point and calibrate it against your own closed-won data within a quarter.
4. Write routing rules before adding a scoring model. A named owner and a response deadline for the three or four signals that already fire most often will out-perform a sophisticated score with nowhere for the output to go.
5. Log every routed signal in the system of record, including what was done with it. This is the provenance layer most CRMs were never built to track, covered in making NetSuite the system of record.
6. Only then evaluate second and third party platforms. Buy coverage once the first party layer is scored, routed and logged, so new spend adds accounts you could not otherwise see rather than duplicating a problem you have not fixed yet.

The order is the point. Buying coverage before fixing routing is the pattern we describe in why strategy without execution never builds a revenue engine: more inputs into a process that already cannot act on the inputs it has.

Frequently asked questions

What is a revenue signal?

A revenue signal is any piece of evidence that a specific account is more likely to buy right now than it was yesterday, such as a pricing page visit, a relevant new hire, or a third party research spike on a related topic.

What is the difference between first, second and third party intent data?

First party data comes from your own systems and carries the highest trust. Second party data comes from a partner's audience, such as a review platform's buyer intent product. Third party data is aggregated across the open web by a provider such as Bombora, giving the widest coverage but the least reliable individual signal, and it should be corroborated with the other two before acting.

How long does a buying signal stay valid before it goes cold?

It depends on the signal. In our own operating framework, a high intent behavioural signal such as a pricing page visit is worth acting on the same working day and is cold within a week, while an organisational signal such as a relevant new hire holds value for two to three months.

Should a sales team automatically act on a third party intent score?

No. A third party score such as Bombora's Company Surge is a reason to check an account, not a reason to contact it. It should be corroborated against first or second party activity before a person reaches out.

What should never be automated in a signal routing workflow?

Scoring and routing a signal can run without a person touching every case. The judgement call at the point of contact, deciding what to actually say to a specific buyer because of that signal, should stay with a person rather than an agent.