Lead routing best practices (get every lead to the right rep, fast)

Lead routing is two problems wearing one name. The first is assignment — which user id gets written into the owner field. The second is visibility — whether that user's permissions let them actually see the row you just gave them. Almost every article about routing covers the first and skips the second, which is why so many carefully-designed routing schemes end with a rep saying "I never got it". Speed matters, and it is the part most teams already know. Ownership that survives an audit is the part they do not.

Routing is two problems, and most advice solves one

Write down what has to be true for a routed lead to become a conversation.

A user id is written into the owner field. That user's role permits them to see leads. That permission's row-level scope includes this particular row. Something told them it exists. They acted before the lead went cold.

Five conditions. Standard routing advice addresses the first and the fourth. The second and third are permission questions that live in a completely different part of the product, and they fail silently — no error, no bounce, just a lead sitting in a list the assigned rep cannot open.

The pattern to internalise: assignment writes a field; visibility decides who can read it. They are configured in different places by different people, usually at different times, and nothing checks that they agree. Designing routing without designing scope is designing half of it.

The speed evidence, and how old it is

The number everyone quotes comes from one study, and it is worth knowing which.

In March 2011, Harvard Business Review published "The Short Life of Online Sales Leads" by James B. Oldroyd, Kristina McElheran and David Elkington. The researchers examined 1.25 million sales leads received by 29 business-to-consumer and 13 business-to-business companies in the United States. Firms that tried to contact a potential customer within an hour of receiving a query were nearly seven times as likely to qualify the lead as those that waited even an hour longer, and more than 60 times as likely as companies that waited 24 hours or more.

Two honest caveats, because the figure gets repeated without either. It is 2011 data about web-form enquiries, and buyer behaviour has moved since — self-service research, more channels, more scepticism about a fast phone call. And "qualify the lead" is the study's outcome, not revenue. What survives the caveats is the shape: the decay is steep and it is measured in hours, not days. The direction is robust enough to design against; the exact multiples are period-specific and should not be quoted as though they were measured last week.

Design implication, and it is the only one that matters: your routing must complete without a human in the loop. Any design where a person has to notice, decide and assign has already spent the window on the noticing.

The four assignment models, and the decision rule for each

Pick one deliberately. Hybrids are fine; accidents are not.

Round-robin. Distribute evenly. Use it when your reps are genuinely interchangeable for the leads in question — early-stage teams, a single product, one segment. It is the simplest model and the easiest to explain when someone complains.

Territory. Route by geography, company size band, or industry. Use it when the reps are not interchangeable, which becomes true faster than most teams admit — the moment one rep has meaningfully more context about one segment, territory beats round-robin on conversion even though it looks less fair on volume.

Specialisation. Route by product line or technical depth. Use it when your products need different conversations. The failure mode is coverage: a specialist on holiday means their queue stops, so specialisation always needs a documented fallback.

Account ownership. Route to whoever already owns the account, regardless of what any other rule says. This one is not really an alternative to the other three — it is an override that should sit above them. A new enquiry from a company someone is already working belongs to that person, because the buyer has already had a conversation and does not want to start again.

The decision rule in one sentence: use account ownership as the first check, then territory if your reps differ meaningfully, then round-robin within whatever bucket you landed in. That composition covers most teams up to a few dozen sellers.

Round-robin is not what most people think it is

Two implementations share the name and behave differently after the first absence.

Rotating hands leads out in a fixed cycle: A, B, C, A, B, C. Simple, predictable, and it accumulates error. A rep who was out for a week comes back to a smaller pile than everyone else and stays behind indefinitely, because the cycle has no memory of the gap.

Least-loaded picks whoever currently owns the fewest leads. Autocloz's assign_owner action defaults to this: it counts leads per active member, then picks the minimum, breaking ties on user id for determinism. It self-corrects after absences because the returning rep is the lightest and gets the next several leads automatically.

There is a specific trap in the least-loaded design, and it is worth naming because it is invisible until it has done a lot of damage. A deactivated user owns the fewest leads, precisely because they have stopped working. A naive least-loaded implementation therefore assigns every new lead to the person who can no longer log in — silent orphaning at exactly the moment nobody is watching. Autocloz's implementation joins to the user table and requires the member to be active, which is the fix. If you are building this yourself, or evaluating a tool, that join is the thing to check.

A second subtlety: least-loaded counts owned leads, not open opportunities or hours worked. A rep who owns 400 dormant records from last year looks loaded and gets starved. If your lead volume is high and your archiving discipline is low, consider counting only leads created or touched recently.

Which events actually fire a routing rule

This is where most routing designs break, and the failure is entirely invisible from the rule editor.

A routing rule is attached to a trigger. If the event you assumed fires does not fire on the path your leads actually arrive by, the rule is correct and never runs. Autocloz publishes its supported set explicitly, and the design decision behind that is worth copying: triggers with no dispatch path are shown as roadmap and cannot be activated, so a rule cannot look live while doing nothing.

Triggers that fire today: lead.added_to_list, lead.created, lead.status_changed, deal.stage_changed, deal.won and deal.lost.

Triggers marked roadmap and blocked from activation: touch.outcome, schedule.cron, lead.score_crossed, email.bounced and lead.went_cold.

Now the specific gap to design around. lead.created fires from the leads API create path. It does not fire from the contact-form capture path, which writes its new list membership row directly and then wakes the autopilot list watcher — that starts the attached campaign, but no lead.created workflow and no lead.added_to_list workflow runs. The paid-ads capture path has the same shape.

The consequence in plain terms: if your inbound enquiries come through an embedded form and your routing rule is attached to lead creation, it will never fire on the leads you care most about. The working design is to route those leads by the destination list instead — the list-level assign-owner action reassigns every member lead in one statement and requires an active workspace member — and to test with a real form submission rather than by creating a lead through the interface, which takes a different path.

The general lesson outlives the specific product. Test routing by producing a lead the way your leads are actually produced. A test lead created by hand exercises a code path your customers never touch.

The visibility half: off, own, team and all

Assignment writes an owner. Visibility decides who can read the row, and it is resolved per module and per action rather than globally.

Autocloz resolves four row-level scopes:

• off — the permission is denied entirely. The action is not available.
• own — rows assigned to, or created by, this user.
• team — rows owned by any member of the holder's team. A team is a named group with a leader, and the leader sees the team's rows while members see only their own.
• all — every row in the workspace.

Owner and admin roles resolve to all for everything. A custom role can set a per-module, per-action scope; where a role grants the permission bit but sets no scope, the workspace-wide default is consulted before falling back to all.

Three practical consequences.

Aggregate numbers must respect the same scope as the list. A count that filters only on the workspace while the list beneath it filters on scope produces a header and a table that disagree — and the header is a small permission leak as well as a confusing screen.

A round-robin pool and a visibility scope are different sets. Assigning to a rep whose role scope excludes them from the module is possible and produces exactly the "I never got it" report. Check both when you add someone.

Analytics defaults are worth checking separately. Personal-by-default reporting is the safer choice and it surprises managers who expect workspace-wide numbers. Decide what you want rather than discovering it.

A worked routing design for a six-person team

An illustrative configuration for a team of six — two enterprise sellers, three mid-market, one handling inbound trials — showing how the pieces compose.

Rule one, highest precedence: existing owner. If the lead's company already has an owner, route there. Everything below is skipped. This prevents the most damaging outcome, which is two reps calling one account in a week.

Rule two: company size. Headcount above 500 goes to the enterprise pool; everything else to mid-market. Written as a condition on a field that is populated, not on a description someone typed.

Rule three: least-loaded within the pool. Two sellers in enterprise, three in mid-market, active members only.

Rule four: the trial queue. Product-trial signups bypass rules two and three entirely and go to the inbound seller, because a trial is a different conversation from a cold enquiry.

Visibility: enterprise and mid-market are two teams, each with a leader. Sellers have leads at own scope, leaders at team, the head of sales as an admin at all.

Notification: the owner is notified on assignment. This is the step people skip, and it is the one that turns assignment into contact. Where the notified rep replies from matters too — one queue holding replies from every channel is what stops a routed lead's answer landing in a mailbox nobody watches.

The escalation rule: anything unworked after four business hours appears on a shared queue that anyone may claim. Not a reassignment — a claim, so ownership stays deliberate. Four hours is a starting number chosen against the shape of the HBR decay, and it should move once you can measure your own.

Autocloz's free plan covers 5 users with role-based access, teams and workflow automation included — start free and configure the scope grid before you invite the sixth person, not after.

The five ways routing silently fails, and how each is diagnosed

Failure one: the trigger does not cover the arrival path. Diagnosis — submit a real form, then query for workflow runs in the following minute. Zero runs with a lead that exists is conclusive.

Failure two: assignment to an inactive user. Diagnosis — join owned leads to the user table and count rows owned by anyone whose account is inactive. Any non-zero result is a live orphan.

Failure three: assigned but invisible. Diagnosis — log in as the assigned rep, or use an impersonation feature if you have one, and try to open the lead. Do not infer this from the permission grid; read it from the screen.

Failure four: assigned and unnotified. Diagnosis — measure the median gap between the assignment timestamp and the first activity on the record, split by hour of day. A bimodal distribution with a large overnight cluster means notification is not reaching anyone outside working hours.

Failure five: routing correct, contact still slow. Diagnosis — you are looking at a capacity problem rather than a routing one. Count leads per rep per day against realistic first-touch time. If the arithmetic does not work, no routing rule fixes it, and the lead management process end to end is the wider frame to fix instead.

What changes at ten reps, and what Autocloz does not route

At ten reps three things become load-bearing that were optional at three.

Ownership disputes need a written precedence order, not a norm. Write the rules in numbered order and make the numbers visible, because the argument you are preventing is not about fairness, it is about two reps having called the same buyer.

Reassignment needs an audit trail. Every ownership change should leave a row saying who changed it and when. Without one, "who had this account in March" is unanswerable, and it will be asked.

Bulk moves need to be one operation. When someone leaves, their leads move in a single statement, not a paginated loop through whatever the interface had loaded. Autocloz's list-level assign-owner operates by list id and updates every member lead in one statement for exactly that reason.

The absences are worth stating plainly. There is no geographic territory-mapping surface — no postcode boundaries, no drawn regions. You express territory as conditions on fields such as country or size, and if you need drawn boundaries, this is not the tool.

There is no capacity-aware routing beyond owned-lead count. Least-loaded counts records, not open opportunities, minutes of call time or working hours, and it does not know about holidays.

There is no working-hours-aware assignment. Routing does not consult a rota, so overnight coverage is a rota-and-escalation problem you solve outside the rule.

And the scoring engine does not recalculate on a schedule, so a routing rule keyed on a score threshold is reading whatever the last explicit recalculation wrote. If you route on score, trigger the recalculation deliberately — what lead scoring is and a simple model to start with covers building the model, and the deals and CRM module is where ownership, teams and the activity timeline live. If you are still deciding whether a CRM is the right home for any of this, when to move off a spreadsheet makes the case with the failure modes rather than the feature list, and the Autocloz and Pipedrive comparison covers how ownership models differ between tools.