Lead Routing Rules Template
Your platform reports the owner field. This pack replays your rule table against real leads and reports which entry actually claimed each one.
Free download · No account needed
A routing rule table gets written once and then never tested, because there is nothing obvious to test it against. The rules live in an admin screen and the leads live in an export, and no screen in any platform joins them. So the table gets judged on whether it reads sensibly, which every rule table does. This pack performs the join: it takes your entries in their real sort order and walks them against your real lead history, one lead at a time.
Each lead then lands in exactly one of three buckets, and the three counts sum to your lead count or the replay is thrown away rather than reported. Exactly one entry matched, so the table worked. Two or more matched, so first-match-wins let sort order pick the owner and nobody chose that sort order against that collision. Or nothing matched, and the lead went to whatever fallback the platform holds. In the worked example those buckets are 71.5%, 22.3% and 6.2%.
The second and third buckets have no report anywhere in any platform, and the reason is the same in both cases. The fallback owner is a real named user, so a lead nothing routed carries an owner name and an assignment timestamp, and is indistinguishable from a correctly routed one anywhere. Response speed is the largest controllable factor, and most companies are not responding nearly fast enough. Blank fields are the commonest reason an entry misses, so run CRM hygiene and dedup alongside this.
What is in the pack
Routing Matrix
One row per entry in sort order, with four claim counts including what it would have claimed had it been first
Unrouted Lead Log
One row per lead no entry matched, each carrying its cause, its fix type and the person who owns that fix
Time to Owner
Median hours and conversion per bucket against the sole-match control, ending in commitments lost
Territory Register
The lookup your entries copy from, with the lead count and the disagreements between register and entry
Routing Policy
Precedence order, pool distribution models, the response commitment, and what this policy deliberately excludes
Exception Handling
The cases handled by somebody remembering, written down, with the open questions left open on purpose
Coverage Note
What the rules never reached, split by cause, priced, and attributed to the person who can fix it
How the Replay Works
The method written down so the output can be checked and rerun in six months for a comparable answer
How it works
- 1
Send both halves
Your routing entries in their real sort order, and a lead export covering a couple of quarters. Wide rather than tidy: an entry testing a column the export lacks will look dead when it is not.
- 2
Replay every entry
Each lead is walked against all entries rather than stopping at the first match, so collisions are recorded with the winner and everything it beat, which is the part the platform discards.
- 3
Give every gap a cause
The no-match bucket splits into criteria gaps, empty rotation pools and leads created by paths that never call the rules. Three fixes, three owners, three separate queues.
- 4
Price it and reorder
Each bucket gets a median time to owner and a conversion rate against the sole-match control, so the finding arrives as commitments lost rather than as a percentage.
Frequently asked questions
What do I need before this is useful?
Your routing entries with their real sort order and criteria, plus a lead export with every field those entries test, the created timestamp, the current owner and the first-touch timestamp. Pool memberships and a territory map help. A screenshot of the admin screen is fine for the entries.
My reports already show every lead has an owner
That is the finding, not a reason to skip this. The platform fallback owner is a real named user, so a lead that matched no rule carries an owner name and an assignment timestamp and looks identical to a routed one. Owned and routed are different states, and only one of them is reported.
Can this run without lead history?
Partly. Entries can be checked against each other for overlap and against the territory register for disagreement, and both find real defects. But overlap found on paper is only a possible collision. The replay is what turns it into a lead count, which is what makes a reorder worth doing.
Why does a collision matter if the lead still gets one owner?
Because sort order picked that owner and nobody chose the sort order against that collision. A broad entry placed high silently swallows every lead the specific entries below it were written to catch. In the example one entry took 1,670 leads from six others, and all of them reported as correct.
Is round robin not already even?
It is even with respect to itself. HubSpot counts assignments made by that specific rotation action rather than the records each user owns, and the counts reset if you add or remove owners. So an even rotation says nothing about anybody's real book, which is why the matrix names a model per row.
What happens when everyone in a pool is away?
On HubSpot, with availability filtering on, the record is left unassigned. Nothing logs it and it clusters on Fridays, holidays and kickoff week. The fix is an overflow path to a named manager, not another entry, because the criteria matched perfectly well.
Does this set our lead SLA or scoring model?
No, and that boundary is deliberate. This pack decides which owner each lead belongs to and proves the rules deliver it. What the score itself should weigh belongs to the lead scoring model, and the contact-time commitment to the sales and marketing SLA. What the owner does next belongs to pipeline hygiene, and a speed-to-lead audit reads what happens after a lead clears these rules.
Find out how many of your leads were actually routed
Send the entries and a lead export. The first thing back is three bucket counts that sum to your lead count.
Replay my rule table