Lead Routing: The Rules That Decide Who Owns an Inbound Reply

Lead routing is the automated assignment of an inbound lead, reply or booking to a specific owner, according to rules evaluated at the moment the record arrives. A reply lands, the system reads what it already knows about the person and the company, applies an ordered set of rules, and writes an owner onto the record. Everything downstream hangs off that one field: which queue the record appears in, who gets the alert, whose number it lands on at the end of the quarter.

The term exists because ownership used to be decided by whoever noticed first. That works at ten inbound replies a week and breaks at a hundred, and it breaks in a particular direction. The records two people both wanted were argued about loudly and got worked. The records nobody wanted, or nobody saw, were never argued about at all, so nothing surfaced them. Routing is the answer to the second problem more than the first. It exists so that every arriving record has a named owner within seconds of arriving, whether or not anyone is watching.

Lead routing rules, and the order they run in

A routing system is a small stack of decisions, run in a fixed order, against whatever fields exist on the record at the instant it lands. The rule bases in common use are unglamorous and mostly compose well.

Territory. Assignment by geography: country, region, state, postcode, sometimes time zone. The oldest rule base and still the most common, because it maps onto how sales teams are usually organised and onto who can plausibly take a call at three in the afternoon local time.

Named-account lists. A static mapping of specific companies to specific owners, used for strategic accounts and anything with an existing relationship. This one has to be evaluated before everything else, because the whole point of a named account is that it does not get treated like general inbound.

Segment. Company size, industry, product line, deal band. A record from a two hundred person manufacturer and a record from a five person agency go to different people because they are different sales motions, not because either is better.

Language. Underrated and mechanically simple. If the reply is in German and the owner does not read German, nothing else about the assignment matters.

Availability. Working hours, holiday, out of office, sometimes a live capacity signal from the queue. This is the rule base that turns a good static assignment into a bad live one, and the one most systems handle worst.

Round robin. Even distribution across a pool, one record at a time. It is the usual tie-breaker once every other rule has narrowed the field to a group rather than a person. Round-robin assignment is its own topic with its own failure modes, and this entry stops at naming it as one of the rule bases.

Composition is where the design work sits. Most systems evaluate rules top to bottom and stop at the first match, which means the order of the rules is the actual policy and the rules themselves are just its expression. A named-account rule sitting below a territory rule does nothing at all, and it will look perfectly correct in the configuration screen.

A team whose routing needs organising is usually looking at rules in the wrong order rather than at missing rules, and the reordering is the whole of the fix.

What a dedicated router does with these rules

Routing tools sell exactly this ordering. RevenueHero's routing page says it "checks who already owns the lead, routes the rest by the rules you set, and logs the trace for every assignment decision". Ownership comes first through lead-to-account matching, "contact → domain → company, with fuzzy matching for the near-misses", and the rest is split by "Strict, flexible, or balanced round robin" with weights per rep. So account-based routing and round robin do sit in one router there, in the order this entry recommends. One detail cuts against "always assigned to their designated account executive": a "Stale-owner skip" treats a lead as net-new when the account has had no activity in 90 days, which is a policy choice worth knowing before relying on it.

Deduplication has to run first

The check that decides whether this record is already in the system has to happen before any assignment rule fires, and it is the step teams skip because it feels like a data problem rather than a routing problem.

It is a routing problem. A record that already belongs to somebody, arriving again under a slightly different company string or a personal email address instead of a work one, will be routed by the rules as though it were new. Now two people own the same buyer, both have been alerted, and both think they are the first contact. The system built to prevent exactly that collision has manufactured one, and it will do it again every time the same buyer replies.

An unrouted record is worse than a badly routed one

Every routing system needs a terminal branch: a named human who receives anything the rules could not resolve. Not a queue, not a shared inbox, not a group alias with nine people on it. One person whose job includes clearing that branch.

The instinct is to treat the fallback as an admission of failure and to keep adding rules until it is never needed. That is the wrong direction. A badly routed record is visible: it sits on somebody's list, they read it, they say this is not mine, and it moves. An unrouted record has no list to sit on. Nobody is wrong, nobody is late, and no report shows a gap, because the report is built from records that have owners.

Speed is the point of the whole system

Routing is bought to remove a delay. A reply routed in two minutes and the same reply routed the following morning are different assets, because the person who wrote it was thinking about the subject when they wrote it and has moved on by the time anyone answers. The rules, the fairness, the reporting are all in service of that: they exist so that the assignment can happen without a human in the loop, and the only reason to want that is speed.

The metric that puts a number on that delay is lead response time, and it is worth splitting into the routing leg and the leg after it, because the two have different owners and opposite fixes.

Which means a routing system that is accurate and slow has failed at its actual job while passing every test anyone runs on it.

How it is measured

Four numbers describe a routing layer honestly, and most teams track only the first.

Measure	From, to	A bad number means
Time to owner	Arrival to owner written	Something is batching
Time to first contact	Owner written to first action	The alert does not work
Unrouted rate	Share hitting the fallback	The rules no longer fit the market
Reassignment rate	Share changing owner later	The rules no longer fit the team

Time to owner. Record arrival to owner written. Should be seconds. If it is minutes, something is batching.

Time to first human contact. Owner written to the owner actually doing something. This is the number the buyer experiences, and the gap between it and time to owner is the real measure of whether the alert works.

Unrouted rate. The share of arriving records that hit the fallback branch. A rising number here is the earliest signal that reality has drifted away from the rules, usually because the business started selling into a segment the rules were never told about.

Reassignment rate. The share of records that change owner after assignment. Some reassignment is healthy. A high rate means the rules encode a model of the team that no longer matches the team.

Assignment is one job inside a longer sequence, and the four around it, from the creation of the record through qualification and prioritisation to nurturing, are set out in lead management.

Where the textbook definition breaks

The tidy definition treats routing as a solved allocation problem. Two things about live programmes are missing from it.

Routing is designed around fairness and bought for speed, and those goals genuinely fight. The fairness requirement says every rep should get a comparable share of the good inbound, which is a real requirement with real commercial force behind it. Nobody stays on a team where the best accounts always land on the same desk. The speed requirement says the record should go to whoever can work it now. Those two produce different answers most mornings, and the fairness answer usually wins because it is the one somebody will complain about. Nobody complains on behalf of a buyer who waited nine hours, because that buyer is not in the room and does not know what happened.

The compromise most teams eventually land on is to let fairness govern the assignment and let a separate mechanism govern the timing: assign by the fair rule, then let anybody available work an unattended record after a short window. That keeps the credit fair and the response fast, and it requires somebody to decide the window and write it down.

Every routing failure is silent by construction. This is the more serious break. A routing rule that misfires does not throw an error, because from the system's point of view nothing went wrong. A rule was evaluated, a value was written, the record was saved. If the value was wrong, or if the owner was on holiday, or if the rule matched a condition nobody intended, the record simply sits somewhere quiet. There is no exception, no failed job, no red mark on a dashboard. The only symptom is a reply that was never worked, and the only person who notices is the buyer who did not get an answer.

So the design principle worth stating plainly: a routing rule that cannot decide must escalate to a named human, never fall through to nobody. A rule with no match and no fallback returns nothing, and nothing is indistinguishable from a quiet week. Any branch of the logic whose outcome is an empty owner field is a defect, however sensible the rule looked when it was written.

The same principle applied to monitoring: the number to watch is not the routing errors, because there will not be any. It is the count of records with an owner and no activity, aged past whatever your own answer window is. That report is the only thing in the stack capable of seeing this failure.

Fails loudly

• Deduplication runs before any assignment rule
• One named person receives everything unresolved
• An owned record with no activity past your window raises an alert
• Unrouted and reassignment rates are read weekly
• Rule order is written down, because order is the policy

Fails quietly

• Unmatched records fall to a shared inbox or group alias
• Ownership goes to whoever opens the alert first
• Holidays live in a manager's memory, not the rules

What to do with it

Write the rule order down before configuring anything, in plain sentences, and get the sales lead to agree to it as a policy rather than as a technical setting. Most routing arguments are policy arguments that were never had, surfacing months later as a complaint about a tool.

Then build the two checks that make failure visible: the fallback owner and the stalled-record report. Between them they convert the silent failure mode into a loud one, and they take an afternoon. Everything else in a routing project is refinement, and refinement of a system that fails silently is effort spent on the wrong end.

If your inbound volume is small enough that a person could plausibly assign every record by hand, do that and spend the time on the answer instead. Routing earns its complexity at the volume where nobody can hold the whole queue in their head, and not before.

Related terms and guides

Routing decides who owns a record, which only matters if the record was worth having. The upstream question of who belongs on the list at all is the ideal customer profile, and the downstream question of what the owner actually does with the reply is covered in B2B appointment setting.

Where the rules live is usually a CRM question. If your inbound arrives from LinkedIn rather than email, the record has to reach the CRM before any rule can act on it, which is the practical problem discussed in LinkedIn CRM integration. For the general shape of moving records between a sourcing tool and the system of record, the Apollo and HubSpot integration guide works through one common pairing, and APIs for client acquisition covers the wider set of connections a routing layer usually sits on top of.

Who the named owners are is a staffing question as much as a systems one, and the SDR role definition sets out what the person receiving a routed reply is actually accountable for.

Routing only pays off when there is inbound worth routing. If the constraint is the volume of qualified conversations rather than their assignment, see what a first campaign looks like.