Playbook · Lead Routing

The Lead Routing playbook.

Everything an architect or engineer needs to run one of these projects end-to-end — Blueprint → Build → Enable → Maintain. Get every lead to the right rep before it goes cold, and prove it with speed-to-lead. Start with the five-minute audio brief, then copy the prompt and open the repo.

4Phases
5Routing models
1 hrCore discovery
Pairedwith Speed-to-Lead
Watch or listen first · 5 min

The audio brief.

One narrator, five minutes, the whole shape of the project — now with the deck that runs alongside it. Play it before you open anything else; it's the fastest way to get into the right mindset for a routing build. In a hurry? Change the speed under the deck — it sticks next time.

0:00 / 0:00
Speed
1 / 1
Chapter 1 Narrated brief · generated with ElevenLabs · Download ↓
Chapters
The whole idea

Routing is two layers, not one — classify the lead, then match it to a rep — and you never ship it without speed-to-lead. If you can't measure how fast a lead moves, you can't tell whether the routing works.

The Shape

Four phases, one motion.

Every Lead Routing project moves through the same four phases. Know what you produce in each one.

1
Blueprint
Pick the routing model, map the channels, lock the prerequisites — territories, accounts, scoring — and set S.L.A.s by source.
OutputApproved routing map + SLAs
2
Build
Pick the tool tier, configure the engine, fix enrichment timing, stand up speed-to-lead, and prove it with a 25-scenario test.
OutputLive routing + STL dashboard
3
Enable
Ship the flowchart, document what changed, and set each rep's lane so the team becomes your monitoring layer.
OutputA team that flags misroutes
4
Maintain
Revisit on change and on a clock. Catch the silent process changes before leads quietly go nowhere.
OutputRouting that stays true
Start Here

Kick off a project in one paste.

Don't dig through the GitHub repo. Copy this prompt, drop in the customer name, and send it to your Claude. It clones the template, reads the AGENTS.md, and walks the checklist with you.

paste into Claude 
# Lead Routing — kick off
Clone the LeanScale Lead Routing template repo for my customer [Customer Name].

Then read AGENTS.md and run the kickoff checklist:
  1. Confirm access to the connected systems (Salesforce / HubSpot / LeanData / Traction Complete).
  2. Pull current routing rules, lead sources, segments, enrichment providers, and rep coverage.
  3. Draft the routing map — model, channels, prerequisites, and the S.L.A. by source.
  4. Stand up the speed-to-lead timestamp fields and generate the 25-scenario test CSV.

Ask me anything you need before you start.

What you get

A customer-specific repo

The clone becomes part of the customer's brain — every routing rule, S.L.A., and segment definition from this project informs their agent going forward.

Inside it

Skills + an AGENTS.md

Per-tool build skills (LeanData, Traction Complete, native SF & HubSpot), the speed-to-lead field pack, the test-scenario generator, and the checklist that makes kickoff a guided walkthrough.

1
Phase 1

Blueprint.

Figure out how leads actually flow before you touch a single rule. Read their systems, name their model and their channels, then map it to our standard. Unlike a full re-platform, A.I. can't quantify most of this — it's a customer-driven conversation plus a bit of homework on their side.

1.1 · The Mental Model

Routing is two layers.

A lead comes in and first hits a classifier — what kind of lead is this? — which hands it to the right engine, and only then does the engine's own matching logic pick the rep. Every routing decision lives in one of these two layers. Keep them separate in your head and the whole thing gets simpler.

The routing pipeline
Lead / Contact
EntryLead in→ ForceSync→ Wait forEnrich→ Layer 1Classify→ Layer 2Match & assign→ SLA clock
Classify by → Segment Territory Target account Channel / source

Enrichment sits before the classifier for a reason (see §2.2) — route on missing data and you'll assign a whale to a commercial rep. The S.L.A. clock is where speed-to-lead starts measuring.

1.2 · The Standard

The five routing models.

Nearly every company runs one of these — or a blend. Name theirs first; it decides everything downstream, including which tool you'll need. More complexity in the blend = more tool (see Build).

Model 01

Round robin

Next available rep. Best for velocity / speed-to-lead segments where getting to the lead first beats getting to the perfect owner. Works the same at 10 reps or 50.

Model 02

Territory

Route by location, company size, or industry. Each territory owns its own path. Prereq: the territories and their owners have to be defined.

Model 03

Target account / ABM

Heavy account scoring so quality gets spread, not just quantity. This is Port Knox — purely target-account, scoring-driven. Prereq: the scoring has to be in a good place.

Model 04

Hybrid

A blend of the above — the SpyCloud shape: business units, white-label alliance partners with their own teams, territory by firmographics, and everything else dumped to an S.D.R. queue.

Model 05

Manual

The honest fallback. When complexity outruns the tooling (or enrichment keeps misfiring), teams route by hand — Harbinger shut automation off entirely. Design so they don't have to.

Overlay

Segment & pods

On top of any model: SMB / mid-market / enterprise / whale, with reps in pods that lead from S.D.R. into A.E. SpyCloud moved the segment cut from ARR to company size.

Discovery question

Everything starts with four questions: What are you doing today? Is it working? What's working and what isn't? Which model are you actually after? The answers are the blueprint.

1.3 · Discovery

One hour, the right people, done.

Discovery here isn't a workstream — it's a meeting. Ask the client who should be in the room and who will have opinions, then get them together and hash it out.

1
Get the right people in the room
Sales ops from their side, S.D.R. managers, sales managers, and maybe a V.P. over the process. That's usually the whole cast — more than that is often too many.
2
Establish the model and the channels
Which of the five models? Which channels feed it — source, events, partner, government? Report every funnel separately and combined.
3
Get their homework
The mapping and routing table is theirs to provide — who owns what, what score sends a lead where. A.I. can't invent this; it comes from the business.
4
Set expectations on change
Land it here first: routing is not set-it-and-forget-it. When their process changes, they have to tell us — this is the single biggest source of downstream headaches (see Maintain).
1.4 · The Gate

Don't kick off without these.

Like a CPQ build needs pricing & packaging first, routing has hard prerequisites. Definitionally: you must know what puts each lead into each bucket before you can build or even recommend.

By model · what must exist
  • Territory model → the territories and who owns each one
  • Target account → the target-account definitions, ready to go
  • Scoring component → the score must be dialed in and trusted
  • Segments → the SMB / MM / ENT / whale cut, and where the line sits
Always · regardless of model
  • An enrichment source that reliably populates the routing fields
  • A clear S.L.A. by lead source — what "fast enough" means per channel
  • The rep roster & coverage — who's live, who's out, who's the fallback
  • The rules of engagement for events and partners (§1.5)
1.5 · The Channels

Every channel can need its own path.

This is where routing gets weird — and where the surprises hide. Surface all of it in discovery.

Channel

Lead source

A demo request and a cold ZoomInfo list are not the same S.L.A.. Track the original source; higher-value sources get tighter response windows and, sometimes, their own team.

Channel

Events

Relationship-driven. If a rep worked that booth, the lead may be theirs regardless of the CRM. SpyCloud splits federal events vs. trade shows vs. hosted — event type routes differently.

Channel

Partner

Nail the rules of engagement: is the partner working the lead directly, or just attached via a deal-reg object as backup while the account stays with the A.E.? SLAs change either way.

Channel

FedRamp / gov

"Good old Uncle Sam." Often a whole separate world. Prefer one instance with role-based access (no fed role, no visibility) over a second CRM — a dual instance is a nightmare. Watch the domains.

Chainguard vs. Human

Human ran a separate FedRamp instance and it was painful. Chainguard consolidated into one with role-based access control — fed data invisible unless you're a system admin. The only hard part left is identifying every government domain (SpaceX-style edge cases you won't see coming).

The Deliverable

The routing map the client signs off.

Blueprint outputs a flowchart — the single most important enablement artifact on the whole project. Something comes in, we check the country and firmographics, enrichment runs, and here's exactly where it lands. Draw it as a flowchart on purpose: LeanData itself is a flowchart, so the day the team opens the tool it already feels familiar.

Example · a hybrid routing map
Client-facing flowchart
InNew lead→ ImmediateForce sync to CRM→ BlockingEnrich (firmographic)→ DecisionClassify
Then route → Gov? → Fed instance / role Event? → the rep who worked it Partner? → deal-reg + A.E. Target acct? → named owner Else → territory / round robin
On assign → Start S.L.A. clock Notify rep Out of office? → fallback rep

Each engagement's map looks a little different — this is the reference shape. Feed it to Claude as the pattern, then upload the finished flowchart to the client hub where they comment and approve.

2
Phase 2

Build.

Pick the tool tier for their complexity, wire the engine to the approved map, get enrichment timing right, and stand up speed-to-lead alongside it. Then prove the whole thing with a test set before a single real lead flows through.

2.1 · The Tool Ladder

When to upgrade to a big-boy router.

It's complexity that drives the tier, not team size — a pure round robin works with 10 reps or 50. The trigger to move up is when you need to combine models on different buckets of criteria.

The ladder
Low → high complexity
Tier 0Native SF / HubSpot / Marketo→ Tier 1Qualified · chat→ Tier 1Chili Piper · scheduling→ Tier 2Traction Complete→ Tier 2 · LeanData

Native handles one motion / one bucket of criteria. The second you want territory and round robin and target accounts and government at once, move to a real router.

Tier 2 · the Rolls Royce

LeanData

The most robust; handles most or all complex routing logic. Flow Builder ≈ Salesforce Flow, so engineers pick it up fast. Version history like SF flows — revert in a click.

Tier 2 · SLA-smart

Traction Complete

Set working hours per rep and it does business-hours S.L.A. math for you. Robust path history to diagnose exactly where a record went wrong. Running well at Port Knox.

Tier 1 · chat

Qualified

Chat-based routing with a native router (we use it). Enough on its own for a SpyCloud-scale shop; a Clio needs more — it comes down to user count and form real-estate.

Tier 1 · scheduling

Chili Piper

Scheduling & inbound speed-to-lead. Lighter LeanScale reps today — scope it where the customer already runs it rather than leading with it.

Integration note

Routers like Qualified need forms channeled through them via scripting — real upfront work when a customer has a lot of form real-estate (Anrock runs ~1,000 forms). Worth it when the volume justifies it.

2.2 · The Biggest Gotcha

Enrichment timing beats everything.

If you rely on enrichment to populate the fields that drive routing, that enrichment must finish before the route fires. Get this wrong and nothing else matters.

The enrichment race · Port Knox

Routing fired before ARR / employee-count landed. Missing data read as $0, and commercial was the fallback bucket — so enterprise accounts got assigned to commercial reps. Five minutes later enrichment returned "$10M ARR," the account should've been enterprise, and the reps were fighting: "you have one of my accounts" / "it was assigned to me." Sequence enrichment ahead of the classifier.

The sync clock · force it

HubSpot syncs immediately on form fills, but everything else follows the standard 15-minute sync. If the team wants to call within 5 minutes, you can't wait — force the sync (add to a campaign / fire a routing rule that pushes into the CRM now). Same story with Marketo: force it rather than waiting for the standard process.

2.3 · Speed-to-Lead

Instrument the handoff — every time.

Speed-to-lead is a prerequisite for routing, not an add-on. Without the timestamps you can't answer the only question that matters: is a lead getting to a rep, and then to a human touch, fast enough? Stamp every hop.

The speed-to-lead timestamp chain
Lead / Contact · date-time fields
t0Created in HubSpot→ t1Sync attempted → SF→ t2Created in Salesforce→ t3Assigned (SDR / AE)→ t4 · First outreach

Sync all of these both directions so marketing and sales read the same data. t1 is the one everyone forgets — it catches sync failures the other timestamps can't see. First outreach counts email, phone, or live chat.

Backfill & business hours

Backfill everything you can so the reports have history from day one. Use Traction Complete's per-rep working hours to measure business-hours-only elapsed time (you could do SF formula fields, but TC does it natively). Trim "just-in-case" wait steps once the data shows enrichment returning fast — Port Knox cut a 10-minute timer to 5.

The dashboard

Spin up a dashboard by team, by rep, and by lead source — average time from assigned to first outreach. S.D.R. leaders monitor it weekly. Tie the S.L.A. to source: demo requests within an hour (15-min best case), lower-intent sources within 24. This catches the human delays too — a mis-located lead once sat 24+ hours with an EMEA rep that a U.S. rep would've worked in one.

2.4 · Build & Test

Claude drafts, the engineer approves.

There's no LeanData CLI, so a human builds — but Claude does the heavy lifting around it. Best practice is an engineer in the tool, because A.I. left alone will latch onto a legacy field value that isn't in use anymore.

1
Claude writes the IKEA instructions
From the approved map + the CRM metadata: these fields, these objects, click this in Traction Complete, build this rule. A precise handoff so the engineer builds fast instead of reverse-engineering intent.
2
Start from a support template
LeanData's support team ships starter templates you can load into the client instance — build the template, then document how to modify it for this client.
3
Engineer builds & reviews the rules
Human eyes on which specific fields feed each routing and matching rule. LeanData's Flow Builder feels like Salesforce Flow, so this moves quickly.
4
Prove it — 25 test scenarios in a CSV
Have Claude generate 25 net-new test records from the requirements + CRM context. Import them, see where they land vs. where they should land. Anything that fails: spot-check, fix, rerun. This is where full CRM context makes Claude genuinely fast.
2.5 · Cutover & Go-Live

Push, then watch — with the team already briefed.

Routing cutovers are gentler than a re-platform. Most work happens in production, volume is usually low enough that there's no set launch day, and the routers give you a safety net.

Low volume · simple change
Push & monitor
Launch it, watch the first leads flow, and manually intervene on anything weird. No downtime window needed — the volume gives you room to hot-fix live.
High volume · big net-new motion
Stage & parallel-run
Stand the new flow up alongside the old, watch it quietly, then swap. Lean on version history to revert and path logs to diagnose where a record went down the wrong branch.

The one rule you don't skip

Enable the team before you go live. Your best monitoring layer is the reps themselves — the A.E. who says "this shouldn't be in my name" is how you catch what testing missed. If they don't know how it's supposed to work, they can't flag what's broken.

3
Phase 3

Enable.

Turn the team into your monitoring layer. Ship the flowchart, document what changed and why, and make sure every rep knows exactly which leads should land in their name.

🗺 The flowchart
See
  • The full routing logic as a diagram
  • Entry → enrich → classify → assign
  • Feels like LeanData because it is one
📄 Documentation
Read
  • What changed and why
  • What the team should expect
  • A one-pager or microsite to hand off
🎙 Training
Live
  • We train for big net-new changes
  • Clients often run their own for tweaks
  • This page's brief is the template
3.1 · Set the Lanes

Everyone knows their leads.

The rhythm is lighter than a re-platform's Friday cutover, but the enable-then-watch cadence still holds.

Before · go-live
Pre-brief & set lanes
Walk the team through the flow: John gets X, Y, Z; Sam gets these. Expectations set before anything changes.
Go-live
Push & monitor
Flip it, watch the first leads route, hot-fix anything odd in real time.
Week 1
Reps flag misroutes
The A.E.s and S.D.R.s are the alert system — "this shouldn't be mine." Triage from their path logs.
Ongoing
Tune & log
Add validation and fallbacks as the edges surface. Every fix goes back into the repo.
3.2 · Clone the repo into their brain

We clone this Lead Routing repo for each customer. The routing map, the S.L.A.s, the segment definitions, the gotchas we hit — all of it informs their agent going forward.

That's the compounding move: enablement isn't a one-time handoff, it's context that makes the next routing change on that account faster — and the next architect who touches it starts warm.

3.3 · The flowchart is the point

If you ship one artifact, ship the flowchart. It's what leadership approves, what the reps reference, and what makes the eventual jump into LeanData feel like home. Keep it living — update it every time the routing changes so the doc never lies.

4
Phase 4

Maintain.

Routing drifts the moment the business changes and no one tells the system. Watch for the triggers, kill the silent changes, and revisit on a clock.

4.1 · Ad-hoc Triggers

What kicks off maintenance work.

Trigger

A new rep

Someone joins or leaves — coverage and the round-robin pool shift, and fallbacks need re-pointing.

Trigger

A new territory

New geography, new owner. The territory map and its routing branch both need updating.

Trigger

A new segment or motion

Adding SMB, a PLG motion, or a new pod means new buckets — and new routing to feed them.

Trigger

A definition change

The firmographic or ICP thresholds move; the score gets re-tuned. The classifier has to move with it.

Trigger

A new stage-movement action

A new alert, a new artifact, a new thing that should happen when a lead is assigned or reassigned.

Trigger

A new channel

They start doing events, sign a partner program, or stand up a gov motion — each wants its own path.

4.2 · The #1 Gotcha

Silent process changes.

The story to tell them

A team adds a new SMB segment and hires Greg to work it — but nobody updates the routing. Greg's first batch runs dry, and only then does anyone realize the new SMB leads are going nowhere. Small change, big hole. A couple of these are exactly what pushed Harbinger to shut automation off and route by hand. If they'd flagged the change, we'd have handled it before it broke.

Health checks between revisits
  • Reps are the smoke alarm — misroute complaints are your earliest signal; make it easy to report them
  • Validation & fallbacks — add checks as the team finds the cracks; watch for rules over- or under-firing
  • Automation errors — health-check the flows; use path logs to trace any record that landed wrong
4.3 · When to Revisit

Event-based and time-based.

Event-based
Revisit when something changes
  • New rep, territory, segment, or motion
  • A definition, score, or threshold moves
  • A new channel or a new executive with opinions
Time-based
Every ~6 months, minimum
Quarterly is often too aggressive; six months is the floor. On account refreshes, resist over-doing it — Port Knox moved theirs from monthly to yearly once they realized the reps didn't need the churn and it was a pain to run.
What You Hand Over

The assets, in one place.

The team gets a landing page (this one) with the brief, a one-paste prompt, and the template repo behind it. The client gets a routing flowchart in their hub to approve and a speed-to-lead dashboard to watch.

For the team

This landing page + brief

The playbook overview and the 5-minute audio brief — the front door for anyone running a routing project.

For the team

The one-paste prompt

Clone-for-customer → AGENTS.md drives the checklist. Claude rips the repo and starts the walkthrough.

In the repo

Skills, configs, test gen

Per-tool build skills (LeanData / Traction / native), the speed-to-lead field pack, the 25-scenario test generator, and the gotcha log — enablement for our team and our agents.

For the client

Flowchart + STL dashboard

The routing map they comment on and approve, plus the by-rep, by-source speed-to-lead dashboard their S.D.R. leaders live in.

The bet

Routing is where deals quietly die of neglect. With the base repo plus this playbook — model, channels, enrichment timing, and speed-to-lead paired in — a team can build a clean one fast and never wonder again whether a lead is getting to a rep in time.

✓
Closeout

Debrief the project.

When a Lead Routing engagement wraps, spend sixteen minutes with the debrief agent. Teamwork already knows what got built and when. This is for the part none of our systems can see — the call that could have gone either way, the thing the customer wanted that you refused, the near-miss that never became an incident, and above all the places this playbook turned out to be wrong. What comes out of it gets written back into this page.

Before you start

Two minutes of thinking beats sixteen minutes of recall. Have these in your head — you don't need notes, and you definitely don't need a script.

  • Which of the five models you landed on — and whether that's what the customer expected walking in.
  • Whether it came out as two layers or collapsed into one, and what forced that.
  • The channel that gave you trouble — events, partner, FedRAMP, or a lead source with its own path — and whether it's solid or just good enough for now.

Sixteen minutes, one sitting. It's a voice conversation, so your browser will ask for microphone access — use headphones or the agent will hear itself. Chrome is the safer bet over Safari.

Hand over the artifacts too

The debrief asks what you built that's worth reusing. This is where you actually hand it over — dashboards, field maps, flows, templates, scripts, spec docs. Files land in the project's Drive folder; links go into the artifact register so the next person can find them.

Thirty seconds, and do it while the project is still in your head. “I'll upload it later” is exactly how assets end up trapped on an account.

Add an artifact →