Business & Revenue OpsFree
Speed to Lead Audit by Rule and Owner
Send your lead timestamps and routing rules, get every delay traced to the specific rule or capacity gap behind it.
Speed-to-lead reports converge on one number: an average or median response time, usually benchmarked against a five-minute target that traces back to a study over a decade old. The ratio between fast and slow response matters more than the absolute figure, and a faster reply to a form that captured nothing still buys less than fixing what happens upstream of the timer. Even where speed is genuinely the constraint, one average cannot say whether the delay comes from a rule, a rep, or a gap in both.
This run reads the lead export's submission and first-touch timestamps alongside the routing configuration that was live when each lead arrived, and walks every late lead back through the specific rule that assigned it. A delay held by an after-hours rule is a different problem than one held behind an already-overloaded owner's queue, and both differ from a lead that matched no rule at all and sat until someone found it manually. Each bucket gets a lead count, an average delay, and a named fix, checked against the total before anything is reported.
On a worked run for Kestrel Data Systems, a B2B software company, 420 leads over 30 days averaged 5.84 hours to first touch. Two named causes, an after-hours routing gap and one overloaded owner, accounted for 70% of all the lead-hours behind that average despite being only 36% of the leads, and fixing both projects the average down to 1.84 hours. The routing rules the delay gets traced against and the response-time commitment the delay gets measured against both feed this run directly.
An average hides which lever to pull. A named cause doesn't.
The five-minute rule is not wrong, it is just incomplete: the finding behind it measures connect probability, not what caused a specific lead's delay. A team with a published five-minute SLA can still be averaging six hours, because the SLA states an intent and the routing configuration decides whether a given lead can actually reach it. The audit reads the configuration as it stood when each lead arrived, since a rule changed last week does not explain a delay from six weeks ago.
Every late lead gets sorted into one of three structural causes. An after-hours rule holding a lead until the next business open is a scheduling gap, not a routing failure, since the rule worked as written. A lead assigned to an owner who already had a backlog is a capacity gap: the rule worked, the assignment was simply wrong given that queue at the time. A lead matching no rule at all is a coverage gap, and it hides the longest, since the fallback owner looks identical to a correctly routed one in every report.
The three bucket counts have to sum to the total late-lead count, and the lead-hours behind each bucket have to sum to the total lead-hours behind the average, or the read gets thrown out rather than reported. On the worked run, leads that matched no rule were only 5% of volume yet 28% of all the lead-hours behind the average. That is the kind of concentration a single average can never surface, and a manager cannot act on it until it has a name.
How it works
Send the export
The lead export with submission and first-touch timestamps, plus the routing rules that were live over that period.
Trace each delay
Every late lead walked back through the specific rule or owner queue that actually held it at the time.
Sort into causes
Scheduling gaps, capacity gaps, and coverage gaps, each carrying a lead count and a total lead-hours figure.
Project the fix
The average recomputed as if each fixable cause were resolved, so leadership sees what a specific change buys.
What you get
- Every late lead traced to the specific routing rule, owner, or gap that actually delayed it
- Separates a scheduling gap, a capacity gap, and a coverage gap instead of one blended average
- Reads the routing configuration as it stood when each lead arrived, not as it reads today
- Checks named causes sum to the total lead-hours behind the average before anything is reported
- Projects the average if each fixable cause were resolved, so the fix has a number attached
- Flags the unassigned-queue leads a fallback owner makes invisible in a standard routing report
Common questions
Isn't average response time already the standard speed-to-lead metric?
It is the standard number, and it is the least actionable one. On the worked run, the 5.84-hour average was produced by two structural gaps affecting just over a third of leads; the other two-thirds were already close to target. A named cause tells a manager what to fix. An average only tells them it is broken.
What if we only have assignment timestamps, not first-touch timestamps?
Send those, and say so. Assignment time still lets the run separate a scheduling or capacity gap from a lead that was actually worked quickly once assigned, though the report will flag first-touch as an estimate rather than a measured figure until that data exists.
How is a capacity gap different from just needing more reps?
Often it isn't a headcount problem at all. A round robin that was never rebalanced after a new rep joined, or one that ignores existing queue depth when it assigns, produces the same backlog that hiring would only mask. The audit names which one it is before anyone proposes a fix.
Our SLA already targets five minutes. Why are we still averaging hours?
Because the SLA describes an intent and the routing configuration decides whether a given lead can actually reach it. A published target with no after-hours rule behind it, or a round robin that keeps assigning into an already-full queue, will miss its own SLA no matter how aggressively it is restated in a policy document.
Does this replace our lead scoring model?
No. Lead scoring decides which leads deserve the fastest response; this audit measures whether the routing and capacity behind that response actually deliver it. A perfectly scored lead assigned to an overloaded owner still sits for hours, which is a routing problem the score cannot see.
What about leads that came in through a source we don't route on at all?
Those are exactly the coverage-gap bucket. A source with no matching rule falls to whatever fallback owner the platform assigns, and that fallback assignment looks identical to a correctly routed lead in every standard report. It is why coverage gaps usually go unnoticed the longest of the three causes.
Should we fix the intake form before running this audit?
That's a separate, earlier problem worth fixing too. Tracing which of your form's fields cost abandoned submissions without feeding any routing or qualification decision fixes what data reaches the rules this audit traces. A lead that already made it through the form and into a rule is exactly what this audit measures, regardless of how that form performed.
Speed to Lead Audit by Rule and Owner
Fill in the form and your workspace opens with the work already underway.