How can a revenue team measure lead-routing exception age?
A measurement protocol for lead-routing exception age that uses queue records, owner acceptance, and resolution evidence.
Question and scope
This protocol asks how long lead-routing exceptions remain unresolved and where the delay accumulates. The scope is one inbound lead queue over a defined window. An exception is a lead that cannot follow the standard routing rule without a manual decision. The protocol covers the time from arrival to a verified resolution or an approved reassignment.
The method is intended for a revenue operations team that already tracks leads in a CRM or routing tool. It uses timestamps that most systems record, plus a small amount of review-note coding. The output is an age profile and a short list of delay causes. It does not attempt to measure lead quality or conversion. State the task list and the service window before comparing any vendor.
Population and unit
Define the population as all leads that entered the queue during the window, not only the ones that remain open at the end. Include leads that were resolved, reassigned, cancelled, or merged. Excluding closed leads would bias the age estimate toward the cases that are hardest to finish. A closed lead that is excluded from the population can make the remaining cases look younger.
The unit is one lead-level exception. If a lead is routed, returned, and routed again, keep one unit and record each transition. If a duplicate record creates two entries for the same buyer, link them and count the primary record once. The rule should be written before collection so the denominator does not shift. Record the link so the duplicate does not become a second unit in the count.
Age definitions
Measure age from the first exception timestamp to the first verified resolution. A resolution can be a successful assignment, an approved reassignment, a documented cancellation, or a merge into an existing record. Do not use the last message date as the resolution date unless the message contains the decision. Use the decision timestamp rather than the last activity timestamp when the two differ.
Report the median and the oldest case, not only the average. A small number of very old cases can pull the average up and hide the typical experience. Use age bands such as under one day, one to three days, three to seven days, and over seven days. The bands make the operational problem easier to see.
Measures
The primary measures are the median age, the share of cases over the service target, and the oldest open case. Add the share of cases with an accepted owner, because a case can be old simply because nobody has accepted it. Report the count of cases that were reopened after closure. Report each measure with its numerator and denominator so the magnitude is clear.
Use secondary measures to locate delay. Track time waiting for information, time waiting for an approval, time waiting for a system change, and time waiting for an owner response. If the team cannot separate these waits, start with a simple reason code and improve the coding over time. The reason code should be based on the review note, not on a guess. A simple cross-tab by asset type is usually enough to show where to look first.
Data collection
Export the lead records with the arrival timestamp, exception flag, owner, status changes, and close timestamp. Keep the original export so the analysis can be repeated. If the system does not record an exception flag, use the queue membership history or a manual list maintained by the coordinator. Document the fallback method. If the export lacks a field, record the gap rather than reconstructing it from memory.
Sample the review notes for cases over the service target and code the delay reason. Use a small codebook with clear definitions, and have a second person check a subsample. Do not infer a cause from the lead source alone. A slow approval and a missing form field can produce the same age, but they need different fixes.
Reporting
Report the window, the number of leads, the number of exceptions, and the inclusion rule. Show the median age, the age bands, and the share over target. List the oldest five open cases with the owner and the next action. A report that shows only an average will not help the team decide what to fix.
Separate the age result from the cause analysis. The age result says how long cases take; the cause analysis says why. End with one process change and a date to remeasure. If the change affects only one queue segment, report the result for that segment separately. The fix should follow the cause, not the number alone.
Limits and sources of error
Timestamps can be incomplete or inconsistent across systems. A lead may arrive in one tool and be created in another minutes later, which adds time that is not really queue work. A resolution may be recorded after the actual decision, which also distorts the age. State which timestamp was used and what it represents. Record the timestamp definition in the report so a later reader can compare periods.
The sample may not represent a different season or campaign mix. A large event can create a temporary spike in exceptions that is not typical. The cited public sources describe data protection and control practice; they do not provide a service target for lead routing. Set the target locally and review it with the sales and marketing owners.
Review cadence
Review the measure monthly while the queue is active. After a routing rule change, run a focused review of the affected segment. Keep the definitions and the age bands stable so the team can compare periods. If the definition changes, mark the break in the chart and explain it. Use the same age bands after the change so the comparison is valid.
Use the monthly review to choose one fix, such as a clearer intake field, a named backup approver, or a rule change. Check whether the fix reduced the age without shifting the work to another queue. The goal is a faster, more accountable routing process, not a lower average produced by closing old cases. A lower average produced by closing old cases is not an improvement.
Owner acceptance as a delay cause
Measure the time between assignment and the owner's acceptance separately from the time spent resolving the case. A case can sit in an inbox because nobody has accepted it, even though the queue reports it as assigned. Record the acceptance timestamp when the system supports it. If it does not, use the first owner action as a proxy and state the limitation.
Report the share of cases that waited more than one business day for acceptance. Review the list with the queue owner and ask whether the assignment rule sent the case to the right person. A routing fix may be more effective than a reminder to the team. Keep the acceptance measure stable so the team can compare cycles.
Reopened cases
Count a case as reopened when it returns to the exception queue after a recorded resolution. Reopened cases are important because they can make the first resolution look faster than it was. Record the original resolution, the reason for the return, and the second resolution. Keep the case as one unit with multiple cycles. A reopen that happens within a day may be a correction, not a new cycle.
Report the reopen rate and the most common reason. A high reopen rate may point to a premature closure rule or a missing check. Review a few cases with the owner before changing the rule. The goal is a resolution that holds, not a faster first close. Keep the reason codes few enough that the team applies them consistently.
What to do with the result
Choose one change based on the largest delay cause. If the queue waits for approval, add a named backup approver. If it waits for information, fix the intake field or the source system. If it waits for owner acceptance, review the assignment rule. Write the change and the expected effect. Write the expected effect so the next measurement has a comparison point.
Remeasure after the change using the same definitions and age bands. Report the result for the affected segment and for the queue overall. If the change moves the delay to another stage, say so. A capacity or routing fix should reduce total age, not just relocate the wait. If the result is unclear, extend the window rather than changing the definition.