Skip to content
SlashClone
DiscoverUse in ClaudeSubmit a link
Sign in
Made by@revopslab

Lead routing rules

@revopslab/lead-routing-rules

Design, test, and apply lead routing rules outside your CRM. Write ordered rules in a JSON file (existing-account match, partner, segment, region, junk filters), prove them with rule tests, then route a leads CSV with weighted round robin, out-of-office skips, and a fallback queue. Works with HubSpot, Salesforce, or any CSV.

SkillRevOpsv1.0.0 (latest)Tested
Use in Claude Save Like Clone Comment
Activity
New: be the first to try it
  1. 1---
  2. 2name: lead-routing-rules
  3. 3description: Design, test, and apply lead routing rules. Turns a plain-English routing policy (existing customers to their account owner, partner leads to the partner team, enterprise vs mid-market vs SMB, regions, junk and personal-email filters) into an ordered rules file with tests, then routes a leads CSV with weighted round robin, out-of-office skips, and a fallback queue. Use when the user says "set up lead routing", "who should get these leads", "test our routing rules", "route this list from the trade show", "why did this lead go to the wrong rep", or "rebalance round robin". Works with exports from HubSpot, Salesforce, or any CSV.
  4. 4license: MIT
  5. 5---
  6. 6
  7. 7# Lead routing rules
  8. 8
  9. 9Routing logic usually lives in a CRM workflow nobody can read. This kit keeps it in one small JSON file with tests, so you can see every rule, prove it works on sample leads, and route a list the same way every time.
  10. 10
  11. 11## When to use
  12. 12
  13. 13- Designing or changing routing (new segment, new rep, new region).
  14. 14- Routing a one-off list (event, webinar, purchased list) before import.
  15. 15- Debugging: "why did this lead go to X?" Run the lead through the rules and read the `rule_id` and `reason`.
  16. 16- Not for scoring leads, and not for writing into the CRM. Import the routed CSV yourself, or rebuild the tested rules in your CRM's workflow tool.
  17. 17
  18. 18## Inputs
  19. 19
  20. 20- **Rules** at `data/routing-rules.json` (start from the kit's `examples/routing-rules.json`).
  21. 21- **Leads** CSV at `data/leads.csv`. Any columns; rules refer to them by name, lowercased with spaces as underscores (`Lead Source` becomes `lead_source`).
  22. 22- **Accounts** CSV (optional) with a domain or website column and an owner column, for existing-account matching.
  23. 23
  24. 24## Rules file
  25. 25
  26. 26- `rules`: checked in order, the **first match wins**. Each has `id`, `when` (all must match) and or `when_any` (one must match), `assign` (`owner`, `pool`, or `queue`), and a `reason`.
  27. 27- Ops: `==`, `!=`, `in`, `not_in`, `>`, `>=`, `<`, `<=`, `contains`, `starts_with`, `ends_with`, `exists`, `missing`. Text compares ignore case. Numbers use the first number in the cell, so `201-500` employees counts as 201.
  28. 28- Built-in fields: `email_domain`, `is_free_email` (common personal email providers), `company_domain`.
  29. 29- `pools`: round robin groups with optional `weights` (`"Rep C": 2` gets twice the leads). `out_of_office`: people to skip.
  30. 30- Existing accounts are checked before all rules when `--accounts` is given (skip with `"account_match": false`). Personal emails never match an account.
  31. 31- `fallback`: where unmatched leads go. Default queue `unassigned`.
  32. 32- `tests`: sample leads with `expect_rule` and optional `expect_to` (owner, pool name, or queue).
  33. 33
  34. 34## Steps
  35. 35
  36. 361. **Design.** Ask for the routing policy in plain words, then write the rules file. Put specific rules (junk, existing accounts, partners) before broad ones (segments). Write one test per rule plus edge cases (missing size, personal email, employee ranges).
  37. 372. **Test.**
  38. 38
  39. 39 ```bash
  40. 40 node scripts/route.mjs data/routing-rules.json --check
  41. 41 ```
  42. 42
  43. 43 Every test must pass. If one fails, show expected vs actual and fix the rule, not the test, unless the user agrees the test was wrong.
  44. 44
  45. 453. **Route.**
  46. 46
  47. 47 ```bash
  48. 48 node scripts/route.mjs data/routing-rules.json data/leads.csv --accounts data/accounts.csv --state data/rr-state.json --out out --name routed
  49. 49 ```
  50. 50
  51. 51 Routing refuses to run while any rule test fails. `--state` keeps the round robin position between runs so the next list continues where this one stopped.
  52. 52
  53. 534. **Report** from `out/routed-summary.json`: leads per rule, per person, how many hit the fallback, and `unused_rules`. A rule nobody hit may be dead or ordered too late.
  54. 54
  55. 55## Output to the user
  56. 56
  57. 57```markdown
  58. 58Routed 10 leads. 5/5 rule tests pass.
  59. 59
  60. 60| Rule | Leads |
  61. 61| --- | ---: |
  62. 62| existing-account | 2 |
  63. 63| enterprise | 2 |
  64. 64| smb | 2 |
  65. 65| fallback | 1 |
  66. 66
  67. 67Per person: Rep A 2, Rep F 2, Rep B 1, Rep C 1, Rep E 1, Partner Manager 1.
  68. 681 lead hit the fallback (UnknownCo: no employee count). Unused rule: spam-or-test.
  69. 69File to import: out/routed.csv (adds routed_to, route_type, rule_id, reason).
  70. 70```
  71. 71
  72. 72## Guardrails
  73. 73
  74. 74- Never import or assign in the CRM. The user imports `out/routed.csv`.
  75. 75- Keep a test for every rule you add. Do not delete a failing test to make routing run.
  76. 76- Do not route on protected or sensitive attributes (age, gender, ethnicity, religion, and similar), even if a column exists.
  77. 77- Lead data is personal data. Summarize in chat; do not paste the CSV.
Sign in to comment on a line