lead-routing

{
  "skill_name": "lead-routing",
  "evals": [
    {
      "id": 1,
      "prompt": "Our inbound assignment rules at Halvard Systems are a mess and I'm rewriting them this week. The rule list in our CRM is literally: (1) round robin across all 22 AEs, (2) if employee count is 1000+ send to the Enterprise pool, (3) if the company is on our named-account list send it to the named owner, (4) if the account already has an owner send it there. Reps keep telling me leads land on the wrong people. We also sell into two German subsidiaries whose parent companies are owned by different AEs in our US book, and legal says leads from our German entity have to stay on EU infrastructure. Can you rewrite the rule list so it actually works, and give me something I can hand to our admin?",
      "expected_output": "A rewritten top-down, first-match-wins precedence ladder: legal/data-residency at the top, relationship and ownership tiers above attribute tiers, the round robin demoted below all eligibility rules, the parent/subsidiary conflict sent to a human-owned conflict queue, and the ladder terminated by a monitored catch-all triage queue. Delivered as a routing matrix of criteria, assignee and SLA in precedence order.",
      "files": [],
      "expectations": [
        "States that the rules are evaluated top-down and that the first matching rule wins",
        "Identifies that the round-robin entry at position 1 matches every lead, so the three rules beneath it never execute",
        "Places the German data-residency constraint at the top of the rewritten ladder, above the named-account rule",
        "Orders named-account ownership, open-opportunity ownership and existing-account ownership above the employee-count segment rule",
        "Moves the round robin below every eligibility rule instead of leaving it as a peer entry in the same ordered list",
        "States that the upper tiers decide eligibility and that the distribution step only picks a person inside the pool those tiers produced",
        "Routes the German subsidiaries whose parents have different owners to a human-owned conflict queue with a dwell timer, not to an automated rule",
        "Terminates the ladder with a catch-all triage queue rather than with the rotation",
        "Gives the catch-all a named owner and a same-business-day SLA",
        "Schedules a recurring catch-all review that converts repeated exception types into new rules",
        "Delivers a routing matrix listing criteria, assignee and SLA per row, in precedence order",
        "Does not present the ordering as a branded or named methodology, and invents no acronym for it"
      ]
    },
    {
      "id": 2,
      "prompt": "I'm the only ops person at Brennwick and I have three weeks before a big demand-gen campaign turns on. I have a list of routing rules I know we need eventually: legal and data-residency carve-outs, named accounts, open-opportunity ownership, existing-account ownership, territory by country and segment, language eligibility, capacity caps, the round robin itself, and something for leads that match nothing. I can't build all of it. Our lead-to-account match rate is sitting at 93%. What do I build first, and what can wait?",
      "expected_output": "A build-order recommendation that is explicitly different from the evaluation order: the catch-all triage queue first at roughly an hour of work, then existing-account ownership (gated on the match rate, which clears), then territory, with the non-negotiable legal, named-account and open-opportunity tiers excluded from the ratio entirely, plus instrumentation before any rule change.",
      "files": [],
      "expectations": [
        "Recommends building the catch-all triage queue first",
        "Prices the catch-all at roughly an hour of work",
        "Justifies catch-all-first because it turns silent drops into visible exceptions and is what makes the other tiers measurable",
        "Recommends existing-account ownership as the next build, ahead of territory",
        "Notes the existing-account tier depends on the lead-to-account match rate, and confirms 93% clears the roughly 90% floor",
        "Ranks territory below existing-account ownership, pricing it at about a week plus a standing maintenance job",
        "States explicitly that build order and evaluation order are two different orderings",
        "Keeps the evaluation ladder ordered most specific to most general and does not reorder it by efficiency",
        "Excludes the legal, named-account and open-opportunity tiers from the efficiency ranking because they are non-negotiable",
        "Recommends adding stage timestamps before changing any rules, because without them no change can be shown to have worked",
        "Does not recommend building the round-robin distribution variant first"
      ]
    },
    {
      "id": 3,
      "prompt": "Nordlite is B2B, about 1,400 inbound leads a month. We want to switch to account-based routing so everyone from the same company goes to one owner. Problem: when I checked last week only 72% of inbound leads actually matched to an account record, and roughly 9% of what comes in is a duplicate of a lead we already have. Sales leadership wants this live by the end of next month. Also, what's a normal misrouting rate for a company our size? I want a benchmark to put in the proposal.",
      "expected_output": "A refusal to design the account-based distribution before matching is repaired: the roughly 90% match-rate floor named, the 9% duplicate rate flagged against the roughly 5% tolerance, a domain-first then fuzzy-name matching sequence with realistic coverage figures labelled as estimates, and an explicit statement that no analyst-grade industry misrouting benchmark exists.",
      "files": [],
      "expectations": [
        "Blocks the account-based distribution work until the match rate is fixed, naming roughly 90% as the floor",
        "Flags the 9% duplicate rate as above the roughly 5% tolerance",
        "Prescribes standardizing an account-domain field",
        "Matches on email domain first and fuzzy company name second, in that order",
        "States that email-domain matching alone covers roughly 70% of lead-to-account matches",
        "States that fuzzy company-name matching adds roughly another 15-20%",
        "Labels those matching figures as vendor-adjacent estimates useful for sizing effort, not as a target to commit to",
        "Treats vendor claims of 95%+ match rates as marketing rather than a planning number",
        "Declines to supply an industry misrouting-rate benchmark, states that no analyst-grade one exists, and tells the team to measure its own rate instead",
        "Carries the match-rate floor into the pass criteria the routing design must meet before shipping",
        "Explains that below the floor leads leak before any rule runs, so distribution work would sit on broken input"
      ]
    },
    {
      "id": 4,
      "prompt": "Castellane Analytics, 3 AEs, all sitting in Chicago. Our VP of Sales wants weighted round robin: the new hire who started six weeks ago should get half the leads the other two get while she ramps. We need it live in 12 days because our campaign starts then. Our CRM doesn't track open-lead counts per rep, and honestly nobody owns the CRM - our marketing coordinator makes changes when she has time. Can you set this up?",
      "expected_output": "A recommendation for availability-checked straight rotation instead of the requested weighted rotation, with weighted and the heavier variants deleted from the proposal rather than deferred, the reasons tied to the missing governance owner, the team shape, the 12-day date, and the comp sign-off that a weighted rotation triggers.",
      "files": [],
      "expectations": [
        "Recommends availability-checked straight rotation as the design to ship",
        "Declines to build the weighted rotation as requested",
        "Names the absence of a weight-governance owner as a reason the weighted rotation is ruled out",
        "Removes the ruled-out variants from the proposal entirely rather than parking them as a later phase",
        "Notes that three reps in one timezone make skew self-correct, which removes the case for capacity-based and layered variants",
        "Notes that the 12-day date rules out any variant requiring a standing process to be stood up first",
        "Flags that a weighted rotation changes reps' earning opportunity and needs sales-leadership and comp sign-off before shipping",
        "Notes that a weighted rotation cannot be quietly reverted once reps know their own weights",
        "Attributes the largest available speed-to-lead gain to the availability check itself, which stops leads parking on absent reps",
        "Prices the rotation plus availability check at near-zero to about an hour, with no standing owner",
        "States that moving to a heavier variant should follow an observed failure condition in real data, never anticipation of one"
      ]
    },
    {
      "id": 5,
      "prompt": "I'm building the slide that justifies our new routing project to the board. The line I want is \"responding within 5 minutes makes you 100x more likely to convert (Harvard Business Review)\" and then \"21x more likely to qualify\". I also need a number for how much revenue faster routing will add - the vendor we're evaluating says 8x pipeline. Can you tighten this up and give me the citations so nobody on the board can poke holes in it?",
      "expected_output": "A corrected citation set: the 5-minute/21x/100x figures reattributed to the 2007 Lead Response Management study with its sample and scope, the HBR source correctly identified as the 2011 audit with its own figures, the word convert rejected, the vendor multiple refused, and the SLA anchored to the company's own response-time history.",
      "files": [],
      "expectations": [
        "Attributes the 5-minute, 21x and 100x figures to the 2007 Lead Response Management study (Oldroyd, MIT / InsideSales), not to Harvard Business Review",
        "Identifies the Harvard Business Review source as the 2011 study \"The Short Life of Online Sales Leads\", carrying the 7x, 60x and 42-hour figures",
        "States that the 100x figure is odds of contacting and the 21x figure is odds of qualifying, comparing 5 minutes against 30 minutes",
        "Rejects the word \"convert\" for these figures, noting the 2007 study explicitly did not address close ratios",
        "Gives the 2007 study's sample: 6 companies, over 15,000 leads and roughly 100,000 dials",
        "Flags the 2007 study as phone-era and dated",
        "Gives the 2011 audit's sample of 2,241 US companies and notes it is a behavioural audit, not a controlled experiment",
        "States that neither study observed a routing-stage timestamp, so they evidence response urgency and not routing ROI",
        "Declines to present the vendor's 8x pipeline claim as evidence, noting it carries no published methodology",
        "Recommends setting the response SLA from the company's own conversion-by-response-time history rather than from a published benchmark",
        "Records figure, source, year and sample for every statistic that stays in the deck"
      ]
    },
    {
      "id": 6,
      "prompt": "Marrowfield Group here. We're re-carving every territory at once - all 60 reps, every account changes owner on the same day, EMEA and NA both. There are about 30 accounts in EMEA with active partner deal registrations that must not get touched by direct reps. I want to push it live this Friday so it's in place for Monday. How do I do this without blowing up the quarter?",
      "expected_output": "A rollout plan that selects shadow mode over the default canary for this specific change, justified by the blast radius and the unrecoverable partner-registration exposure, preceded by a sandbox test-pack run on replayed historical leads, with a single-action rollback, pre-agreed rollback triggers, second-approver and change-log requirements, and a pushback on the Friday production edit.",
      "files": [],
      "expectations": [
        "Recommends shadow mode rather than a canary for this change",
        "Justifies it by the change moving ownership across every segment at once, so no canary can contain it",
        "Names the active partner deal registrations as the second condition: a wrong owner there is unrecoverable rather than merely embarrassing",
        "States that the canary is the default for ordinary routing changes and that shadow mode is the exception",
        "Describes shadow mode as computing the intended owner on live volume without writing it, then diffing intended against current behaviour record by record",
        "Requires a sandbox run of the synthetic test pack first, ideally replaying real historical leads from the last full week",
        "Rejects editing the assignment logic directly in production, and pushes back on the Friday ship",
        "Requires the previous rule set to be restorable as a single action, with the state it restores to known before shipping",
        "Lists rollback triggers agreed in advance, such as unexplained per-source volume loss, unassigned leads with no reason code, catch-all volume above its normal band, or skew outside the agreed variance",
        "Requires a second approver and a change-log entry recording the date, the tiers touched and the test-pack result",
        "Assigns communication of the territory change to affected reps to sales leadership, because it touches quota attainment"
      ]
    },
    {
      "id": 7,
      "prompt": "Something's wrong at Ombra Health and I can't see it. Our routing dashboard is green - every lead has an owner, no errors. But pipeline is down 30% this quarter. Two things I noticed: our partner-webinar source hasn't produced a single lead in eleven days, and leads created through our API integration show an owner but nobody has ever called them. Our web form leads seem fine. Where do I even start?",
      "expected_output": "A diagnosis aimed at silent routing failure rather than lead quality: alert-on-silence per source, a same-record test across every ingestion path, a hard-failure branch on null assignment, decision and write results split into separate fields, the full stage-clock chain with the acceptance gap, and an acceptance clock that reroutes unaccepted leads.",
      "files": [],
      "expectations": [
        "Adds per-source volume monitoring with alert-on-silence, noting that nothing in a standard CRM alerts on absence",
        "Names the eleven silent days as a failure that still reports green, rather than as a demand problem",
        "Suspects that the API ingestion path bypasses the assignment rules, rather than concluding the rule logic itself is wrong",
        "Prescribes pushing an identical synthetic record through every ingestion path and requiring the identical owner on each",
        "Adds a hard-failure branch that pages a named owner when assignment comes back null",
        "Separates the routing decision result and the CRM write result into different fields, so a failed write is distinguishable from a rule that never matched",
        "Adds the stage clocks: captured, eligible, decision, assigned, notified, accepted, first action",
        "Reports the acceptance gap, accepted minus assigned, as its own metric",
        "Adds an acceptance clock that reroutes to a named backup after a set interval with a logged reason code",
        "Distinguishes assignment as an owner-field write from routing as a person taking responsibility or a visible exception with a timer",
        "Does not conclude that lead quality or rep effort is the cause"
      ]
    },
    {
      "id": 8,
      "prompt": "Cobalt Rail is a self-serve developer tool - about 9,000 signups a month, 6 reps, all in Dublin. Our founder wants 24/7 follow-the-sun coverage so no signup waits, and he wants every single signup to get a human touch. Realistically maybe 20 signups a month ever turn into real deals; most are students and hobbyists. We do have a usage event that fires when someone invites 3 or more teammates. How should I build the routing?",
      "expected_output": "A high-volume coverage design that deletes follow-the-sun outright for lack of out-of-region headcount, replaces it with an after-hours queue plus instant auto-acknowledgment, leads with a no-touch floor that cuts the low-value segment out of sales entirely, then shift-based pools, and routes the teammate-invite signal to a rep with the signal attached.",
      "files": [],
      "expectations": [
        "Deletes follow-the-sun from the design rather than scheduling it for a later phase",
        "States that follow-the-sun is a hiring decision rather than a routing rule, given there is no out-of-region headcount",
        "Recommends an after-hours queue with instant auto-acknowledgment and a next-open-hours SLA as the replacement",
        "Recommends a no-touch floor as the first tier to build: an eligibility rule cutting the lowest-value self-serve segment out of sales entirely",
        "Justifies the no-touch floor by the volume it removes from every rule beneath it, which makes every later variant cheaper",
        "Refuses the \"every signup gets a human touch\" requirement, because the no-touch floor means part of the volume is deliberately never worked",
        "Places shift-based pools ahead of skills-based queues, and prices shift-based pools at about an hour over rosters the team already keeps",
        "Gates skills-based queues on language or product genuinely determining who can work the lead, and names the per-rep skill field somebody must keep current",
        "Routes the teammate-invite product-qualified signal to a rep within 24-48 hours of the trigger",
        "Passes the triggering signal itself to the rep alongside the assignment, not just a score",
        "Keeps the catch-all, the testing method and the measurement identical to the account-based motion, changing only the routing key and the coverage model"
      ]
    },
    {
      "id": 9,
      "prompt": "Pellier Loft here. We run inbound through two separate workflows in our CRM - one for demo requests, one for pricing-page form fills - and each has its own round-robin rotate step across the same 7 AEs. One AE ended up with 41% of last month's leads and the rest are furious. We also added the 7th AE at the start of last month. On top of that, our lead score is junk - can you re-weight it so enterprise-sized companies score higher while you're in there?",
      "expected_output": "An explanation that rotation fairness is counted per rotate action rather than across total ownership, so two individually fair workflows skew the total, plus the rotation reset caused by adding an owner, a consolidation to a single assignment path, a fairness-definition question before any change, measured skew, and a refusal to re-weight the scoring model here.",
      "files": [],
      "expectations": [
        "Explains that rotation fairness is counted per rotate action rather than across global ownership, so two individually fair workflows can produce a lopsided total",
        "Identifies the two separate workflows as the cause rather than a defect inside either rotation",
        "States that adding the 7th AE reset the rotation",
        "Recommends consolidating to a single assignment path so fairness is measured once across total ownership",
        "Asks what \"fair\" means to this team - equal turns, equal open workload, proportional share by ramp or tenure, or equal opportunity value - before changing the rotation",
        "Measures distribution skew per rep over a window rather than asserting the algorithm is fair",
        "Verifies skew over the observation window against the team's stated fairness definition instead of inferring it from the algorithm choice",
        "Considers gaming, such as disqualifying leads quickly to draw the next one, as a candidate cause alongside the workflow split",
        "Declines to re-weight the lead scoring model as part of this work",
        "Points to lead scoring as separate, dedicated work rather than folding it into the routing fix",
        "Uses the existing score only as a ranking signal for which eligible lead to work first, or as an eligibility gate"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "Design lead routing rules for our inbound leads", "should_trigger": true },
    { "query": "who should get this lead when it comes in?", "should_trigger": true },
    { "query": "our round robin is lopsided, one AE is getting way more leads than everyone else", "should_trigger": true },
    { "query": "leads are sitting in a queue nobody looks at", "should_trigger": true },
    { "query": "how do we make sure inbound leads get assigned to the right rep", "should_trigger": true },
    { "query": "set up territory assignment by country and company size", "should_trigger": true },
    { "query": "we need a lead assignment waterfall", "should_trigger": true },
    { "query": "what happens to a lead when nobody picks it up?", "should_trigger": true },
    { "query": "our enterprise leads keep landing on SMB reps", "should_trigger": true },
    { "query": "an existing customer filled out a demo form and got assigned to a random SDR", "should_trigger": true },
    { "query": "build a routing matrix for inbound", "should_trigger": true },
    { "query": "we're adding 4 new SDRs, how do we split the inbound between them?", "should_trigger": true },
    { "query": "how long should a rep have before we take the lead back and give it to someone else?", "should_trigger": true },
    { "query": "leads coming in through our API don't get an owner", "should_trigger": true },
    { "query": "three people from the same company filled out the form and three different reps called them", "should_trigger": true },
    { "query": "should we use weighted round robin or capacity based?", "should_trigger": true },
    { "query": "what do we do with leads that arrive at 2am", "should_trigger": true },
    { "query": "design the assignment logic for our new inbound motion", "should_trigger": true },
    { "query": "our catch-all queue has 400 leads in it", "should_trigger": true },
    { "query": "we re-carved territories and I need a safe way to roll it out", "should_trigger": true },
    { "query": "how do I test assignment rule changes before pushing them live", "should_trigger": true },
    { "query": "lead distribution across the team is unfair and reps are complaining", "should_trigger": true },
    { "query": "we want PQLs to go to a sales rep when someone crosses a usage threshold", "should_trigger": true },
    { "query": "help me decide who owns a lead when the subsidiary and the parent have different account owners", "should_trigger": true },
    { "query": "what SLA should we set for responding to inbound leads?", "should_trigger": true },
    { "query": "half our inbound never gets called", "should_trigger": true },
    { "query": "set up a fallback for leads that don't match any rule", "should_trigger": true },
    { "query": "our partner-registered accounts keep getting worked by direct reps", "should_trigger": true },
    { "query": "need a plan for splitting inbound between the SDR team and the AEs", "should_trigger": true },
    { "query": "we have no idea why a lead went to the person it went to", "should_trigger": true },
    { "query": "how should we handle leads when a rep is on PTO?", "should_trigger": true },
    { "query": "write the rules that decide which rep gets each new signup", "should_trigger": true },
    { "query": "leads with a blank country field are going to random people", "should_trigger": true },
    { "query": "we're switching from named territories to a pooled inbound model, what breaks?", "should_trigger": true },
    { "query": "figure out why some of our forms assign an owner and others don't", "should_trigger": true },
    { "query": "I need a fair way to hand out inbound demo requests", "should_trigger": true },
    { "query": "our speed to lead is 19 hours and I don't know where the time goes", "should_trigger": true },
    { "query": "can you help me split inbound by language for our EMEA team", "should_trigger": true },
    { "query": "what's the right order to evaluate our assignment rules in?", "should_trigger": true },
    { "query": "we want follow the sun coverage for inbound", "should_trigger": true },
    { "query": "leads are being assigned but the reps never accept them", "should_trigger": true },
    { "query": "how do we stop enterprise inbound from going into the general rotation", "should_trigger": true },
    { "query": "which rep should this demo request go to", "should_trigger": true },
    { "query": "our lead-to-account matching is bad and it's breaking assignment", "should_trigger": true },
    { "query": "our SDRs are cherry-picking the best leads out of the shared queue", "should_trigger": true },
    { "query": "design our lead scoring model weights", "should_trigger": false },
    { "query": "our MQL threshold is letting junk through, help me recalibrate it", "should_trigger": false },
    { "query": "backtest our lead score against closed-won deals", "should_trigger": false },
    { "query": "which fields should be required on the lead object and who owns each one", "should_trigger": false },
    { "query": "set freshness SLAs for our CRM fields", "should_trigger": false },
    { "query": "decide whether the CRM or the warehouse is source of truth for account records", "should_trigger": false },
    { "query": "audit our pipeline stage exit criteria", "should_trigger": false },
    { "query": "our forecast is always wrong, help me figure out why", "should_trigger": false },
    { "query": "flag the stale deals in our pipeline this quarter", "should_trigger": false },
    { "query": "design the handoff from sales to customer success after closed won", "should_trigger": false },
    { "query": "build a discount approval matrix for non-standard deals", "should_trigger": false },
    { "query": "which usage signals predict churn for our accounts", "should_trigger": false },
    { "query": "build a weighted customer health score", "should_trigger": false },
    { "query": "model our revenue funnel stages from first touch to closed won", "should_trigger": false },
    { "query": "where are we losing revenue between demo and close?", "should_trigger": false },
    { "query": "what KPIs should the board see each quarter", "should_trigger": false },
    { "query": "write the narrative for our Q3 board revenue deck", "should_trigger": false },
    { "query": "should we consolidate our sales engagement tools?", "should_trigger": false },
    { "query": "what should I learn to become a RevOps manager", "should_trigger": false },
    { "query": "write a job description for a sales ops analyst", "should_trigger": false },
    { "query": "which revops newsletters should I subscribe to", "should_trigger": false },
    { "query": "I'm starting a new revops project, where do I begin", "should_trigger": false },
    { "query": "set up routing in my Next.js app router", "should_trigger": false },
    { "query": "configure nested routes in React Router", "should_trigger": false },
    { "query": "how do I do declarative routing in Flutter", "should_trigger": false },
    { "query": "route traffic between two CloudFront distributions with Route 53", "should_trigger": false },
    { "query": "set up Vue Router navigation guards", "should_trigger": false },
    { "query": "TanStack Router best practices for typed route params", "should_trigger": false },
    { "query": "Angular routing with lazy loaded modules", "should_trigger": false },
    { "query": "build an API route in Expo", "should_trigger": false },
    { "query": "route customer support tickets to the right agent queue", "should_trigger": false },
    { "query": "design the on-call escalation rotation for our engineering team", "should_trigger": false },
    { "query": "assign code reviewers round robin on our pull requests", "should_trigger": false },
    { "query": "implement a round robin scheduling algorithm for my CPU scheduler assignment", "should_trigger": false },
    { "query": "route inbound support emails to the right shared inbox", "should_trigger": false },
    { "query": "plan delivery routes for our field service technicians", "should_trigger": false },
    { "query": "write the cold email sequence for the leads we just imported", "should_trigger": false },
    { "query": "how do I generate more inbound leads from paid search", "should_trigger": false },
    { "query": "build a lead magnet to capture more emails", "should_trigger": false },
    { "query": "compare data enrichment vendors for firmographic coverage", "should_trigger": false },
    { "query": "set commission rates and accelerators for our AEs", "should_trigger": false },
    { "query": "how many accounts should each AE carry for next year's quota plan", "should_trigger": false },
    { "query": "write the rules of engagement for channel conflict between partners and direct sales", "should_trigger": false },
    { "query": "configure webhook retries for our form submission integration", "should_trigger": false },
    { "query": "write the ICP definition for our outbound target account list", "should_trigger": false }
  ]
}

# Worked precedence ladder and routing matrix

Two worked examples of the same structure, one per motion, plus a negative example. Adapt the tiers to the attributes the team actually populates - a tier reading a field that is blank half the time is not a tier.

## B2B account-based variant

Company: 40 reps, four segment pools (Enterprise, Mid-Market, SMB, Partner), EMEA and NA coverage, named-account list maintained quarterly by sales leadership.

Routing matrix, in precedence order. First match wins; evaluation stops there.

| #   | Criteria                                                           | Assignee                                        | SLA               |
| --- | ------------------------------------------------------------------ | ----------------------------------------------- | ----------------- |
| 1   | Contact record resides in a data-residency-restricted region       | In-region pool, in-region infrastructure only   | 1 business day    |
| 2   | Company on the named-account list                                  | Named-account owner from the list               | 4 business hours  |
| 3   | Matched account has an open opportunity                            | Opportunity owner                               | 2 business hours  |
| 4   | Matched account has an existing owner                              | Account owner                                   | 4 business hours  |
| 5   | Matched account is a subsidiary whose parent has a different owner | Conflict queue (human-owned, 1-day dwell timer) | 1 business day    |
| 6   | Active partner deal registration on the account                    | Channel manager for review                      | 24 hours          |
| 7   | Employee count >= 1000                                             | Enterprise pool                                 | 4 business hours  |
| 8   | Employee count 100-999                                             | Mid-Market pool                                 | 4 business hours  |
| 9   | Employee count < 100, country in coverage                          | SMB pool                                        | 1 business day    |
| 10  | Requested language not covered by tiers 7-9                        | Language-eligible sub-pool                      | 1 business day    |
| 11  | Anything else                                                      | Triage queue, named owner                       | Same business day |

Within tiers 7-10, distribution is capacity-based (fewest open leads) with an availability check that skips reps who are out of office, past their open-lead cap, or outside business hours. That is rung 2.

This company earns rung 2:

- 40 reps across four pools
- an open-lead field already maintained
- a documented definition of when a lead stops counting as open

A ten-rep team with none of those ships rung 1 instead.

Two behaviours worth stating explicitly in the deliverable:

- All contacts from one account land on one owner. A buying committee submitting three forms in a quarter is one relationship, not three rotations.
- Tiers 1-6 are eligibility overrides driven by relationships and contracts. Tiers 7-10 are eligibility by attribute. Distribution only picks a person inside whatever pool those tiers produced.

## B2C / high-volume / PLG variant

Company: self-serve signup product, three shift-based pools (Americas, EMEA, APAC), a specialist team for the paid tier, no named accounts.

| #   | Criteria                                                                                         | Assignee                                           | SLA                             |
| --- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------- | ------------------------------- |
| 1   | Contact record resides in a data-residency-restricted region                                     | In-region pool                                     | 1 business day                  |
| 2   | User belongs to a workspace with an existing paying account                                      | Existing account owner                             | 4 business hours                |
| 3   | Product-qualified signal fired (usage threshold, teammates invited, paid-tier feature activated) | Product-led sales pool                             | 24 hours from trigger           |
| 4   | Self-reported deal size below the sales-touch floor                                              | No human touch; self-serve nurture                 | not applicable                  |
| 5   | Requested language has a dedicated sub-pool                                                      | Language sub-pool for the current shift            | 15 minutes in-hours             |
| 6   | Business hours in the contact's timezone                                                         | Regional pool for the current shift                | 15 minutes                      |
| 7   | Outside business hours everywhere                                                                | After-hours queue plus instant auto-acknowledgment | Next open hours, first in queue |
| 8   | Anything else                                                                                    | Triage queue, named owner                          | Same business day               |

Within tiers 5-6, distribution is availability-aware round-robin over reps currently on shift - rung 1, unchanged, because shift membership already does the workload narrowing a capacity field would otherwise buy. Note tier 4: the no-touch floor is the cheapest tier in this ladder and the one that shrinks every tier below it. Pass the triggering signal to the rep alongside the assignment - a bare score with no context is the documented reason sales teams distrust product-qualified leads.

Tiers 1-2 are identical in shape to the B2B ladder. The catch-all, testing method and measurement are identical for both motions. Only the routing key and the coverage model change.

## Negative example: a ladder that misroutes

```
1. Round-robin across all reps
2. Enterprise leads -> Enterprise pool
3. Named accounts -> named-account owner
4. Existing account owner
```

Every lead matches tier 1, so tiers 2-4 never execute. First match wins means the most general rule at the top swallows everything beneath it. Even reordered as 3, 4, 2, 1 the design still has two defects worth naming:

- No catch-all with a named owner. Tier 1 as a bare rotation hides no-match leads inside normal volume, so a lead with a blank country looks routed and is never investigated.
- Distribution sits in the same list as eligibility. Once a rotation entry can win against an ownership entry, an enterprise lead can land on an SMB rep and an existing customer can be assigned to a rep who has never spoken to them.

Order most specific to most general, keep eligibility above distribution, and terminate with a monitored triage queue rather than a rotation.

# Speed-to-lead and matching evidence

Read this before quoting any number to stakeholders. The routing literature is dominated by vendors selling routing, matching and scheduling software. Their descriptions of mechanics are reliable. Their statistics and return-on-investment claims are marketing.

## The two studies behind almost every quoted figure

**Lead Response Management Study (Oldroyd, MIT / InsideSales.com, 2007).**

- **Exact finding:** the odds of contacting a lead called in 5 minutes versus 30 minutes drop 100 times; the odds of qualifying a lead called in 5 minutes versus 30 minutes drop 21 times.
- **Sample:** 6 companies, 2004-2007, over 15,000 leads and 100,000 dials.
- **Scope:** the study explicitly did not address close ratios.
- **Credibility:** vendor-academic, robust for its scope, phone-centric and now dated.

**"The Short Life of Online Sales Leads" (Oldroyd, McElheran & Elkington, Harvard Business Review, March 2011).**

Audit of 2,241 US companies, response-time distribution:

- 37% responded within an hour
- 16% within one to 24 hours
- 24% took more than 24 hours
- 23% never responded

- **Average response time:** 42 hours, among companies responding within 30 days.
- **Qualification odds:** firms contacting within an hour were nearly seven times as likely to qualify the lead as those waiting one more hour, and more than 60 times as likely as those waiting 24+ hours.
- **Additional dataset:** a separate dataset in the same work covered 1.25M leads across 29 B2C and 13 B2B US companies.
- **Credibility:** the strongest source in the domain, and still a behavioural audit, not a controlled experiment.

- **2007 study:** the "5-minute", "21x" and "100x" figures.
- **2011 audit:** the "7x", "60x" and "42 hours" figures.

They are routinely mixed up and attributed to each other. Neither observed a routing-stage timestamp. No public study has. They are evidence that response speed matters, not evidence that a routing change produces a given revenue multiple.

## Other response-time benchmarks

| Finding                                                                                                          | Source                                                  | Year       | Sample                                        | Credibility                                                                                                                              |
| ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ---------- | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Median first phone response 3h08m; mean ~61 hours; 47% (4,472 of 9,538) never responded                          | InsideSales / XANT Lead Response Report                 | 2014       | 9,538 companies, secret-shopper method        | Vendor, but a large retrievable sample; among the most robust available                                                                  |
| 7% respond within 5 minutes; 55% not within 5 business days; ~42-hour average                                    | Drift lead-response audit                               | ~2017-2019 | 433 B2B companies                             | Vendor; sound real-form audit method, but the primary URL is offline and the study is routinely confused with a separate consumer survey |
| 63.5% never responded (365 of 1,000); average response among responders ~29 hours                                | RevenueHero                                             | 2024       | 1,000 B2B SaaS companies, mystery-shopped     | Vendor; transparent methodology; convenience sample, not randomized                                                                      |
| 74% miss the 5-minute window; teams with an SLA respond within 15 minutes 54.9% of the time versus 29.5% without | Blazeo Speed-to-Lead Benchmark Report                   | 2026       | 573 service-sector companies                  | Vendor; self-reported survey, so subject to self-reporting bias; service sector, do not generalize to software                           |
| 47-hour average; 23% within 5 minutes; 8x speed via AI routing                                                   | Optifai Pipeline Study                                  | 2026       | Claimed 939 B2B SaaS companies                | Vendor marketing with no published methodology and the same sample tag reused across unrelated pages; omit or flag strongly              |
| 84% of customers say the experience a company provides matters as much as its products                           | Salesforce State of the Connected Customer, 3rd edition | 2019       | 8,022 respondents, 16 countries, double-blind | Reputable large survey; the specific per-minute restatements circulating come from aggregators, not the primary report                   |

Two figures worth naming so they are not repeated uncritically:

- "78% of customers buy from the first company that responds" circulates through aggregators with no retrievable primary methodology. Treat as directional at best.
- The "391% conversion lift from responding within one minute" comes from a Velocify white paper analysing roughly 3.5 million leads around 2013, is mortgage and insurance skewed, and the original source link has rotted.

## Matching and distribution benchmarks

- Email-domain matching alone catches roughly 70% of lead-to-account matches, with fuzzy company-name matching adding another 15-20%. Vendor-adjacent estimate; use it to size effort, not to set a target.
- Vendors claim 95%+ match rates with fuzzy matching. Treat as marketing. What matters operationally is that the gap between 80% and 95% maps directly to leads misrouted or lost, which is why a match-rate floor belongs in the pass thresholds.
- One vendor case study reports a 74% improvement in match accuracy after adopting fuzzy matching. Single-customer, vendor-published, unverifiable.
- Only around 43% of B2B teams have any formal marketing-to-sales service-level agreement, per a vendor citing unnamed research. Directional only; no primary methodology is retrievable.
- No analyst-grade, industry-wide misrouting-rate benchmark exists. This is a genuine data gap, not something to fill with a vendor estimate. Measure the organization's own rate instead.

## How to use this with stakeholders

Set the response SLA from the organization's own conversion-by-response-time history whenever enough data exists - a single quarter of leads bucketed by time-to-first-touch beats any published benchmark, because it reflects the actual product, price point and buyer. Use the published research only to justify why speed is worth instrumenting at all.

Vendor benchmark URLs rot quickly, so record, at the moment of use:

- the figure
- the source
- the year
- the sample

A statistic without a retrievable primary methodology is directional, and should be labelled that way in the deliverable rather than dropped into a slide as fact.

# Synthetic test pack and rollout sequence

## The test pack

A fixed set of synthetic records, pushed through every ingestion path, with the expected owner written down before the run. The pack is an artifact that lives beside the routing matrix and is re-run on every assignment-affecting change.

One row per case:

| Case | Scenario                            | Input record                                        | Ingestion path | Expected owner                                     | Expected SLA          |
| ---- | ----------------------------------- | --------------------------------------------------- | -------------- | -------------------------------------------------- | --------------------- |
| P-01 | Named account, clean match          | Company on named list, all fields populated         | Web form       | Named-account owner                                | 4 business hours      |
| P-02 | Existing account, no opportunity    | Email domain matches an owned account               | Web form       | Account owner                                      | 4 business hours      |
| P-03 | Open opportunity on matched account | Domain matches, account has open opp                | API            | Opportunity owner                                  | 2 business hours      |
| P-04 | New enterprise company, in coverage | 2,000 employees, covered country                    | Web form       | Enterprise pool, capacity-based pick               | 4 business hours      |
| P-05 | Product-qualified signal            | Usage threshold crossed on a free workspace         | Product event  | Product-led sales pool                             | 24 hours from trigger |
| O-01 | Two tiers both match                | Named account that is also enterprise-sized         | Web form       | Named-account owner (higher tier wins)             | 4 business hours      |
| O-02 | Ownership vs rotation               | Existing account owner is at their open-lead cap    | Web form       | Account owner regardless of cap                    | 4 business hours      |
| B-01 | Blank routing field                 | Country empty, everything else populated            | Web form       | Triage queue, not a rotation                       | Same business day     |
| B-02 | Enrichment times out                | Segment field unresolved at decision time           | API            | Explicit missing-field branch, then triage         | Same business day     |
| B-03 | Duplicate of an existing lead       | Same email as an open lead                          | List import    | Existing lead owner, no second assignment          | unchanged             |
| H-01 | Subsidiary hierarchy conflict       | Subsidiary matched, parent owned by another rep     | Web form       | Conflict queue with dwell timer                    | 1 business day        |
| H-02 | Partner deal registration active    | Registered account arrives inbound direct           | Web form       | Channel manager review                             | 24 hours              |
| C-01 | Assigned rep out of office          | Eligible pool, next rep flagged OOO                 | Web form       | Next available rep in pool                         | unchanged             |
| C-02 | After-hours arrival                 | Arrives 02:00 in the contact's timezone             | Web form       | After-hours queue plus auto-acknowledgment         | Next open hours       |
| C-03 | Rep with no availability configured | Eligible pool, one rep never set availability       | Web form       | Not the silent fallback; explicit pool rules apply | unchanged             |
| X-01 | No rule matches                     | Country and company size both blank, unknown domain | Manual entry   | Triage queue, named owner                          | Same business day     |
| X-02 | Assignment write fails              | Valid decision, owner-field write rejected          | API            | Retry queue, decision logged separately from write | Paged to Ops          |

Run the same pack through each path the CRM can receive a lead on:

- web form
- API
- list import
- CRM sync
- chat or scheduling tool
- manual entry

An identical record must produce an identical owner on every path. A path that disagrees with the others is the single most common silent-drop cause, and it is invisible from a dashboard because both paths report a populated owner field.

Record the run:

- case
- path
- expected owner
- actual owner
- pass or fail

Keep the results alongside the change log entry.

## Rollout sequence

1. **Sandbox.** Load the pack plus edge-case records:
   - duplicates
   - incomplete fields
   - unusual attribute combinations

   Ideally replay real historical leads from the last full week. If a rule change cannot be tested against last week's inbound, it is not ready to ship.

2. **Canary, or shadow mode - a ranked choice, not an either/or.**
   - efficiency: canary > shadow mode
   - value: shadow mode > canary
   - effort: shadow mode (a week, plus a parallel compute path the CRM may not support) > canary (an hour, a scoping filter over one segment)

   Run the canary by default. Enable the new logic for one controlled segment (one region, one source, or one pool) and reconcile daily: count submissions at the source against records in the CRM, and confirm the difference is zero. Any unexplained loss triggers rollback rather than investigation-in-production.

   Shadow mode computes the intended owner on live volume without writing it, then diffs intended against current behaviour record by record. It sees every disagreement instead of only the ones one segment happens to exercise - some will be the intended fix, some new defects, and only a record-level diff separates them. That extra coverage is what the week buys.

   Shadow mode wins, despite the effort, on exactly two conditions:

   - the change moves ownership across every segment at once, so no canary can contain it
   - a wrong owner is unrecoverable rather than merely embarrassing: partner deal registration, contractual territory, a regulated-region carve-out

   Otherwise the canary's faster feedback beats the shadow's completeness.

3. **Full rollout.** Expand once the canary window shows no leads queue-owned past the acceptance SLA and no per-source volume anomalies.

**Approval and versioning:**

- propose the change as a ticket
- require a second approver for anything that changes who owns a lead
- record it in a change log with the date, the tiers touched, and the test-pack result

Sales leadership owns communicating a territory or fairness change to the reps it affects, because those changes touch quota attainment directly.

## Rollback plan

Keep the ability to restore the previous rule set as a single action, and know before shipping which state it restores to. Never edit assignment-affecting logic directly in production - a rule edited in production on a Friday is an incident waiting for Monday.

Rollback triggers, decided in advance:

- unexplained per-source volume loss
- any lead unassigned with no reason code
- catch-all volume rising above its normal band
- distribution skew outside the team's agreed variance

## Post-change monitoring

- Error alerts routed to a named owner, not a shared inbox nobody reads.
- Volume monitoring per source with alert-on-silence. Zero leads from a source on a Tuesday is a failure wearing a green checkmark; nothing in a standard CRM alerts on absence.
- Separate fields for the routing decision and the CRM write result. A correct decision followed by a failed write otherwise looks identical to a rule that never matched, which turns a one-minute query into an investigation.
- A weekly one-page report: speed-to-lead by stage, acceptance gap, never-touched count, catch-all volume and dwell, distribution per rep.
- A weekly catch-all review that converts recurring exception types into new rules, so the exception set shrinks instead of accumulating.

---
name: lead-routing
description: Design the assignment logic that routes inbound leads to sales reps - rule precedence and waterfall ordering, lead-to-account matching, territory assignment rules (geography, segment, industry, named accounts), round-robin variants (straight, weighted, capacity-based, availability-aware), fallback catch-all queues, SLA escalation and reassignment, and safe rollout of routing changes. Use whenever the user mentions lead routing, lead assignment, territory assignment, round-robin, lead distribution, "who gets this lead", a lopsided round-robin, or leads sitting unworked in a CRM queue - even if they never say "routing". Covers B2B account-based and B2C/PLG high-volume routing. Do NOT use for designing the lead score itself - use mbfinotti/revops-skills@lead-scoring instead.
license: MIT
metadata:
  author: Maya-Beth Finotti
  version: "1.3.5"
---

# 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.

7. 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.
8. 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](references/precedence-ladder-example.md) and [references/test-pack-and-rollout.md](references/test-pack-and-rollout.md).
9. 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](references/test-pack-and-rollout.md) for the ranking). Never edit assignment-affecting logic directly in production.
10. 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
11. 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.
- **Tiers 1-3, outside the ranking:** legal overrides, named accounts, and open opportunities are non-negotiable, so their ratio never decides anything.

## Distribution variants, ranked

Round-robin is a family of algorithms, each answering a different definition of "fair".

The most common configuration mistakes:

1. picking the wrong one for the team's definition
2. picking the most elaborate one

Rank them by what they actually deliver, speed-to-lead and the fairness reps experience (not the fairness the algorithm claims), against what they cost:

- admin configuration time
- the standing governance the rule needs
- the fields the CRM must already carry
- how hard the rule is to unwind once reps have adapted to it

- efficiency: availability-checked straight rotation > capacity-based > weighted > the layered stack
- value: the layered stack > capacity-based > availability-checked straight rotation > weighted
- effort: the layered stack > weighted > capacity-based > availability check == straight rotation
- compliance cost: weighted == the layered stack > capacity-based == availability check == straight rotation

- **Straight rotation ties with the availability check on effort:** both are pure configuration over data the team already keeps (a rotation list, and whichever OOO calendar it already trusts), with no new field and no standing owner.
- **Weighted ties with the layered stack on compliance cost:** both hand some reps more inbound than others by design. That changes earning opportunity, so it needs sales-leadership and comp sign-off before it ships, and it cannot be quietly reverted once reps know their own weight.

The other three carry no such exposure.

**Rung 1 - availability-checked straight rotation (the default).** Next rep in the rotation, skipping anyone out of office or outside business hours. Fair means equal turns among the people actually present.

- _You get_: the largest single speed-to-lead gain available here - no lead parked on an absent rep, which is the failure that kills leads outright rather than merely distributing them unevenly.
- _You owe_: near-zero for the rotation, about an hour for the availability check, no standing owner.
- _Fails when_: equal turns end in very unequal open-lead piles, or calendar presence gets mistaken for sales capacity.
- _Cheap upgrade_: where an open-lead count already exists, add a hard cap that skips reps above it. Near-zero, and it buys most of rung 2's protection without rung 2's standing referee.

**Rung 2 - capacity-based, still availability-checked.** Fewest open leads takes the next one. Fair means equal open workload.

- _You get_: skew measured in workload rather than turns, and visible relief for the rep buried in leads nobody noticed.
- _You owe_: an open-lead field the CRM maintains, about a week to agree what counts as an open lead, and a standing referee for when one stops counting.
- _Fails when_: "a lead" varies wildly in effort, so equal counts hide unequal work just as turns did.

**Rung 3 - weighted rotation.** Weight 2 receives roughly twice weight 1. Fair means proportional share by ramp, tenure, or role.

- _You get_: ramping and part-time reps protected - a narrow gain that only pays while someone is actually ramping.
- _You owe_: a standing weight-governance process (who sets weights, on what evidence, when they are revisited), plus the comp sign-off above.
- _Fails when_: nobody owns the review, and last year's ramp weights are still running as an unexamined performance judgment.

**Rung 4 - the full layered stack.** Eligibility narrows the pool, a capacity or weighted base allocates, an availability check sits on top. Fair means every definition at once.

- _You get_: the best achieved outcome of the four, and the only one that satisfies a team holding two fairness definitions simultaneously.
- _You owe_: all three costs plus the interactions between them - a standing job, and the least reversible option here.
- _Fails when_: nobody can explain in one sentence why a given lead went where it went, at which point the team cannot safely unwind it either.

Promote one rung only when the failure condition of the current rung is observed in the canary data, never in anticipation of it.

- Persistent open-lead pile-up promotes rung 1 to rung 2.
- A genuine ramp cohort promotes rung 2 to rung 3.

**What this order starves.** Rung 4 loses every round: highest value, highest standing cost, so a ratio never selects it.

Promote it anyway when all three hold:

- someone owns the CRM day to day
- more than one pool has genuinely different economics
- a fairness dispute is already on the table

A team of three reps that ships rung 4 has built a system it will not be able to change.

**Delete, do not demote.**

- A CRM with no open-lead field and no appetite to add one deletes rung 2 outright, and rung 4 with it. A demoted option silently reappears as scope three months later.
- No weight-governance owner deletes rung 3.
- Missing availability data is the exception: it deletes nothing, because the first thing to build is that availability source, not a rotation variant chosen around its absence.

**Re-rank against the answers.**

- A hard date promotes rung 1 and deletes rung 4: the standing process cannot be stood up before the deadline.
- A compounding-asset mandate promotes rung 2, because a workload field pays off as the team grows while a rotation list does not.
- An effort ceiling below "a standing job" deletes rungs 3 and 4 in one move.

This ordering is a default, not a law. It shifts with context and with who executes it, so re-rank it against everything already known about this user before proposing anything:

- an admin who owns the CRM full-time moves rung 4 within reach
- three reps in one timezone make skew self-correct and delete rungs 2-4
- an existing territory model already does most of the eligibility narrowing, which lowers what any distribution variant can add

## B2B vs B2C / high-volume / PLG

The ladder shape, catch-all design, testing method, and measurement are identical for both motions. What differs is the routing key and the coverage model:

- **B2B account-based**: route on account ownership first. All contacts from one account go to one owner - a buying committee submitting three forms must not hit three reps. Honor named-account carve-outs and partner deal-registration protection windows as hard overrides. A 24-hour SLA on target accounts is a common practitioner starting point.
- **B2C / high-volume / PLG**: route on geography, language, and coverage hours. Route product-qualified signals (usage threshold hit, teammates invited) within 24-48 hours of the trigger, and pass the underlying signal to the rep, not just a bare score. The coverage model itself is a ranked choice, below.
- **Mixed motions**: run both branches under one ladder - account-based tiers first, high-volume distribution as the general pool beneath them.

Coverage mechanisms for high-volume motions:

- efficiency: no-touch floor > shift-based pools > skills-based queues > follow-the-sun
- effort: follow-the-sun (a quarter, and a hiring decision) > skills-based queues (a week, then a standing skill matrix) > shift-based pools (an hour, over rosters the team already keeps) > no-touch floor (near-zero)

- **No-touch floor, first:** one eligibility rule cutting the lowest-value self-serve segment out of sales entirely is the highest-ratio move in the whole high-volume design. It costs a single tier, and it removes volume from every rule beneath it, so every later variant gets cheaper.
- **Shift-based pools, next:** buying in-hours coverage over rosters that already exist.
- **Skills-based queues:** pay only where language or product genuinely gates who can work the lead, and they need a per-rep skill field somebody keeps current.

Delete follow-the-sun outright when the team has no out-of-region headcount - it is a hiring decision wearing a routing rule's clothes, and demoting it invites someone to "phase it in". The after-hours queue with instant auto-acknowledgment (ladder tier 7) covers the same gap at near-zero cost and is what to build instead.

## Failure modes and fixes

Not ranked, deliberately: fix the symptom actually observed. Ordering symptom-driven repairs by ratio would be false precision.

Two rows are the exception, built before any symptom appears because their symptom is invisible by construction:

- per-source alert-on-silence
- the hard-failure branch on a null assignment

| Symptom                                                   | Likely cause                                                                                        | Fix                                                                                                                     |
| --------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| One ingestion path produces different owners than another | A path bypasses assignment rules (common with API-created records)                                  | Push the identical synthetic pack through every path; add a hard-failure branch that pages an owner on null assignment  |
| Leads match the wrong rule                                | Overlapping entries accumulated over time; earlier entry silently wins                              | Audit and merge overlapping conditions; version the rule set; re-document precedence after any two-rules-match incident |
| Rules misroute on blank fields                            | Stale or empty territory/segment data                                                               | Validate or enrich before routing, with a hard timeout and an explicit missing-field branch - never misroute silently   |
| Leads assigned to absent reps                             | No PTO/holiday skip logic; some platforms treat reps who never set availability as always available | Availability-aware rotation, coverage pools, a dedicated holiday rule for known periods                                 |
| Weekend/after-hours leads go cold                         | No timezone- or business-hours-aware branch                                                         | Follow-the-sun pools or an after-hours queue with next-open-hours SLA plus instant auto-acknowledgment                  |
| Reps dispute fairness                                     | Equal counts hiding unequal lead value; or gaming (insta-closing to draw more)                      | Transparent assignment logs; distribute high-score leads separately from the standard pool; monitor for gaming patterns |
| Catch-all quietly fills up                                | Manual overflow review that never happens                                                           | Named owner, same-business-day SLA, weekly review with teeth - recurring exception types become new rules               |
| Dashboards green, pipeline missing                        | Nothing alerts when a source goes silent                                                            | Volume monitoring per source; alert on silence, not just on errors                                                      |

## Measurement and pass thresholds

Decompose speed-to-lead into a chain of clocks: captured → eligible → decision → assigned → notified → accepted → first action. Report the acceptance gap (accepted minus assigned), the interval where queue dwell and failed notifications hide.

Track alongside it:

- never-touched-lead count
- distribution skew per rep
- lead-to-account match rate
- catch-all queue volume and dwell

The design must meet every threshold below before it ships. Iterate until it does:

- Lead-to-account match rate ≥ 90% on inbound volume; below that, return to matching before touching distribution.
- Every ingestion path covered by at least one test case, and the identical synthetic record produces the identical owner on all paths.
- Zero unmonitored queues: the catch-all (and any conflict queue) has a named owner, an SLA, and a scheduled review.
- During the canary period, zero leads queue-owned past the acceptance SLA, and per-source volume monitoring with alert-on-silence is live.
- Distribution skew within the variance the team's fairness definition allows, verified over the canary window - not assumed from the algorithm choice.

Set the response SLA itself from the user's own conversion-by-response-time history when it exists. The famous urgency statistics (the 5-minute / 21x / 100x figures) come from a 2007 InsideSales/MIT phone-era study and a 2011 HBR audit, are widely misattributed, and evidence urgency - not routing ROI. See [references/speed-to-lead-evidence.md](references/speed-to-lead-evidence.md) before quoting any number to stakeholders.

## Optional integration note

Skip this section unless the user names one of these platforms.

- **Salesforce:** one active lead assignment rule per object, entries evaluated top-down first-match. API-created leads skip the rule unless the assignment-rule header is set, and native territory management does not cover leads or round-robin.
- **HubSpot:** rotation fairness is counted per rotate action, not per global ownership, so two individually fair workflows can produce a lopsided total. Adding or removing an owner resets the rotation.
- **Dynamics 365:** sellers who never configure availability count as always available and silently become the fallback.

## Reference

- See [references/precedence-ladder-example.md](references/precedence-ladder-example.md) for a worked precedence ladder and routing matrix (B2B and PLG variants), plus a negative example.
- See [references/test-pack-and-rollout.md](references/test-pack-and-rollout.md) for the synthetic test pack template and the sandbox → shadow → canary rollout sequence.
- See [references/speed-to-lead-evidence.md](references/speed-to-lead-evidence.md) for citable speed-to-lead and matching statistics with source, year, and credibility flags.
- `mbfinotti/revops-skills@crm-data-governance` for field ownership and source-of-truth rules on the fields routing reads.