Signal-to-Action Latency: The Metric Nobody Tracks
Signal-to-action latency is the elapsed time between a buying signal firing and a contact attempt landing. Most companies measure only the last hop — how fast a rep called after assignment — and miss the hours or days consumed by batch jobs, enrichment queues, and sync delays upstream of it.
- Measure the whole chain, not the last hop. Rep response time is usually the smallest component.
- Batch scheduling is where most latency hides — a nightly job adds a mean of twelve hours by itself.
- Targets differ by signal type. Behavioural signals decay in days; trigger events in weeks.
- Cutting latency is nearly always cheaper than improving message quality, and it compounds with it.
- It is the metric a GTM engineer uniquely controls, which makes it the right one to measure them on.
What it measures
Signal-to-action latency is the elapsed time from the moment a buying signal exists to the moment a relevant contact attempt lands with a human at the target account.
Most companies measure a much narrower thing — lead response time, meaning how quickly a rep acted after a record was assigned to them. That is the final hop, and it is usually the smallest part of the total. A pricing page visit that reaches a rep six hours after it happened has already lost most of its value regardless of how fast the rep then moves.
Where the delay actually hides
| Hop | Typical delay | Cause |
|---|---|---|
| Signal captured to signal available | 0–24 hours | Provider batch delivery or scheduled polling |
| Available to enriched | 0–12 hours | Nightly enrichment job scheduling |
| Enriched to scored | 0–4 hours | Scoring runs on a schedule, not on change |
| Scored to routed | 0–2 hours | Sync interval between systems |
| Routed to contacted | 1–30 hours | Rep availability and queue depth — the only hop most teams measure |
Add the midpoints and a typical unoptimised chain runs 20–40 hours. The rep hop is often under a third of it, which is why teams that push hard on response-time coaching see disappointing results — they are optimising the smallest term.
Realistic targets by signal type
Latency only matters relative to how fast the signal decays. Targets should be set against the decay window rather than as one universal number.
| Signal | Decay window | Latency target |
|---|---|---|
| Demo or contact request | Hours | Under 15 minutes |
| Pricing page visit | ~7 days | Under 4 hours |
| Multiple people from one domain | ~14 days | Same business day |
| Documentation or integration read | ~14 days | Under 24 hours |
| Hiring signal | 60–90 days | Under 5 days |
| Funding round | 90–180 days | Under 10 days |
The top row is where the largest measurable gains sit, and it is worth building a dedicated fast path for it. A demo request should bypass every batch process in the stack — the full signal taxonomy and decay behaviour is in buying signals.
How to cut it
- 01Instrument the whole chain first
Timestamp every hop: signal time, ingestion time, enrichment complete, score written, routed, first contact. Without per-hop timestamps you will optimise the hop you can already see, which is the wrong one.
- 02Move high-intent signals to event-driven
Webhooks rather than polling for the signals that decay in hours. Batch is fine for hiring and funding signals; it is fatal for a demo request.
- 03Pre-enrich the target list
The largest structural win. If your ICP accounts are already enriched and scored before any signal fires, the enrichment and scoring hops drop to zero and the chain collapses to routing plus response.
- 04Build a fast path for the top tier
One route that skips scoring, batching, and queueing for demo requests and pricing-page conversions from ICP-fit accounts. Everything else can take the normal path.
- 05Alert rather than assign for the highest tier
A task in a queue waits for someone to look. A notification to a named owner with context attached does not.
The third step deserves emphasis because it is counterintuitive: the cheapest way to reduce latency is to do the slow work before the signal arrives. Enriching your named target accounts on a schedule, independent of any signal, means the expensive hops are already complete when one fires.
Why it is worth the effort
Latency reduction is nearly always cheaper than the alternatives. Improving message quality requires research, testing, and iteration. Improving targeting requires data and analysis. Reducing latency is mostly scheduling configuration and routing rules — and it compounds with both of the others rather than substituting for them.
It is also the metric a GTM engineer uniquely controls. Reply rate depends on message and market; pipeline depends on sales execution. The elapsed time between a signal and a contact attempt is almost entirely a systems property, which makes it the right thing to hold the role accountable for.
Reporting it
- Median, not mean. A handful of records stuck in a failed job will distort the average and hide the typical case.
- Segmented by signal type, because the targets differ by an order of magnitude between a demo request and a funding round.
- With the 90th percentile alongside. The gap between median and p90 tells you whether you have a systemic delay or a broken edge case.
- Per hop, not just end to end, so the number points at what to fix rather than merely reporting that something is slow.
One caution: a falling median with a rising p90 usually means the fast path is working and everything outside it is degrading. That is a common outcome when a fast path is added without maintaining the standard route, and it is worth catching early rather than discovering when a mid-tier segment quietly stops converting.
Want this diagnosed on your own numbers?
The RADAR™ Scan scores your revenue engine in 2 minutes — 12 questions, a 0–100 score, and your gate verdict. No email required.
Run your RADAR™ Scan→Questions this raises.
What is signal-to-action latency?
Where does most signal-to-action delay come from?
What is a good signal-to-action latency target?
How do you reduce signal-to-action latency?
Why measure a GTM engineer on latency?
Related guides.
Four signal families ranked by predictive strength, each with a decay window — plus how to weight them without building a scoring model nobody trusts.
GTM EngineeringThe technical operator who builds go-to-market systems instead of running plays — what the role owns, what it pays, and why it appeared.
GTM EngineeringAssignment models compared, the fallback rule nobody builds, and why alerting the manager rather than the rep is what makes an SLA real.
GTM EngineeringFirst we build your pipeline. Then we build the machine that scales it.
Every engagement starts with the RADAR™ Reveal — a 2-week audit with a scored report, gate verdict, and roadmap. Yours to keep, whatever you do next.