lead_routing v1.0.0

name: "lead_routing" description: "Route inbound leads to the right owner: ordered first-match rules by account ownership, segment, territory, and intent, weighted round robin with availability and capacity caps inside each pool, speed-to-lead SLAs by intent, a fairness audit, and a misroute fix that preserves context and the original clock. Use when someone asks to design, fix, audit, or explain lead routing or assignment rules, set up round robin, or stop leads going to the wrong rep or sitting unowned. For scoring which leads deserve sales time use lead_scoring; for researching one named account use lead_intelligence."

Lead Routing

Purpose

Lead routing decides which person gets a new lead, how fast they hear about it, and what happens when they do not act. Bad routing is quiet damage: a demo request lands with a rep on leave, an existing customer gets a cold first call from a stranger, a high intent lead waits in a shared queue while a low intent download gets worked first.

This skill ships a method, a working router at bin/route.py, and worked tables in references/routing-tables.md. The router is tool neutral. The same ordered rules translate into Salesforce assignment rules, a HubSpot rotation workflow, or a standalone script. Design the rules once, on paper, before building them in any one tool.

Two platform facts shape the design. Salesforce assignment rules evaluate entries in order and stop at the first match, and only one assignment rule per object can be active at a time. HubSpot rotation distributes records across a set of owners and can restrict assignment to available users, but the owners in the rotation need the right paid seats. In both cases the rule order you choose is the routing policy, whether you wrote it down or not.

Workflow

1. Put ownership before rotation

Order the rules like this, first match wins:

1. Existing account owner. A lead from a company that already has an owner goes to that owner. Never let a rotation overwrite an existing relationship.
2. Open opportunity or named account. A lead tied to a live deal or a named target account goes to that owner or pool.
3. Segment, territory, language, or product match. Enterprise, midmarket, and small business leads usually need different reps, and a territory or language mismatch is a real misroute, not a preference.
4. Intent and source inside the segment. Demo and contact requests outrank content downloads and event scans. Partner referrals get the path agreed with the partner.
5. Round robin inside the correct pool only. Rotation is the fallback for unowned, matched leads, not the whole policy.
6. A monitored fallback. Anything unmatched goes to a queue a named person checks daily. A fallback that nobody owns is where leads die.

Keep the rule count small. Add a rule only when a misroute pattern repeats, and log every change with date, before, after, and reason.

2. Build pools, weights, availability, and caps

Group reps into pools by segment or territory, one pool per routing destination. Inside a pool:

• Use plain round robin when reps have similar capacity and deal size.
• Use weighted round robin when capacity or seniority differs. A rep at half capacity gets weight 1 against full capacity weight 2. Weights are a capacity statement, not a reward.
• Skip unavailable reps automatically. Leave, away status, and outside-hours arrival should move the lead to the next available rep, not wait in an inbox.
• Set a capacity cap per rep. At cap, the router skips them. If the whole pool is capped or away, route to the monitor queue and flag it the same day.
• Decide in advance whether partner, event, and self-sourced leads count toward rotation totals, and write that decision down.

3. Set speed-to-lead targets by intent, with a consequence

Response speed is the part of routing with hard research behind it, and the research needs honest handling:

• A 2011 Harvard Business Review audit of 2,241 US companies found firms that tried to contact a web lead within an hour were nearly 7 times as likely to qualify it as firms that waited longer, and the average first response was 42 hours. It measured qualifying, not closed sales.
• A 2007 lead response study by Oldroyd and InsideSales, covering about 15,000 leads at six companies, found calling within 5 minutes instead of 30 made contact about 100 times more likely and qualification about 21 times more likely.
• A 2017 Drift test of 433 B2B companies found only 7 percent replied within five minutes.

Set targets from intent, for example: 5 minutes for demo and contact requests, 15 to 30 minutes for partner and event leads, 1 hour for content leads, all inside business hours, with an after-hours rule stated plainly. Pair every target with a consequence: at breach, notify the manager and reassign to the next available rep in the pool. A target with no consequence is a wish. Do not repeat the popular claim that most buyers pick the first responder as a measured fact: no traceable original study for it was found while researching this skill.

4. Run the router on a real list before trusting it

Write pools and rules in one JSON config following references/config-example.json, then route a lead export:

bash
python3 ~/workspace/skills/lead-routing/bin/route.py route \
  --config references/config-example.json \
  --leads references/leads-example.csv --out routed.csv

Read the output by hand. In the worked example, ten leads cover every path: one goes straight to its existing account owner, one named account lead jumps the content rule because named account sits higher, midmarket demo leads split 2 to 1 by weight while a rep on leave gets none, and one unmatched event lead lands in the monitor queue instead of vanishing.

Then audit distribution and check the clock:

bash
python3 ~/workspace/skills/lead-routing/bin/route.py audit \
  --routed routed.csv --config references/config-example.json
python3 ~/workspace/skills/lead-routing/bin/route.py sla \
  --routed routed.csv --now 2026-10-13T16:00:00

The audit compares each owner share against the weighted expected share and flags deviation over 0.15 by default. Judge it on a week or a few hundred leads, not a handful. The SLA check lists every lead past its first-touch deadline with no recorded first touch.

5. Fix misroutes without losing the lead

When a lead lands wrong:

1. Verify it is a misroute against the fields and rule order at routing time, not against who wants the lead.
2. Reassign with full context: source, intent, notes, and time already elapsed. The SLA clock does not reset.
3. Fix the cause in this order: bad field data, a rule ordered too broadly, wrong pool membership, then a one-off override with no rule change.
4. Log the rule change and search for sibling leads that matched the same pattern.

Full procedure and worked tables are in references/routing-tables.md.

6. Review the system weekly

Track four numbers: routing speed from submission to assignment (under 60 seconds is a sane target for automated routing), first-touch time by intent tier, acceptance rate by pool (below 70 percent accepted and worked points at routing or scoring, not rep effort), and conversion by route type. Review breaches by pool before blaming a rep: a pool-wide miss is a staffing or target problem.

Output Contract

Deliver, in this order:

• The ordered rule list, first match first, with the condition, destination pool or owner, and SLA for each rule.
• The pool table: members, weights, availability handling, and capacity caps, plus the written decision on whether partner and event leads count toward rotation.
• The SLA table by intent, with the breach consequence and the after-hours rule.
• The routed output or audit result when data was run: owner counts, audit flags, and SLA breaches, with the config and lead files named.
• The misroute and change log format the team will keep.

Operating Rules

• Ownership beats rotation, always. No rule may overwrite an existing account owner to satisfy a fairness count.
• Every lead ends with a named owner or a monitored queue with a named checker. Unowned is a failure state, not a routing outcome.
• The SLA clock starts at lead creation and never resets on reassignment.
• Weights describe capacity and availability, not performance rewards. Changing a weight is a policy change and gets logged.
• Cite speed-to-lead research with what it actually measured (contact or qualification) and its age. Cut any statistic you cannot trace to a study.
• Test every path with test leads before go-live, including the fallback, the unavailable rep, and the capped pool paths.
• Keep personal data in lead files to what routing needs. Do not add fields to a routing export just because the CRM has them.

Available connectors

• Use muse.connector_search to find other connectors and muse.skill_search to find related skills.

• If nothing here fits, look on the web for a maintained API or MCP server and set it up with Custom Connectors and MCPs, or build a custom connector.