Lead Routing

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.

• Output Approved 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.

• Output Live routing + STL dashboard
• 3
• Enable

Ship the flowchart, document what changed, and set each rep's lane so the team becomes your monitoring layer.

• Output A team that flags misroutes
• 4
• Maintain

Revisit on change and on a clock. Catch the silent process changes before leads quietly go nowhere.

• Output Routing that stays true
• Start Here

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
• Copy prompt
• # 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

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

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

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
• Entry Lead in →
• Force Sync →
• Wait for Enrich →
• Layer 1 Classify →
• Layer 2 Match & 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

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

A blend of the above — the most common enterprise 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

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

On top of any model: SMB / mid-market / enterprise / whale, with reps in pods that

lead from S.D.R. into A.E. One client 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

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

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

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

Relationship-driven. If a rep worked that booth, the lead may be theirs regardless of the

CRM . One client splits federal events vs. trade shows vs. hosted — event type routes differently.

Channel

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

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

Two instances vs. one

One client ran a separate FedRamp instance and it was painful. Another 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

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
• In New lead →
• Immediate Force sync to CRM →
• Blocking Enrich (firmographic) →
• Decision Classify
• 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

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

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 0 Native SF / HubSpot / Marketo →
• Tier 1 Qualified · chat →
• Tier 1 Chili Piper · scheduling →
• Tier 2 Traction 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

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

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

Chat-based routing with a native router (we use it). Enough on its own for a

mid-size shop; a larger one needs more — it comes down to user count and form real-estate.

Tier 1 · scheduling

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

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

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
• t0 Created in HubSpot →
• t1 Sync attempted → SF →
• t2 Created in Salesforce →
• t3 Assigned (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

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

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

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

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

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

• 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
• 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 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

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

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

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.

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.

It's a craft debrief , feeding straight back into this playbook.

It is not an assessment. Nothing here goes near performance review.

It's attributed — Anthony reads it with your name on it.

"This took two weeks longer than it should have because of X" is the most useful thing

you can say . Say it.

No mic prompt? Check the padlock in the address bar — the browser may have blocked it.

Agent talking over you? Headphones. It's hearing itself through your speakers.

Still stuck? Message Anthony rather than burning fifteen minutes on it.

The transcript takes a moment to generate after you hang up. You'll get a recap

emailed to you.

• 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 →
• LeanScale · Delivery OS

The Lead Routing playbook — the internal standard for getting every lead to the right rep instantly, across native

Salesforce & HubSpot, LeanData, and Traction Complete, with speed-to-lead paired in. Blueprint, Build, Enable, Maintain.

• Blueprint — model, channels, prerequisites
• Build — tooling, enrichment, speed-to-lead
• Enable — flowchart, docs, set the lanes
• Maintain — triggers & silent changes
• www.leanscale.team