Signal-Based Outreach: A Playbook for Turning Buying Signals Into Meetings

What actually counts as a buying signal

I'm Hlib Storchak. I build outbound systems for B2B founders and sales teams, and enough of that work has run through signal-based programs by now, part of the 2000+ meetings booked for B2B clients along the way, that I have a clear view on what actually earns the label versus what is a static list with a new name on it.

Not every data point is a signal. A useful framework I found from Growleads, an agency that publishes its own signal-based methodology, sets a clean three-part test: a real signal has to be observable from outside the account, temporal, meaning it happens at a specific time with an actionable window rather than being a permanent trait, and predictive, meaning historical evidence actually shows it precedes a purchase decision. Source: Growleads, Signal-Based Outbound: The Complete B2B Guide.

Company size is not a signal by that test. It is observable, but it is not temporal and it does not predict timing on its own. A company posting a job for the role your product replaces is a signal. It is observable, it happened this week, and it plausibly predicts that a buying process is about to start. That distinction matters more than most teams treat it, because it is what separates a genuinely signal-based program from a static list that just added a few enrichment columns.

Where signals actually come from

Apollo's own framework for what it calls signal-based selling splits signals into three sources, which is a useful lens for figuring out what you already have versus what you would need to buy. First-party signals come from your own systems: website behavior, product usage, CRM engagement history, support ticket trends. Second-party signals come from sales intelligence databases: job changes, technology installs, headcount growth. Third-party signals come from external intent providers tracking research behavior across the wider web, the category of tool that tells you an account is reading comparison pages for something like what you sell. Source: Apollo, Signal-Based Selling.

The practical takeaway: start with first-party signals, they are free, you already own the data, and they are usually the most predictive because they are your own prospects behaving, not a third party's model guessing at intent. Second and third-party signals are worth adding once the first-party layer is actually wired into your outbound process, not before.

Seven signal types worth watching

Growleads' guide names seven categories worth building a watch-list around. I have used this as a starting checklist with clients rather than a rule that every category applies to every ICP.

Website-visitor identification tools, RB2B and Leadfeeder being two of the better-known ones, sit inside the "direct inquiry" and "content engagement" rows above: they de-anonymize who is on your site so a pricing-page visit becomes a named account and, on some tools, a named person rather than an anonymous session. That is one input into the framework, not the whole framework by itself.

The signal buffet mistake

The most common failure mode I see when a team says "we're doing signal-based outbound now" is that they turned on every signal their tool offers at once. Growleads calls this the signal buffet, and its guidance is blunt: "Pick 3-5 signals per ICP segment. No more. Test them for one full quarter. Measure signal-to-meeting rate for each signal individually. Cut the ones below 3%." Activating every available signal produces the same noise as volume outreach, just with a fancier dashboard on top of it.

The fix is not a bigger signal list, it is a shorter one that you can actually act on inside the response window each signal needs. A funding-round signal that sits in a queue for two weeks before anyone messages the account is not a signal-based program, it is a slower version of the static list you already had.

Step 1: Select 3 to 5 signals per segment

For each ICP segment, pick the signals with the clearest story for why they predict a buying window, not the ones your tool happens to surface most often. A new VP of Revenue is a strong signal for a sales-tooling company and a weak one for a compliance product. Write down, in one sentence per signal, why it should predict timing for that specific segment. If you cannot write that sentence, it is not one of your 3 to 5.

Step 2: Score them

Not every instance of a chosen signal deserves the same urgency. Weight each hit by how closely the account matches your ICP and by how fresh the signal is, since a job change from six weeks ago is a weaker trigger than one from six days ago. Set a threshold below which a hit gets logged but does not trigger outreach yet, so the team is not chasing every marginal ping.

Step 3: Route to the right channel and sequence

A funding-round signal and a pricing-page visit deserve different openings and, often, different channels entirely. A pricing-page visit is close to a direct-inquiry signal, a fast, short, low-friction email or a same-day call attempt usually beats a long sequence. A job-change or funding signal is earlier in the buying window and can support a slightly longer, more educational first touch. Build this routing logic once, as rules, rather than leaving it to whichever rep happens to see the alert first.

Step 4: Execute inside the window

This is the step most signal-based programs quietly skip. Apollo's own framework for this puts a number on it: its stated target for top teams is a "sub-30-minute response time on high-priority signals through automated routing and playbook triggers." Whether your realistic number is 30 minutes or same-day, the principle holds, a signal has a shelf life, and the whole premise of the approach collapses if the alert sits in a shared inbox until Friday.

Step 5: Measure and cut what doesn't earn its slot

Track signal-to-meeting rate per signal, not just an aggregate reply rate for the whole program. A signal that produces plenty of replies but few actual meetings is either being routed to the wrong sequence or was never as predictive as it looked. Growleads' own cutoff, drop anything below roughly a 3% signal-to-meeting rate, is a reasonable starting bar. Review it quarterly and replace the weakest signal in your 3 to 5 with a new candidate rather than letting the list quietly grow to eight.

What the reply-rate numbers actually say

Here is where I want to slow down, because this is the part of "signal-based outreach" that gets oversold the hardest. The headline claim circulating across a lot of 2026 outbound content is that signal-based campaigns get 15 to 25% reply rates against a roughly 3.43% average for cold email generally, a claim traced in several places back to Instantly's own 2026 benchmark report as the baseline figure. Source: Instantly, 2026 Cold Email Benchmark Report.

That 15 to 25% number is real as a best-case figure, but it is not what a typical, full signal-based program actually produces once you look past the headline. Growleads, working from over 200 of its own B2B client campaigns run between 2023 and 2026, publishes a more granular breakdown that I think is a far more honest picture of the range:

Growleads is direct about the gap between that data and what vendors pitch: "Vendors selling signal-based outbound tools and services sometimes claim 10x improvements over traditional cold outbound. This is misleading." Its read is that vendors are averaging their best-performing client campaigns, often in categories where intent-data coverage happens to be strong, over short measurement windows, and calling that the typical result. The actual, defensible lift its own data supports is roughly 2 to 4x on reply rate, not 10x, and even that range still varies a lot by how disciplined the select-score-route-execute loop above actually is.

I would treat the 15 to 25% headline as a real ceiling some campaigns hit, and the 4 to 10% full-program figure as the number to actually plan around.

A cost model, built on stated assumptions

Reply rate alone does not tell you what a signal-based program is worth. What matters is contacts needed per qualified meeting, and what each of those contacts costs you to reach. Here is the maths, built entirely from the ranges above, with every input labeled as an assumption you should replace with your own numbers.

Formula: contacts needed per meeting = 1 ÷ (reply rate × qualified-meeting share). Applying the low and high end of each row above:

Now add cost. Assume $1 per contact all-in for list building and standard email enrichment on a volume campaign, and a higher $3 per contact once you layer in intent-data and signal-tooling costs for a full signal-based program, since that tooling carries a real premium per contact reached. These two figures are illustrative starting points, swap in whatever your own data and tooling stack actually costs you per contact.

At those assumptions: volume-based outbound costs roughly $200 to $1,333 per qualified meeting. Full signal-based costs roughly $60 to $213 per meeting, even after paying the tooling premium, because you need so many fewer contacts to get there. That is a wide range on both sides, and your real numbers may land anywhere in it, but it is the same direction Growleads' own client data points to when it describes signal-based programs producing a "30-40% lower cost per qualified meeting" versus volume benchmarks, without me having to take that single number on faith.

What I actually run for clients

The setup I run for clients almost always starts with first-party signals, since they are free and usually the most predictive, before I ever recommend paying for a third-party intent feed. The mistake I see most often when I take over an account that already calls itself "signal-based" is exactly the buffet problem above, six or seven signals turned on because the tool made it one click to enable, with nobody able to tell me which of them are actually earning their slot. The fix is almost always subtraction: cut to 3 to 5, put a real owner and a real response-time target on each one, and only then decide whether a paid third-party signal is worth adding.

Mistakes that quietly kill a signal-based program

Beyond the buffet mistake, the other failure modes I see repeatedly: treating a signal hit as a reason to send the same generic template faster, rather than a reason to write a genuinely different opening line for that trigger; letting alerts sit in a shared inbox with no owner and no SLA, which kills the entire "temporal" premise the signal was chosen for; and reporting on raw signal volume instead of signal-to-meeting rate, so a noisy, low-value signal keeps its seat on the dashboard because it looks busy rather than because it books meetings.

FAQ