Routing is not the same as speed to lead. Speed is the promise; routing is the machinery that makes the promise keepable. You cannot respond in five minutes if it takes twenty to decide whose job it is.
Why routing is a revenue problem, not an admin problem
In MitHub's revenue engineering method you start at the payment and walk backwards. In business after business, the biggest single drop in the map is not conversion — it is contact. Leads arrive and nothing happens to them.
The research on response speed goes back years. Oldroyd, McElheran and Elkington wrote in Harvard Business Review in 2011 that "most companies are not responding nearly fast enough" to online enquiries (HBR). Fifteen years of better tooling have not closed the gap, because the gap is rarely about willingness. It is about an unassigned queue at 4:55 p.m. on a Friday.
The routing contract: five questions
MitHub treats routing as a contract the system must satisfy for every single lead, within seconds of creation.
- Does someone already own this account? Existing customer, open deal, or a contact a rep spoke to last month. Account ownership beats every other rule. Getting this wrong is worse than being slow.
- Where does it belong? Territory, branch, language, product line, service area. This is a data lookup — ZIP code, country, product interest — not a judgment call.
- Who is available right now? Not who is on the team: who is working, under capacity, and inside business hours.
- What did we promise? The SLA: first attempt within N minutes, M attempts over D days.
- What happens when the promise breaks? The escalation, automatically, without anyone noticing and reporting it.
Question 5 is the one that separates a routing system from a routing rule. Rules assign. Systems recover.
Rule types, and what each is good for
| Rule type | How it works | Best for | Failure mode |
|---|---|---|---|
| Account ownership | Match on domain, phone or account ID; assign to the existing owner | Any business with repeat buyers or branches | Duplicate accounts split ownership |
| Territory / branch | Map a geographic or segment attribute to a team | Multi-location operations, field sales | Leads outside the map become orphans |
| Round robin | Rotate sequentially through eligible owners | Equal-capacity inbound teams | Equal counts, unequal real workloads |
| Load balanced | Assign to whoever has fewest open records | Teams with uneven schedules | A rep who never closes keeps receiving leads |
| Score-based | Send high scores to senior reps, the rest to automation | Mixed-quality inbound at volume | A broken score misroutes silently |
| Random | Pick an eligible owner at random | Tie-breaking, tests | Nothing is explainable |
Major platforms implement the middle three directly. HubSpot's "rotate record to owner" action offers round robin, load balanced and random distribution, and only considers active users with paid seats who accepted their invitation — with the option to skip users marked away, and Enterprise capacity limits that make a rep ineligible once they hit their cap (HubSpot).
Those eligibility details are exactly where routing quietly breaks: a rep leaves, their seat is downgraded, and a rule that used to cover four people now covers three.
Round robin vs load balancing: the arithmetic
Here is a hypothetical example to make the difference concrete.
A team receives 250 inbound leads a week. Five reps handle them. Three work inbound full time and can realistically work 70 leads a week each. Two split their time with account management and can work 30.
Total capacity: (3 × 70) + (2 × 30) = 210 + 60 = 270 leads a week. Enough, on paper.
With round robin, each rep receives 250 ÷ 5 = 50 leads.
| Rep group | Assigned | Capacity | Result |
|---|---|---|---|
| 3 full-time | 50 each | 70 each | 60 unused capacity |
| 2 part-time | 50 each | 30 each | 40 leads never worked |
The math is perfect and the outcome is terrible: 40 leads a week go uncontacted while 60 slots sit empty. Nobody notices, because every dashboard shows an even distribution.
With load balancing, assignment follows open workload, so the full-time reps absorb roughly 70 each (210) and the part-timers take the remaining 40. Same team, same week, 40 more leads contacted.
The lesson generalizes: fair by count is not fair by capacity, and only one of them produces revenue.
Territories and branches
Multi-location businesses add a second axis: the lead belongs to a place, not just a person. MitHub's approach is to make the territory map a data table, not a set of nested rules.
One row per ZIP code (or city, region, country) with: assigned branch, backup branch, business hours, language, and whether the branch is live. Routing reads the table. When a branch opens, you add rows. When a branch is paused, you flip a flag and every lead flows to the backup automatically.
Nested if-then rules in a workflow builder become unmaintainable at around a dozen locations. A lookup table stays readable at two hundred, and non-technical operators can edit it without touching automation logic.
The rule that saves you: a default row that catches everything the map missed, pointing at a named human queue. An orphan is a lost deal; a mis-assigned lead is a five-second correction.
The SLA ladder
An SLA without escalation is decoration. MitHub writes it as a ladder where every rung fires automatically.
| Elapsed | What fires | Who is involved |
|---|---|---|
| 0 min | Lead assigned, owner notified, auto-acknowledgement sent to the lead | System |
| 5 min | First call attempt due | Owner |
| 15 min | No logged attempt → reassign to backup owner, notify both | System |
| 60 min | Still no attempt → return to central queue, alert the manager | System + manager |
| 24 h | No contact made → drop into the automated follow-up sequence, flag for review | System |
| Weekly | Every breach reviewed by source and by owner | Manager |
Two design notes. First, escalation must move ownership, not just send a reminder; reminders are ignored, reassignment is felt. Second, the after-hours rung matters more than the five-minute rung in most businesses: if 35% of your leads arrive outside working hours, an AI voice agent or an instant booking link is doing the work your SLA cannot.
Every assignment writes a receipt
Routing decisions are invisible unless you record them. MitHub asks for four fields on every routed record:
assigned_at— timestamp of assignmentassigned_by_rule— the rule name and version that matchedassignment_reason— human-readable, e.g. "ZIP 30143 → Jasper branch, primary"attempt_count— attempts logged since assignment
With these, "why did this lead go to Maria?" takes five seconds instead of a forensic session. Without them, every routing dispute becomes an opinion. This is the same principle as the data contracts that hold a CRM together: if a system changes a record, it says why.
The orphan audit
One query, every Monday, is the highest-leverage report in routing:
All records created in the last 7 days where owner is empty, OR no activity is logged and the SLA window has passed.
Count it. Chart it. Drive it to zero. Everything on that list is revenue the company paid to acquire and then did not touch. In MitHub's diagnose chapter this is one of the first things we look for, because it is usually larger than anyone expects and cheaper to fix than anything else on the list.
Test routing like an engineer
Routing runs in the seconds after a lead is created, which is the hardest moment to observe. Before you trust it:
- Send synthetic leads through every path: each territory, out-of-map, after hours, duplicate of an existing account, missing ZIP, missing phone.
- Measure the real latency. Documented platform behaviour will surprise you — HubSpot notes that rotating new contacts can take about ten minutes to process when contact-and-company owner sync is enabled (HubSpot). A five-minute SLA cannot sit on top of a ten-minute assignment step.
- Break something on purpose. Deactivate a test user and confirm their leads reroute instead of vanishing.
- Validate in the CRM, not the run log. A green automation run is not proof; open the record and confirm the owner, the timestamp and the reason.
- Keep a human in the loop for the exceptions that rules cannot resolve, and review those exceptions monthly for a new rule.
A 60-minute routing audit
Do this on any business you have access to:
- Export last month's leads with created date, owner, first activity date and source.
- Count records with no owner. That is your orphan rate.
- Compute median minutes from creation to first activity. Split it by hour of day — the after-hours gap is usually the whole story.
- Count reassignments per lead. Anything above one suggests overlapping rules.
- Compare leads received against leads actually worked, per rep. Uneven work with even counts means your distribution method is wrong.
- Write the five routing-contract answers on one page and show them to the sales manager. Where they disagree with reality is your build list.
Routing sits between scoring and contact in the revenue chain, and it is almost always the cheapest link to fix. The Faculty of Revenue Reverse Engineering walks through that chain end to end, starting with following the money so you can prove which link is leaking before you build anything.