Lead Routing

Lead Routing

Design the assignment logic that gets every inbound lead to a named owner who accepts it. No industry-named framework exists for this discipline - practitioners independently converge on the same de facto pattern: an ordered precedence ladder (also called a rule waterfall), evaluated top-down, first match wins, terminating in a monitored catch-all. Present it as common practice, never as a branded methodology.

Routing is not assignment.

• Assignment: a CRM owner-field write.
• Routing: the full chain from capture to a person taking responsibility, or the system raising a visible exception with a timer and an escalation path.

Most routing failure is silent:

• rules fire
• dashboards show green
• leads sit unworked in queues nobody owns

Lead score is strictly an input here, never a design target. Use the score the user already has as:

• a ranking signal: which eligible lead to work first
• an eligibility gate: route only above a threshold

Do not design or tune the scoring model itself. That is the sibling skill mbfinotti/revops-skills@lead-scoring.

Interview

• Ask before designing anything.
• One question per message.
• Offer multiple-choice options when possible.
• Skip a question only when the user already answered it.

• What creates a lead, and through which ingestion paths - web form, API, list import, chat, scheduling tool, CRM sync, manual entry?
• Which lead attributes are reliably populated at capture (country, company size, industry, email domain)? Which are often blank?
• What is the team shape - how many reps, in which pools (SDR, AE, segment teams, specialists), with what specialization?
• What are coverage hours and timezones? Is there after-hours or weekend inbound?
• Is the motion B2B account-based, B2C/high-volume, PLG self-serve, or mixed? Roughly how many leads per month?
• Do named-account lists, partner deal registration, or existing-customer carve-outs exist? Are they versioned anywhere?
• What does "fair" distribution mean to this team - equal turns, equal open workload, proportional share by ramp/tenure, or equal opportunity value?
• What response SLA exists today (if any), and is it measured?
• Any compliance constraints - data residency, consent requirements, regulated verticals?
• Is a lead score available as an input? What does it mean, and is it trusted?
• By what date must the new routing be live, and is that date hard or aspirational?
• Do you want a one-off fix to today's misrouting, or a distribution system that keeps holding as the team grows?
• What is the effort ceiling - admin hours available, whether anyone owns the CRM day to day, and whether the team will run a standing governance process (weight reviews, territory changes)?

The last three answers move the rankings in this skill, not just the timeline. Re-rank against them before proposing anything - see Distribution variants for which answer moves which option.

Workflow

1. Run the Interview; collect the answers the design depends on before proposing rules.
2. Instrument before touching rules: add stage timestamps (captured, eligible, decision, assigned, notified, accepted, first action). Without them, nothing proves a routing change worked.
3. Fix lead-to-account matching before distribution. Standardize an account-domain field. Match on email domain first, fuzzy company name second. If the match rate is under ~90% or duplicates exceed ~5%, leads leak before any rule runs - clean first.
4. Write the precedence ladder (next section) top-down, most specific to most general, and version it as a document. Eligibility tiers decide who may own the lead. Distribution only chooses within the eligible pool.
5. Choose the distribution variant by first writing down the team's definition of "fair", then taking the highest rung the team's answers actually support - default rung 1, availability-checked straight rotation (see Distribution variants).
6. Design the catch-all as a real state, a monitored triage queue with:

• a named owner
• a same-business-day SLA
• a weekly review that converts recurring exceptions into rules

Designed here, shipped first - it is the top of the build order in The precedence ladder, ahead of every rule above it.

1. Add the acceptance clock: if a lead is assigned but not accepted or touched within N minutes, reroute to a named backup with a logged reason code. Keep the decision result and the CRM write result in separate fields, so a failed write is distinguishable from a rule that never matched.
2. Produce the routing matrix (criteria → assignee → SLA, in precedence order) and a synthetic test pack covering every rule, every overlap, and every ingestion path - see references/precedence-ladder-example.md and references/test-pack-and-rollout.md.
3. Test in a sandbox with the pack, ideally replaying real historical leads; then roll out through a canary segment with daily reconciliation and a rollback plan, reserving shadow mode for changes a canary cannot contain (see references/test-pack-and-rollout.md for the ranking). Never edit assignment-affecting logic directly in production.
4. Validate against the pass thresholds in Measurement below. Iterate on rules, matching, or coverage until every threshold holds. Present the finished design for user approval, section by section:

• routing matrix
• test pack
• monitoring plan

1. If your harness has persistent memory, memorize the approved ladder, fairness definition, and thresholds - a later change request starts from them instead of re-interviewing.

The precedence ladder

Order rules top-down; first match wins. A defensible default ordering, adapted to what the user actually has:

1. Legal/regulatory/contractual overrides - data residency, consent constraints, contractual partner rights. Deterministic and versioned, never inferred.
2. Named-account or strategic ownership, from a versioned list.
3. Open opportunity or active commercial process on the matched account.
4. Existing account and hierarchy ownership - route to the relationship owner, not the next in rotation.
5. Territory boundary - geography, segment, industry, in whatever combination the team uses.
6. Product, skill, or language eligibility.
7. Capacity and availability - open-lead caps, PTO, business hours.
8. Fair allocation - the chosen distribution rung, within the pool tiers 1-7 produced.
9. Governed exception - the monitored catch-all triage queue.

Two structural rules:

• Tiers 1-6 define eligibility; tiers 7-8 only distribute within it. Mixing the two is how enterprise leads land on SMB reps.
• Hierarchy conflicts (a matched subsidiary whose parent is owned by a different rep) route to a human-owned conflict queue with a dwell timer, never to an automated rule.

This list is deliberately not ranked by efficiency, and never gets reordered by it. It is an evaluation order - most specific first, first match wins - so any efficiency reshuffle changes which rule fires, not which rule to build first.

Build order does rank, and it is a different order from the one above:

• efficiency (build order): tier 9 catch-all > tier 4 existing-account ownership > tier 5 territory > tier 6 product/skill/language > tiers 7-8 distribution
• effort (build order): tier 5 territory (a week, then a standing job) > tier 6 (a week, plus a per-rep skill field) > tier 4 (a week, gated on match rate) > tiers 7-8 (see Distribution variants) > tier 9 (an hour)

• Tier 9 catch-all, first: an hour of work turns every silent drop into a visible exception, and it is the only tier that makes the others measurable.
• Tier 4 existing-account ownership, next: it prevents the most damaging misroute, a current customer handed to a rep who has never spoken to them, but it is worthless below a 90% match rate, so fix matching first.