What it means
Lead routing is the piece of plumbing between "someone filled in a form" and "a named human is responsible for calling them". It is not glamorous and it is not usually anybody's job title, which is why it is one of the most reliably broken systems in a go-to-market stack.
A routing system is an ordered list of rules evaluated top to bottom until one matches. That ordering carries more meaning than teams realise. Put territory before existing-account ownership and you will call your own customers as though they were strangers. Put enterprise segmentation after round-robin and your largest inbound leads will land wherever the pointer happened to be.
There are five routing strategies in common use, and most real systems layer several of them:
- Ownership-based: if the account already has an owner, they get it. This should almost always be rule one.
- Territory: by country, region, language, or postal code.
- Segment or skill: enterprise to the enterprise team, a Turkish-language lead to a Turkish-speaking rep, a technical product to someone who can answer.
- Round-robin, plain or weighted: fair distribution when no other rule applies.
- Pull queues: leads sit in a shared pool and reps claim them. Fast when the team is hungry, and quietly unfair when it is not.
The formulas, written out
Routing is judged on four numbers.
Time to assign = assigned_at - created_at
Time to first touch = first_outbound_activity_at - created_at
Report both as median and 90th percentile, never as a mean. The distribution of response times is heavily skewed, so a mean is dragged around by a handful of weekend arrivals and describes no actual lead.
Catch-all rate = (leads matched only by the final fallback rule / total leads routed) x 100
This is the health metric nobody puts on a dashboard and everybody should. It measures how often your rules could not decide.
Expected share for rep i: E_i = T x (w_i / sum of all w)
- T: total leads routed in the period.
- w_i: the capacity weight of rep i. A full-time rep is 1.0, a half-time rep 0.5, a senior rep carrying larger deals might be 1.5.
- E_i: how many leads rep i should have received.
Load deviation for rep i = (A_i - E_i) / E_i x 100, where A_i is the actual count. Anything beyond roughly fifteen percent in either direction is a rule problem, not luck.
A worked example, end to end
A team of six reps receives 1,200 leads in a month. Capacity weights are Ada 1.0, Bora 1.0, Cem 1.0, Deniz 0.5, Elif 1.5, Fatih 1.0, summing to 6.0.
Expected shares:
- Ada, Bora, Cem, Fatih:
1,200 x (1.0 / 6.0) = 200each - Deniz:
1,200 x (0.5 / 6.0) = 100 - Elif:
1,200 x (1.5 / 6.0) = 300
The rule set, in order:
- Existing account owner wins.
- Headcount above 500 goes to Elif.
- Country matches a territory, split across Ada, Bora, Cem, Fatih.
- Everything else goes to the default owner, Deniz.
What actually happened:
- Rule 1 matched 0 leads, because none were existing accounts.
- Rule 2 matched 96 leads. Elif received 96 against an expected 300.
- Rule 3 matched 648 leads, 162 each to Ada, Bora, Cem and Fatih against an expected 200.
- Rule 4 matched 456 leads. All of them went to Deniz, against an expected 100.
Load deviations:
- Deniz:
(456 - 100) / 100 = +356% - Elif:
(96 - 300) / 300 = -68% - Ada, Bora, Cem, Fatih:
(162 - 200) / 200 = -19%
Catch-all rate = 456 / 1,200 = 38.0%
The cause is a single missing field. The website form does not ask for country, and enrichment fills it for only part of the traffic, so 456 leads reached rule 4 with a null country and fell into the default owner's queue. Nothing errored. Every one of those leads is recorded as successfully routed.
The response-time distribution is where this becomes visible, and only if you look at the right statistic. Median time to first touch across all 1,200 leads was 9 minutes, which reads as excellent. The 90th percentile was 41 hours, and 212 leads were never touched at all. The median is healthy because 744 leads went to five reps with spare capacity; the tail is catastrophic because 456 went to a half-time rep who could not physically work them.
Two changes fixed it. First, infer country from the phone prefix and the request IP before routing, which cut null countries from 456 to 71. Second, replace the named default owner with a weighted round-robin across all available reps and raise an alert when the catch-all rate crosses 10%. The following month: catch-all rate 5.9%, worst load deviation 8%, 90th percentile time to first touch 2 hours 10 minutes, untouched leads 14.
Three ways the measurement goes wrong
Measuring time to assign instead of time to first touch. Assignment is a webhook writing a column, so its median is approximately three seconds and its chart is a flat line at zero. Teams put it on the dashboard because it looks good, and it is entirely uninformative: in the example above, all 1,200 leads were assigned in under a second, including the 212 nobody ever contacted. Measure the human clock.
Reporting the mean. The mean time to first touch in that month was 4 hours 51 minutes, which sounds tolerable and describes no lead in the dataset. The median was 9 minutes and the 90th percentile was 41 hours. Skewed distributions need percentiles.
Counting a fallthrough as a successful route. If your routing report says "1,200 of 1,200 leads routed", it is measuring whether the code ran, not whether the decision was right. Log which rule matched, and report the catch-all rate next to the success rate.
How routing is actually derived from CRM data
Routing reads more tables than most people expect:
- The lead record, including fields that may be null at the moment routing runs. Enrichment is asynchronous, so a rule that depends on enriched data must either wait or be re-evaluated later.
- Account and existing-contact tables, for the duplicate and ownership checks that belong at rule one.
- The rep roster with weights, working calendar, timezone, declared holidays and out-of-office windows.
- An open-lead cap per rep, so routing can decline to add to a queue that is already unworked.
- An assignment audit table, one row per routing decision, carrying the rule that matched, the owner chosen, the timestamp and the actor. Without this table none of the metrics above can be computed after the fact.
Edge cases that decide whether the system is trustworthy:
- Weekend and out-of-hours arrivals. A lead lands at 02:14 on a Saturday. Does the service-level clock start at 02:14 or at 09:00 on Monday? Both are legitimate metrics: calendar time answers "what did the customer experience", business time answers "did the team do its job". Compute both and label them. Never quietly use business hours for the internal report and calendar hours for the customer promise.
- Duplicate arrivals across channels. The same person fills in a form and messages WhatsApp four minutes later. Match on email plus phone before routing, or two reps will open the same conversation.
- Concurrent inserts. Two webhooks arriving in the same millisecond can read the same round-robin pointer and both assign to the same rep. The counter increment has to be atomic, which in practice means doing it in the database rather than in application memory.
- Departed reps. When someone leaves, their rules usually stay. Leads keep routing into an inactive owner and vanish from the unassigned queue. Deactivating a user must trigger a re-route of their open leads and a rule audit.
- Re-routing after enrichment. A lead routed as small business at 10:00 is enriched at 10:04 and turns out to have 900 employees. Decide whether the enterprise rule may claim it back, and if so, whether the first owner keeps credit for the touch they already made.
Why it matters
Routing is the shortest path between money spent and money earned. Every lead in that 456-record queue was paid for: an ad click, a content investment, a conference badge. The routing rule is the last step before that spend either turns into a conversation or expires quietly.
It also sets the floor on pipeline velocity. Days lost between arrival and first touch are days added to the sales cycle before a rep has done any selling, and cycle length is the one variable in the velocity formula that sits in the denominator. Fixing routing is usually the cheapest available reduction in cycle time, because it requires no change in how anybody sells.
Common mistakes
- A single named default owner. Every upstream data gap becomes one person's queue.
- Routing on fields that are frequently null. Check the fill rate of every field a rule depends on before you depend on it.
- No audit row. If you cannot say which rule matched, you cannot debug a routing complaint, and you will get them.
- Ignoring availability. Assigned to someone on holiday is worse than unassigned, because it looks handled.
- Rules only a single person understands. Routing logic buried in a workflow builder with forty nodes is a permanent dependency on whoever built it.
Related concepts
- Round-robin assignment: the distribution algorithm most catch-all rules should use.
- First response time: the metric routing exists to protect.
- MQL: the threshold that decides which leads enter the routing queue at all.
- SQL: the acceptance the routed rep is expected to make or decline.
- ICP: territories and segments are slices of the profile with owners attached.
- Omnichannel CRM: why the same person can arrive twice through two channels.
How Pinlyx handles it
Pinlyx evaluates routing rules in an explicit order, writes an audit row for every decision recording which rule matched and which owner it chose, and treats availability as a first-class input so a rep on holiday is skipped rather than silently loaded. Round-robin counters are incremented in the database, so two messages arriving in the same millisecond from two channels cannot land on the same rep by accident, and unassigned or untouched leads surface as their own queue instead of disappearing into a default owner's list.