Lead Routing Rules Generator · Marketing Tool Stack

Most routing rules look fine in a slide and fall apart at 5pm on a Friday when the named rep is on PTO and three leads silently rot in a queue. This prompt forces every branch to have an owner, a timer, and a backstop.

What this isA copy-paste prompt that turns your territory map, segments, rep capacity, and SLA targets into an implementable routing decision tree for LeanData, HubSpot, or Salesforce.

You give itYour territories, segments, named-account list, rep pools with capacity, and SLA targets.

You get backA documented decision tree with assignment logic, fallback, SLA-breach reroute, an unrouteable holdout, and a test plan you can run before go-live.

Paste this into Claude, ChatGPT, or any capable model. Fill in the bracketed parts and it does the rest.

You are a RevOps architect who has shipped lead routing in LeanData, HubSpot, and Salesforce. I want a routing spec I can hand to an admin and build this week. Plain, deterministic, no hand-waving.

PLATFORM: [LeanData / HubSpot / Salesforce native]
CONTEXT: [B2B SaaS / your model], selling [product], deals routed to [SDRs / AEs / both].

TERRITORY MAP (use only what I give you, do not invent regions):
[e.g. NA East, NA West, EMEA, APAC. Include the field that decides territory, such as billing country or state, and how you handle blanks.]

SEGMENTS:
[e.g. Enterprise = 1000+ employees, Mid-market = 200 to 999, SMB = under 200. Name the field and source.]

NAMED ACCOUNTS:
[list of account names or domains that must override territory and go to a specific owner, or say "none"]

REP POOLS AND CAPACITY:
[per rep or pool: name, territory + segment they cover, daily/weekly lead cap, current open-lead load if known, working hours/timezone, out-of-office flag if any]

SLA TARGETS:
[e.g. first touch within 2 business hours for Enterprise, 1 business day for SMB. Define what "touched" means: status change, logged activity, or task complete.]

Build the spec in this exact order:
1. ASSIGNMENT DECISION TREE. Evaluate in priority order, most specific first: named-account override, then territory + segment match, then territory-only, then segment-only. At each node name the matching rule, the field it reads, and the destination (single owner or pool). For pools, state the method: round-robin for even pools, or weighted by remaining capacity when caps differ. Show the order of evaluation so two rules can never both fire.
2. CAPACITY HANDLING. For every pool, say what happens when a rep is at cap or out-of-office: skip and continue round-robin, or fall to the next-best pool. Never assign past a hard cap. If every rep in the matched pool is capped, route it in step 3.
3. FALLBACK. For every leaf that could end with no eligible owner (no territory match, no capacity, rep deactivated, blank routing field), name the explicit destination. No dead ends. Default to a named catch-all owner or a manager queue, never "leave unassigned".
4. SLA-BREACH REROUTE. For each segment's SLA timer: when it breaches, where does the lead go (next rep, manager, escalation queue), and does the timer reset on reroute. State the trigger mechanism for my platform.
5. UNROUTEABLE HOLDOUT. Define the holding queue for leads that match nothing or fail validation (no country, junk domain, missing segment field). Name the owner who reviews it and how often.
6. TEST PLAN. Give me 8 to 12 named test leads as a table, each targeting a specific branch including edge cases (named account in the wrong territory, capped pool, blank country, SLA breach, deactivated rep). For each: input fields, expected destination, and what proves it worked.

RULES:
- Build only from the territories, segments, and reps I gave you. If I left a gap or two rules conflict, STOP and list the gaps and conflicts as questions. Do not fill them with assumptions.
- Mark every assumption you do make in a separate "Assumptions" list at the top.
- Use my platform's real mechanisms and field names. If you need a field I have not named, ask.
Ask me your clarifying questions first, then produce the spec.

When to use it

When you are standing up routing for the first time, or your current rules leak leads, double-assign, or leave breached SLAs sitting with no reroute.

How to use it

Fill the brackets with your real territories, caps, and SLA definitions, answer the clarifying questions, then run the generated test leads in a sandbox before you flip it on in production.