Buying Signals: An Evidence-Led B2B Triage System

A buying signal is only useful if you keep three things separate: the event you observed, the hypothesis you drew from it, and the action you took because of it. Teams that blur those layers end up arguing about whether "they're evaluating vendors" is true, when the only thing anyone actually observed was a job posting for a RevOps analyst. Buying signals work best when they are treated as evidence in a triage system, not as verdicts.

This article lays out that triage system: a taxonomy of signal types, a fact/inference/action ledger, a fit-first screen, and expiry windows so stale events stop masquerading as live opportunities.

Two families of signals, different evidence strength

It helps to sort B2B signals into two broad families, and they should not be scored the same way.

Event signals are observable changes at a company: a funding round closed, a hiring spike in a relevant function, a technology added or removed from the stack, a leadership change, an office opening. These are auditable observations: you can point to the announcement, the job posting, the detection record. What they mean is still a hypothesis, and detection methods carry their own error rates (a job ad proves a role was advertised, not that a buildout exists), but the observation itself can be checked.

Conversation cues are things a person said or did in direct interaction: a question about migration timelines on a call, a reply asking for security documentation, a demo request. These are stronger evidence of interest but weaker evidence of organizational readiness. One curious individual is not a buying committee.

Behavioral intent data sits between the two. As Demandbase's explanation of intent data notes, it describes behavior that may indicate interest, and fit, source methodology and timing deserve separate evaluation rather than a single blended score (Demandbase). That separation is the core of the triage system below.

The fact, inference, action ledger

Every signal that enters your pipeline should be recorded in three explicit fields. The structure borrows its spirit from the W3C provenance model, which distinguishes the entity, the activity that produced it, and the agent responsible (W3C PROV-O). Our ledger is an illustrative implementation of that idea, not a standards certification.

Three rules keep the ledger honest:

1. Facts carry provenance. Source, capture date, and method. If you cannot say where a fact came from, it is not a fact yet. Recording lineage this way is the practical version of data provenance for go-to-market work.
2. Inferences carry confidence and a kill condition. A hypothesis without a way to be wrong is just optimism with a timestamp.
3. Actions reference the inference they test. When the deal review asks why an account was worked, the answer traces back through the ledger instead of relying on someone's memory.

Screen for fit before you react

A signal tells you something changed. It does not tell you the account belongs in your market. Run the fit screen before the signal triage, not after, because signal enthusiasm is exactly the force that tempts teams to stretch their ICP.

A minimal fit screen checks four gates. All are pass/fail before any signal weighting applies:

• Segment gate: industry, size band and geography match the ICP definition.
• Stack gate: no disqualifying technology (for example, a locked-in competitor with a fresh multi-year contract, where you can verify it).
• Structural gate: the company can actually buy, meaning a relevant function exists or is being built.
• Data gate: you have or can obtain verified records for the people you would contact. Enrichment coverage matters here; an account you cannot reach cleanly is operationally not in market for you yet. This is where waterfall data enrichment earns its place, filling the gaps a single source leaves.

Accounts that fail the screen get logged and suppressed, not worked. The signal is still recorded, because a failed gate today (no relevant function exists) can flip later (they just hired a head of that function), and that flip is itself a signal.

Expiry windows: signals age at different rates

Treating a six-month-old funding announcement the same as one from last week is a quiet way to burn outreach credibility. Set explicit expiry windows per signal type. The table below is an illustrative internal policy, not a universal default; calibrate against your own sales cycle and revisit quarterly.

Expired signals do not vanish. They downgrade to background context on the account record, which is still useful for personalization later, and a standing signal watch can resurface the account if a fresh event lands.

Worked example (hypothetical)

Illustrative example, not a real company. Suppose a mid-market logistics software firm appears in your monitoring on June 1 with two events: a Series B announced May 25, and three posted roles for integrations engineers.

Fit screen: segment gate passes (450 employees, target vertical, target geography). Stack gate passes (no verified blocker). Structural gate passes (an operations function exists). Data gate: enrichment finds verified records for two of the four target roles, so the gate passes with a note to fill the gap.

Ledger entries:

• Fact 1: Series B announced May 25, source: press release, captured June 1. Expiry under the illustrative policy: 120 days, so September 22.
• Fact 2: three integrations-engineer postings live May 20 to June 1, source: careers crawl. Expiry: 60 days, so July 19.
• Inference: "Post-raise, they are scaling integrations capacity; likely evaluating data-infrastructure tooling this quarter. Confidence: medium, supported by two corroborating events; note the hiring push is likely downstream of the raise, so treat them as related rather than fully independent." Kill condition: postings withdrawn or the function outsourced.
• Action: open a conversation with the head of operations referencing the integrations buildout, not the funding amount. Route the account into the appropriate sequence and log the inference ID against the activity.

Note the arithmetic on the combined window: the account is highest priority until July 19, when the hiring signal expires, then medium priority until September 22 on funding alone. Two overlapping facts justified a medium-confidence inference; either fact alone would have rated low.

Tradeoffs and failure handling

The system adds friction. Logging three fields per signal is slower than forwarding a news alert to a Slack channel. The tradeoff pays off at review time, when you can measure which signal types actually preceded pipeline instead of debating anecdotes. Feeding ledger outcomes back into lead scoring is how the weights improve.

Common failure: inference laundering. An inference gets copied into a CRM note without its confidence label, then a later reader treats it as fact. Guard against it by prefixing every inference field with "Hypothesis:" so the framing travels with the text.

Common failure: expiry theater. Windows exist on paper but nobody suppresses expired signals, so reps keep working stale events. The fix is operational: expiry should change the account's routing automatically in whatever system holds the queue, and your prospecting data infrastructure should carry the expiry date as a field, not a comment.

Common failure: single-signal overconfidence. One event, one inference, maximum priority. Require corroboration for high confidence: two independent facts, or one fact plus a conversation cue.

FAQs

Are buying signals the same as intent data? Intent data is one class of buying signal; it describes behavior that may indicate interest, and it can come from third-party sources. Buying signals also include verifiable company events and direct conversation cues. Each class has different evidence strength, so triage them separately rather than blending everything into one score.

Why screen for fit before reacting to a signal? Because a strong signal at a poor-fit account produces a poor-fit deal. The fit screen is cheap and pass/fail; running it first protects outreach capacity from signal enthusiasm.

How long does a buying signal stay actionable? It varies by type. Funding relevance stretches over months while conversation cues decay in days. Set expiry windows as explicit team policy, wire them into routing, and recalibrate quarterly against what actually converted.

Put the ledger to work

If your team reacts to signals without recording the fact, the inference and the kill condition, start with one signal type this week, hiring or funding, and run it through the ledger. When you want the discovery, enrichment and monitoring layers handled by autonomous agents that deliver structured records into your existing systems, start with AstroFabric.

Sources

• Demandbase: What is intent data?
• W3C PROV-O: The PROV Ontology