What is signal-based selling?
Signal-based selling is go-to-market triggered by detected changes in an account’s state rather than by fixed cadences or static lists. A signal is the observation that something is now different — not a positive indicator, and not a data product you buy. The practice depends on a system that holds a current model of each account, which is why most implementations stall at purchasing intent data and never reach the part that changes outcomes.
The idea, and the thing it replaces
Conventional go-to-market is scheduled. A list is built, a sequence is loaded, and contact happens according to a cadence chosen by an operator — five touches over fourteen days — with no relationship to anything happening at the receiving company. Timing is determined by the seller's calendar.
Signal-based selling inverts that. Contact is triggered by something changing at the buyer. The cadence is a consequence of the market, not an input to it.
This is not a messaging technique. It is a claim about where the leverage sits: that when you engage matters more than what you say, and that reliably knowing when requires infrastructure most companies have not built.
What a signal actually is
A signal is a detected change in state. Three words in that sentence do work:
- Detected — the system noticed. Not a rep who happened to see a LinkedIn post.
- Change — a difference from what was true before. This requires memory of what was true before.
- State — a property of the account, inferred from evidence, rather than a field someone typed.
Note what is absent: any claim that a signal is good news. A champion leaving is a signal. A renewal going quiet is a signal. Signals are not opportunities; they are observations, and treating them as synonyms is how teams end up sequencing everything that moves.
The industry uses "signal" and "intent" interchangeably. They are not the same. Intent is a vendor's inference about buying likelihood, sold as a product. A signal is your system observing that something is now different. You can have the first and still have no capacity for the second.
Why most implementations stall
The common sequence: a team buys an intent product, wires the feed into the CRM, watches reps ignore it, and concludes the category is overhyped. The category is not the problem. The system received a stream of observations and had nowhere to put them.
Four layers have to exist for a signal to become revenue:
- State — a current model of each account that new evidence updates.
- Detection — comparison against prior state, so change is visible rather than overwritten.
- Decision — a stated rule for which changes warrant action, by whom, how fast.
- Feedback — measurement of whether the action caused anything, so the rules improve.
Buying a data feed adds input to the first layer. It does not create any of the other three. This is why the same purchase produces transformation at one company and shelfware at another — the difference was the architecture that was already there.
Why the CRM cannot do this
A CRM stores current values. When a field updates, the previous value is replaced. That is correct behaviour for a system of record and fatal for signal detection, because the change — the only thing you actually wanted — exists for an instant and is then gone.
Signal detection needs somewhere that retains history and can compare. That is an architectural requirement, not a tooling preference, and it is the point at which signal-based selling stops being a sales methodology and becomes a systems problem. More on that in why your CRM doesn't reflect reality.
What good looks like
A working implementation can answer four questions without a meeting: what changed, when it changed, what the system decided to do about it, and whether that worked. Every one of those is answerable from the system rather than from someone's recollection.
Establishing which of those four your architecture can currently answer is the middle of the GTM Architecture Audit — layers three through six, evaluated in order, because a decision layer built on absent detection has nothing to decide about.
Is signal-based selling the same as buying intent data?
No, and conflating the two is the most common reason implementations fail. Intent data is one possible input. Signal-based selling is an architecture: something has to hold a model of what is currently true about each account, notice when that changes, decide whether the change warrants action, and find out whether the action worked. Buying a data feed supplies input to a system that, in most companies, does not exist yet.
What counts as a signal?
Any observable change in an account’s state: a relevant hire or departure, a shift in job postings, a technology added or removed, a funding event, a pricing-page visit from a new department, a champion changing employer, a support pattern, a product-usage cliff. What makes it a signal is not the source but that it represents a difference from what was previously true.
Do we need a data warehouse first?
Usually yes in some form, because a signal is a comparison and a comparison needs history. A CRM records the current value of a field and overwrites the previous one, which means the change is destroyed at the moment it happens. You do not necessarily need a large warehouse project, but you do need somewhere that retains prior state.
How is this different from lead scoring?
A score is a single number summarising an account’s attractiveness. A signal is a specific, dated, explainable observation that something changed. A score tells a rep an account is a 78 and offers no reason; a signal tells them what happened, when, and therefore what to say. Scores also tend to be static where signals are inherently temporal.