The lead was assigned in nine seconds — to a salesperson on holiday

Assignment and routing are not the same operation. Assignment writes a name into a field. Routing gets an enquiry in front of somebody who is going to answer it, and the difference between the two is an acceptance step: a moment where a human takes the lead and the system records that they did. A CRM that assigns in 9 seconds and never asks anyone to claim anything has excellent assignment statistics and no routing at all.

That distinction is the whole diagnosis. Before you change a rule, find out whether leads are landing on the wrong people or landing on the right people and sitting there, because those need opposite fixes.

The check: minutes to first outbound touch, by assignee

1. Export 30 days of leads: record id, created-at to the second, assigned user, assignment timestamp, and the timestamp of the first outbound message or call logged against the record.
2. Compute minutes from creation to first outbound touch. Use the payload timestamp rather than the CRM write time where the two differ.
3. Bucket by assignee and take the median, not the mean. One lead answered 3 days later drags a mean far enough to hide 40 that were answered in 4 minutes.
4. Sort assignees by median. A store with a routing problem shows a clean split: most people in single-digit or low double-digit minutes, and 2 or 3 people in hours.
5. Cross-tabulate those assignees against the rota for the same days. If the slow assignees were not working, the rule is reading rota data that is wrong or absent.
6. Count leads with no outbound touch at all after 48 hours, grouped by assignee and by rule. This is the number that usually ends the discussion.

Four causes, and what distinguishes them

The rota is a data problem before it is a management problem

Every availability-aware routing rule depends on a table saying who is working. In most stores that table is maintained by nobody in particular, updated when someone remembers, and consulted by software with complete confidence. A rule acting on stale availability is more damaging than a rule with no availability logic at all, because it produces a distribution that looks deliberate.

The general principle is worth naming: a rule is only ever as good as the reference table underneath it, and reference tables need an owner and a refresh path or they rot silently. The parts department runs into the identical dependency when a lookup returns the wrong component, which is the choice examined in licensed data versus a supplier catalogue for fitment. Same failure, different table.

• Give the rota one owner and one place. Two sources — a wall planner and a CRM flag — guarantee they disagree by the second week.
• Make absence set availability, not the other way round. Approved leave should write the flag; asking people to remember on the morning they leave does not work.
• Add a fallback that assumes unavailable when the data is older than a stated age. Failing to a shared pool is recoverable; failing to a name is not.
• Log the availability value the rule read at the moment it fired, so an argument about who was in becomes a query rather than a conversation.

Two rules matched and the one you did not expect won

Routing configurations grow by accretion. A rule for a franchise brand, a rule for a marketplace source, a rule for commercial vehicles, a rule someone added for a campaign 2 years ago and never removed. When a lead satisfies 3 of them, something has to choose, and the choice is made by an ordering or a first-match rule that nobody in the store can describe.

The evidence you need is a rule-firing audit: for a sample of 50 leads, which rules matched, which one applied, and what it set. Most dealership CRMs can show this per record even when they cannot report it in aggregate, and 50 records read by hand is a morning's work that settles the question permanently. Two things usually fall out of it — a campaign rule still live long after the campaign, and 2 rules that are the same rule written twice by different people.

A routing configuration nobody can explain on a whiteboard is not a routing configuration. It is a set of accidents that happen to run in a repeatable order.

The leads that match nothing at all

Every rule set has an implicit default, and the default is where the awkward enquiries go: a vehicle type you do not usually stock, a source that was added last month, a lead whose fields arrived empty. These land in a pool with no owner or on a house account that exists for reporting rather than for selling, and they are invisible in exactly the way an assigned-but-unread lead is not, because nobody is even expecting them.

Two of them are worth handling specifically rather than dumping into the same pool. A trade-in enquiry needs a defined intake before anyone can say anything useful, as in qualifying a trade-in enquiry without quoting a number. An enquiry with no vehicle reference at all needs a human, because no rule can match a lead that names nothing.

The claim-or-reassign timer, specified

This is the mechanism that turns a silent queue into a visible one. It is not complicated, but it fails whenever any of its 3 numbers is left implicit.

1. Assign, then require a claim. The lead shows as pending until the assignee accepts it, and the acceptance is a deliberate act, not a side effect of opening the record.
2. Set the claim window against your response-time target. If you promise a reply inside 15 minutes, the window is a fraction of that, not most of it.
3. On expiry, reassign automatically to a named second target — a pool, a manager, the business development desk. Never to the same round-robin that produced the miss.
4. Escalate the second miss to a person, not a queue. A lead that has expired twice needs someone accountable, and 2 expiries is the point at which a system stops being able to help.
5. Cap reassignment at 2 hops. Every hop loses context, and a lead on its fourth owner has a worse conversation than one that sat for an hour.
6. Log every claim, expiry and reassignment with actor and timestamp, so the weekly number is claim rate by user rather than an argument.

Decision tree, with a name against each branch

1. Slow assignees line up with days off. Fix the rota ownership first, with a named owner and a stale-data fallback. Nothing else matters while the availability table is wrong.
2. Distribution is even but response is not. The rule is not reading availability at all. That is a configuration change, owned by the CRM administrator, and it is usually a same-week fix.
3. The wrong specialist keeps getting leads. Run the 50-record rule audit, retire the dead rules, and write the surviving order down where the sales manager can read it.
4. Leads are landing nowhere. Give the default pool an owner and an alert before you touch any matching logic, because an unowned default swallows every improvement you make upstream.
5. The rules are right and people are simply busy. This is a capacity and coverage question, and the honest answer may be an assistant that claims, acknowledges and gathers the missing facts until a person picks it up — bounded AI agents and automation work rather than a routing change. If you are buying that capability, the questions worth asking a supplier are in choosing an AI development partner.

What this page deliberately does not cover is what happens after the first touch. Follow-up cadence — how many attempts, on which channels, with what stop condition — is a separate design with its own page, and the next number that will not reconcile once routing is fixed is appointments set against customers who actually arrive, examined in the appointment was confirmed twice and the customer still didn't come. The rest of the silo sits under lead response and follow-up, within our wider automotive retail and aftermarket work.

• lead routing
• CRM rules
• response time
• escalation