Open the signal channel your team set up last quarter. It probably has forty alerts from yesterday: a Series B here, a new VP of Sales there, a company that posted twelve engineering roles, another that visited your pricing page twice. Now count how many of those alerts a rep acted on. On most teams the honest number is a handful, and the rest scrolled past. The feed is full and the calendar is not.
The reps are not lazy and the data is not wrong. Every one of those events happened. The problem is that a signal feed answers one question, what happened at this company, and leaves the rep to answer the one that matters: why does that event mean this account needs what we sell, right now? When that second answer is missing, the rep has a list of events instead of a list of reasons, and a list of events is just a longer list.
This is a guide to signal based selling that starts where most guides stop. Signal types are easy to list. The work that decides whether the program pays is mapping each signal to a problem your product solves before it ever reaches a rep, and throwing away the signals that do not map.
Why signal feeds turn into noise
Most writing on signal based selling follows the same shape: a definition, a list of signal types, a list of tools. Cognism's guide is a good example. It names job changes, funding rounds, website intent, hiring and technology installs, and recommends building a play for each one. That is useful as a catalogue. What it does not do, and what almost none of these guides do, is ask which of those signals are noise for your particular product.
That omission is where programs break. A funding round fires the same alert for the payroll vendor, the security vendor, the recruiting agency and the sales training firm. Each of them gets the same event and writes the same opener: "Congrats on the raise." The buyer receives that email from a dozen sellers in a week, and none of them said anything about the buyer's actual situation.
Meanwhile the rep's time is the scarce input. Salesforce's State of Sales research, a survey of 7,775 sales professionals, found that reps spend just 28% of their week actually selling. A feed that hands a rep forty unranked events a day does not give them more selling time. It gives them a triage job on top of the admin they already have, and triage is the first thing a busy rep skips.
So the failure is not too few signals. It is signals that arrive without a reason attached, in a volume nobody can sort by hand.
A signal only means something relative to what you sell
The same event is a strong reason for one seller and noise for another. You can see it by holding the events still and changing the product.
| Event at the account | Sales training vendor | Data warehouse vendor | Contract management vendor |
|---|---|---|---|
| Hiring 15 SDRs this quarter | Strong: a ramp problem is about to land on the enablement team | Noise | Weak at best |
| New CFO from a public company | Weak | Medium: reporting standards usually tighten | Strong: contract visibility is a common first audit |
| Acquired a competitor | Medium: two sales teams, two methods | Strong: two data stacks to merge | Strong: an inherited pile of vendor and customer contracts |
| Raised a Series B | Depends on the hiring plan they announced | Depends on whether data roles are in it | Weak on its own |
Read down any column and the feed shrinks. Read across any row and you see why a shared alert channel cannot work for a company with more than one product, or for two companies buying the same signal data. The funding round row is the instructive one: on its own it is a reason for nobody. It only becomes a reason when it is joined to something the round is going to be spent on, which is a second piece of evidence the feed did not give you.
We made a similar argument about trigger events in trigger events in sales are generic until you add products. Signal based selling inherits the same problem at a larger scale, because the feeds are now automated and the volume is far higher than any trigger list a rep kept by hand.
Map each signal to a problem before it reaches a rep
The fix is to build the signal list backwards, starting from the product rather than from the data you can buy. It takes an afternoon per product and it is the most valuable afternoon in the program.
- Write down the problems your product solves. Not features. Problems a buyer would say out loud: "our contracts live in shared drives and we miss renewals," "new reps take seven months to ramp."
- For each problem, ask what would be visible from outside the company if it were present or getting worse. Missed renewals are invisible. A new procurement leader, an acquisition, or a job post for a contract administrator are visible.
- Turn each visible thing into a signal with a source. Job posts come from the careers page. Leadership changes come from press releases and LinkedIn. Acquisitions come from filings and news. Write the source next to the signal so the rep can check it.
- Mark everything left over as noise for this product. If a signal type does not map to a problem on your list, it does not go in the feed, however cheap it is to collect.
- Write one sentence per mapping that a rep could say on a call. "You are hiring fifteen SDRs this quarter, and the ramp for that many at once is usually where enablement teams get stretched." If you cannot write that sentence, the mapping is not real yet.
A worked example for the contract management vendor: the problem is "contracts from an acquisition are nobody's job." The visible evidence is an acquisition closed in the last two quarters plus no posted role for contract operations. The source is the press release and the careers page. The sentence: "You closed an acquisition in May and I do not see anyone hired to own their vendor contracts yet." That is a signal mapped to a problem. "Congrats on the acquisition" is not.
Most of the signals on a typical feed will not survive step four. That is the point. Fewer, product-specific signals beat a long generic feed every time a rep has to decide what to do at nine in the morning. For a broader look at which signal categories exist in the first place, see buying signals in sales and what intent data is and is not.
The reason test: what changed, where you saw it, when
Mapping decides which signal types are allowed into the feed. The reason test decides whether a specific account on a specific day is worth a call. It has three parts, and a name passes only when all three have an answer:
- What changed. A specific event at this account that connects to a problem on your list. "They are growing" fails. "They posted fifteen SDR roles since August" passes.
- Where you saw it. A source someone else could open: the careers page, the press release, the filing, the post. If the only source is "the tool flagged it," you cannot defend it on a call.
- When it happened. A date. Signals decay, and an acquisition from three years ago is history, not a reason.
No reason, no call. The account goes back on the list to be checked again, which is a perfectly good outcome. A test that only ever says "call" is not a test.
The timing part matters more than it used to. The 6sense 2024 Buyer Experience Report found that buyers are nearly 70% through their purchasing process before engaging with sellers, and that 81% already have a preferred vendor at first contact. If you reach an account after the shortlist is written, the best signal in the world only tells you that you were late. A dated reason lets the rep see whether there is still time to be on the list, and skip the account honestly when there is not.
You can run the test by hand on your own list today. Take the last twenty alerts in your channel, and for each one write the three answers in a spreadsheet. Count how many pass. Expect a minority to pass, and expect the ones that pass to be the ones reps already chose to work. The test is not telling you anything new about those accounts. It is telling you which of the rest they can stop looking at.
Where this breaks at scale
The method works by hand for a rep with fifty accounts. It breaks at a few hundred, for a plain reason: the reason test is research, and research per account takes time. Opening the careers page, reading the press release, checking the date and writing the sentence is ten to twenty minutes for one account and one product. Multiply it by a territory and by a product line and it is no longer something a rep does before lunch. This is the same gap described in our pre-call research checklist: the checklist is right, and nobody has time to run it on every name.
Teams usually respond in one of two ways. They keep the feed and accept the noise, which puts them back where they started. Or they hand the test to a score, which hides the reason inside a number. A rep who sees "intent score 87" still has to work out what to say, and the buyer still gets an opener with nothing specific in it. Our piece on how to score leads covers why a score is good at ranking and poor at explaining.
This is the part PitchSmart was built for. It researches every lead on your list against what you sell, runs the equivalent of the mapping above for each product, and returns a plan per lead: who to contact, what to pitch, why now, and what to say, with a source on every claim. A plan is allowed to say hold or skip, which is the reason test applied at the scale of the whole list rather than the top fifty names.
What to change this week
You do not need new tooling to start. You need a smaller feed and a stricter rule about what reaches a rep.
- Write the problem list per product. Five to eight problems, in the words a buyer would use.
- Map your current signal types to it. Turn off or reroute every signal type that maps to nothing. If two products share a feed, split it.
- Attach a source and a date to every alert. If your tooling cannot show where a signal came from, treat that signal as a hint to research, not a reason to call.
- Run the reason test on twenty alerts. Record the pass rate. It is your baseline for whether the changes above are working.
- Change the opener rule. No outreach goes out that does not state what changed at the account, in one sentence the rep could defend on a call.
Signal based selling is sound. Timing outreach to something that actually happened beats working a static list in alphabetical order. But the signal is only half of it. The other half is the reason that signal matters to what you sell, and until that half is written down for every account, your team does not have a signal program. It has a busier list.
