---
title: "Automated Outbound Sequencing"
type: playbook
evidence_type: method
category: "Automation"
publisher: "LeanScale"
date_modified: 2026-07-30
word_count: 6063
topics: ["outbound-sales", "ai-in-gtm"]
canonical_url: https://knowledge.leanscale.team/playbooks/automated-outbound-playbook/
source: "LeanScale Knowledge Hub — https://knowledge.leanscale.team"
license: "Free to quote and cite with attribution to LeanScale."
---

# Automated Outbound Sequencing

**Evidence type:** method (what we prescribe)

Most playbooks start at Blueprint. This one starts before that — with three things that have to be true before you are willing to run the project at all. And unlike the others, the centre of gravity sits in Maintain.

## Four phases, and a gate in front of them.

Most playbooks start at Blueprint. This one starts before that — with three things that have to be
true before you are willing to run the project at all. And unlike the others, the centre of gravity sits
in Maintain.
1
Blueprint
Fit and intent scored separately; the autonomy call and the ownership call made out loud.
Output A green-lit design
2
Build
One skeleton, the multi-channel wrap, and the measurement schema that makes it testable.
Output A tagged, live engine
3
Enable
Rules of engagement to the reps, and the expectation that v1 is not the good version.
Output A team that isn't fighting it
4
Maintain
Test-and-learn on the sequences, one named owner on the scoring model.
Output Something that gets better
0
Before Phase 1

## The gate.

This is the most prerequisite-heavy project in
the library, and that is a feature. Every one of these three failures is fatal after you have
built the machine, when it is far more expensive to discover. Check them at scoping, not at kickoff.
1 · A market map
Our own playbook, run first
Outbound has no warm signal to lean on, so the ICP has to carry the weight instead.
Loose ICP means spray and pray, non-response, and a team that abandons it inside a month .
Without a narrow target set, you also never get buy-in — nobody defends a channel that isn't working.
2 · Territories + rules of engagement
A light version counts
The machine is about to start touching named accounts. Somebody owns each one.
One rep? Fine, rock and roll. Four reps? Decide the split first — it doesn't have to be a whole project.
The Sales Territory Design playbook already carries the ROE section. Borrow it.
3 · Their offer and messaging
Theirs, not ours
Same rule as pricing and packaging on a CPQ project: we tell them they need it, we don't decide it.
You need taste about what gets sent, and that taste has to be the customer's.
If they don't have a point of view yet, that's a prerequisite — not something to discover in week three.
So what
Say this at scoping, plainly:
"We can automate a bunch of garbage and it won't work." The three prerequisites are how you
keep that from being your problem. A customer who won't do the homework is telling you something useful
about how this project would have gone.
The quick-follow

## Expect to open an attribution project after this one.

Not before — after. This project creates new ways to generate activity, and those need attribution
components that almost certainly don't exist yet. If their attribution setup is already poor, folding clean
outbound data into it makes the outbound look worse than it is.
If their attribution is decent
Extend it
Add the sequence, reply and sentiment fields into what they already run, and report outbound in the same place as everything else.
If it's garbage
Instrument outbound cleanly, then scope attribution separately
Keep your subset clean rather than pouring it into bad data. Then have the honest conversation about the wider fix as its own project.
Start Here

## Kick off a project in one paste.

Copy this prompt, drop in the customer name, and send it to your Claude. It checks the gate first,
then builds both scoring layers off their own data so you walk into the blueprint session with a
scored account list rather than a blank framework.
paste into Claude Copy prompt
# Automated Outbound Sequencing — kick off
Stand up the outbound blueprint for [Customer Name] .
STEP 1 — check the gate. Tell me which of these are missing before anything else:
- A market map (ICP + persona definitions). No map, no build.
- Sales territories + rules of engagement, even a light version.
- Their offer: the actual reason a stranger would reply. Ours to demand, theirs to write.
- Comp model: does it pay on meetings booked? Flag it — see the comp trap.
STEP 2 — build LAYER ONE, fit. For every product or use case they sell, score
every account in the market map for how well that product fits them. Return the
top-scoring category per account — that score decides what the message is about,
not just whether to send one.
STEP 3 — build LAYER TWO, intent. From their site analytics, CRM activity and any
intent tool they run, propose a warm threshold. Not "visited the site" — a repeat
pattern over a window. Show me the distribution so we can set the bar honestly.
STEP 4 — the account profile. For the accounts that clear both layers, assemble the
summary profile the sequence writes from: what they do, size, funding, stack,
recent triggers, and which of our products fits. Flag every field we CANNOT
populate — those are the holes the personalization will fall through.
STEP 5 — draft the blueprint as a microsite: the flow diagram, the autonomy call
(fully autonomous vs. human-approves-send) with a recommendation and why, the
ownership model (central vs. per-rep), the tools we recommend and the reason for
each, and the measurement schema. That page is what they green-light.
1
Phase 1

## Blueprint.

Blueprint is where you decide what the machine
targets, what it says, who owns it, and how much of it runs without a human. Budget about two weeks —
most of that is the customer aligning, not you designing. It ends in a green light on a single page.
1.1 · The standard

## Two layers. Never one.

Almost every failed outbound build collapses fit and intent into a single "score." They answer
different questions and they come from different data. Keep them apart, and the message writes itself
from the pair.
Layer 1 · Fit — who
Not just "are they in the ICP," but which of the things we sell fits them
best . If you sell compliance, code review and something else, and an account scores highest on
code review, that ranking is what the message is about.
Scored per product or use case, not one blended number
Built from firmographics + the market map, before any behaviour
Quantitative on purpose — a model, not a rep's opinion
Layer 2 · Intent — when
The threshold that makes someone warm. The old-school answer — they landed on
the website — is not warm any more . You have to nearly fingerprint behaviour over a period of
time before you call it interest rather than a passing look.
Session depth and repeat visits, not a single hit
Third-party intent where they have it (6sense and similar)
Public-source signals where the market publishes them — see just below
Set the bar from their real distribution, not a round number
The qualification ladder
Both layers have to clear before anything sends
Market map In the ICP →
Product-fit scored →
Intent threshold met →
Profile complete →
Enrolled
Below threshold · nurture
Fit without intent is a list you're blasting. Intent without fit is a
competitor's intern reading your pricing page. The pair is the qualification.
Where layer two's signal comes from — and the source most people miss
Site analytics and a third-party intent tool are the obvious inputs. The
differentiated one is public data the whole market can see and nobody is reading . Compliance
listings, contract awards, tenders, certifications, registrations, rebate applications. It's published,
it's free, and in regulated or public-sector-adjacent markets it is the strongest buying signal
available — while everyone else prospects off the same purchased list.
One client — we scrape FedRAMP. A company appears on it and it's in their system within
24 hours , enriched, ICP-checked, with the target titles for that tier already attached for
multi-threading. Another runs a public-source feed too.
Standard signals still carry most accounts: new job posts, leadership changes, new hires,
funding and growth news . Custom ones are where the edge is — ask what gets published in their
market that a competitor would have to be paying attention to notice.
Signals go stale fast. This is a scheduled watch with a freshness window , not a one-time
list build.
Then route by tier

## Not everything that scores gets a human.

The pair of scores gives you a ranking, and the ranking should decide the channel , not just
whether to send. Ask up front whether the customer wants us to run the outbound or just to surface,
score and route it to them — those are two different projects, and both are legitimate.
Tier 1
Human, immediately
Highest fit and live intent
Goes to an SDR or AE as a task, with the signal attached as the reason
This is where the hand-built asset is worth the time
Tier 2
Assisted
Strong on one layer, not both
Machine assembles it, a human hits send
The default landing zone for most of the list
Tier 3
Fully automated nurture
In the ICP, no signal yet
Sequenced or nurtured without a human touching it
Cheap, patient, and where the next tier-1 comes from
The plumbing
Same either way
Signals dedupe onto one account record , not one row per alert
Composite score writes the tier back to the CRM
CRM syncs the tier to the sequencer — the tier is the enrollment condition
Ask this at scoping
"Do you want us to send it, or
to surface it?" A customer who wants the signal engine and the tiering, but keeps the sending
in-house, is a smaller and much faster project — and it sidesteps the comp trap below entirely. Don't
assume they want the whole machine.
1.2 · Data readiness

## You can't personalize from nothing.

Underneath both layers sits one centralized account profile — the thing the sequence actually writes
from. If it isn't there, the AI has nothing to derive from, and "personalized at scale" quietly becomes
merge fields.
1
Can we identify them at all?
Person, company, domain. Everything else hangs off this, and de-anonymised traffic is often the weakest link in the chain.
2
Do we know what their business actually does?
A summary of the company in its own terms — from their site, not from a SIC code. This is the single most load-bearing field for message quality.
3
What can we infer around it?
Recent funding, hiring, stack, product launches, what they're looking at from intent signals . Each one is a legitimate reason to be in touch — which is exactly what the offer needs.
4
Where does it live?
One object, one place, refreshed. Not scattered across an enrichment tool, a spreadsheet and somebody's Clay table. Flag every field you can't populate — those are the holes personalization falls through.
1.3 · The autonomy call

## Fully autonomous, or AI-assisted?

Two very different builds hide under one name, and the blueprint has to say which one you're building.
This is a spectrum, not a binary — but you still have to pick a point on it and defend it.
Fully autonomous
Nobody touches it until somebody replies
The machine researches, writes, sends and follows up. A human enters the loop at the reply. Works when the offer is strong enough to carry a cold send on its own — the podcast invitation is the standing example.
AI-assisted · "AI acceleration"
The machine builds it, a human hits send
Research, asset, draft, hyperlinks, subject — all assembled and waiting. The human's job is a final look, not composition. The safer default, and the right one when volume is low and each touch carries a real asset.
The rule
The strength of the offer is what earns you
the right to go autonomous. A genuinely good offer can run unattended. A weak one needs a human in
front of the send button — and probably needs a better offer more than it needs automation.
Worth naming for the customer
"AI acceleration" is becoming its own discipline — there are people being hired
as sales acceleration managers who don't sell, but build the automations that make sellers faster.
If the customer is staffing that role, they've already decided where on this spectrum they sit, and your
blueprint should match it.
1.4 · The offer

## What actually earns a reply.

We don't write it. We do have to tell them what a real one looks like, because most first drafts are a
request for time dressed up as a value proposition.
Works

### An invitation

Something they get to be part of. The podcast is the clean example — it's a genuine offer, it runs fully autonomous, and the people who accept land in the funnel for everything else afterwards.
Works

### Proof in their exact shape

"I built the websites for six other RevOps agencies — here they are." Right time, right context, and work you can see. That one landed on Anthony, out of a hundred that didn't.
Works

### A trigger-fired diagnostic

They just raised, just hired a CRO, just launched. Send something light and specific that you built for them . Real work is a real offer. The strongest version of this is aimed at your own dormant pipeline — see Reactivation .
Doesn't

## The comp trap.

This is the one that has actually blown up in the field, and it is not a tooling problem. Before you
turn anything on, somebody senior has to decide who owns automated outbound — and then check that the
comp plan agrees with them.
Centralized
A growth or RevOps team owns the machine
Consistent, maintainable, one standard. The failure mode: reps still run their own outbound, comp pays on meetings booked, and the machine is now taking commission off their plate. They start working against RevOps — not because they're difficult, but because the comp plan told them to.
Per rep
Each rep runs automation on their own accounts
Feels fair, and reps feel ownership. The failure mode: it gets gamed. Touch as many accounts as possible, let the automation do the work, and claim the meeting that lands — having done nothing but enroll them.
What to actually do
Decide it top down, before build. This is a rules-of-engagement decision, and it belongs to the sales leader, not to the person configuring the tool.
Read the comp plan before you design the routing. If it pays on meetings booked, a centralized machine is in direct competition with the reps for their own commission.
Make it complement, not compete. Automating email should free the SDRs to make calls — the part we still can't automate. Say that out loud, and make sure the plan pays for it.
Write the ROE down. Who gets enrolled, who gets credit, what happens when the machine and a rep touch the same account in the same week.
1.6 · The deliverable

## One page they green-light.

The blueprint is a microsite, not a deck: the diagram, the description, and every tool we recommend
with the reason we recommend it. Nothing gets built until it's approved — and the approval is what
protects the two-week build estimate.
The flow
Diagram
Signal → score → profile → enroll
Where a human enters, if at all
What happens on reply
The decisions
Named, not implied
Autonomous vs. assisted
Central vs. per rep
The warm threshold
The stack
And why
Each tool, with the reason
What we'd retire
What they already own
Success
Agreed up front
Reply rate first
Meetings vs. a real BDR
How we'll A/B test it
So what
Decide how you'll measure success during
Blueprint, not after launch . The maintenance phase of this project is an analytics exercise, and
you cannot A/B test something you never instrumented. That's a Blueprint decision with a Build cost.
The second enrollment source

## Reactivation: the pipeline they already have.

Everything above points the machine at strangers. Point the same machine at stalled and
dormant opportunities and you get the highest-converting outbound in the build — because the
offer problem, the one thing we can't solve for them, is already half solved. They know the company,
the company knows them, and there's a real reason the deal stopped.
Why this belongs here
It reads like pipeline analysis and
it behaves like outbound. The output isn't a report — it's an asset good enough to be the reason
you're back in someone's inbox. That makes it a genuine answer to the offer problem, and it runs
on the same enrollment, sequencing and instrumentation you've already built.
The build

## Three context blocks, one two-page document.

Built for one client. The trigger is a deal going quiet — or a rep asking for it on a named
opportunity.
1
Ingest everything the deal already knows
Opportunity ID goes out, and back comes the CRM record, the call recordings, the full email thread, and the rep and SE notes . Compress each source into its own summary block first — forty emails become one block — then a summary of the summaries.
2
Add the outside context
Two more blocks. A published benchmark or research report in their vertical — the deal summary gets read against it. And company intelligence: what the company is dealing with, who they compete with, and any deadline or compliance date that makes this urgent for them rather than for you .
3
Write the asset, not the summary
Two pages, structured: the problem they're actually facing, why it's time-sensitive for them , what the benchmark data says about companies in their position, how you remove the bottleneck, and one concrete next step. It reads as a lead magnet, not a nudge.
4
Send it as outbound
Same sequences, same instrumentation, same reply-and-sentiment tagging — just a different enrollment source. Tag it separately so you can compare reactivation against cold in the same dashboard, because it will not perform like cold and you want to be able to prove that.
Why it converts better than cold
The account is already qualified — somebody ran discovery on it once.
There's a named champion, and often a reason they went quiet that you can address directly.
The personalization has real material behind it. It's derived from their own words on a call , not inferred from a website.
It's a genuine offer: a document with their situation in it, built for them.
Where it gets you into trouble
Rep ownership. These are somebody's deals. The comp trap below is sharper here than anywhere — settle the ROE before you enroll a single dormant opportunity.
Nothing to say. If the deal died because they had no budget and nothing has changed, an elegant document doesn't help. Gate on a change having occurred.
The benchmark has to be real. A published report in their vertical is the load-bearing ingredient. Without one, this degrades into a well-formatted follow-up.
Call data has to be reachable. If the recordings aren't accessible by API, the whole ingestion layer is out.
Scope note
The same ingestion layer — CRM plus calls plus
emails plus notes, compressed into summary blocks — supports several other projects, including win/loss
classification and forecast work. Those are separate scope and belong in their own playbooks.
What lives here is only the reactivation motion: dormant deal in, engaging asset out, sequence enrolled.
2
Phase 2

## Build.

Two weeks, if the blueprint is good. The
infrastructure itself is not the hard part and it's genuinely repeatable — do it once and you know exactly
what standing it up takes. What eats the calendar is the modelling and the back-and-forth, and most of that
belongs in Maintain, not here.
Blueprint
~2 weeks
Mostly them aligning, not you designing. Longer if the market map isn't done.
Build
~2 weeks
The skeleton, the enrollment logic, the instrumentation. Ship a v1 that works, not a v1 that's finished.
Enable
~2 weeks
ROE, walkthrough, expectation setting. The team is outbounding at the end of it.
Maintain
Ongoing
Where the results actually come from. Budget for it in the SOW, not as a surprise.
The estimate, honestly
Sam's first number was four to six weeks for the full infrastructure
including the modelling. Pushed on it, the answer settles at two weeks minimum for the skeleton —
the service, the flows, the instrumentation — with the model refinement treated as Maintain rather than
Build. That's the version that lets you say: kick off in August, your team is outbounding in
September. Quote the two weeks only when the prerequisites are genuinely in hand.
2.1 · The standard

## One skeleton, not thirty sequences.

A rep building a sequence writes in their own voice, for their own accounts, and experiments as they go.
That instinct is fine for a rep and fatal in an automated system — you end up maintaining dozens of
near-identical sequences forever.
Do this
One structure that ingests variants
A skeleton that conceptually applies broadly, with the personalization flowing in from the account profile and the fit score. Add a variant by adding data, not by cloning a sequence.
Not this
A sequence per segment, per persona, per rep
Nobody is manning this on a per-cadence basis. Dozens of hand-built sequences means dozens of things going stale simultaneously, and no way to tell which of them is actually working.
The test
Ask: "when their messaging changes, how many
places do I edit?" If the answer is more than one, you built sequences instead of a skeleton.
2.2 · The wrap

## One channel can't carry it.

Cold outbound with nothing around it is very hard, and the team has watched it fail
that way. The figure Sam works from is roughly nineteen touch points before somebody engages —
treat that as a directional rule of thumb rather than a measured constant, but design as though it's
true. If the sequence is the only thing reaching them, it's carrying weight it can't carry.
The engine Sequence +
Paid, aimed at the same list +
Content in their feed +
Rep calls
This is an ABM shape , and it's worth naming
it as one. Say it plainly in the blueprint: this is not a silver bullet, it's another way to nurture
the market — a customer expecting a lead firehose from one channel will churn off the project before
the maintenance loop ever gets a chance to work.
2.3 · The measurement schema

## Tag it, or you're guessing.

This is the part people skip and then regret, because every A/B test in the maintenance phase depends
on it. Concept is identical across CRMs; only the plumbing changes.
1
Pull email activity into the CRM
From the engagement platform, as activity records. If the platform can't hand it back cleanly, that's a tool problem — see the Salesloft note below.
2
Stamp the sequence on every activity
Which sequence sent this. Without it you can compare "automated" against "manual" and nothing finer — and which sequence won is the whole question .
3
Flag replies, and run sentiment on them
Positive, neutral, negative. Negative is mostly "stop emailing me," and a rising negative count is an early warning worth watching separately from reply rate.
4
Aggregate to the account, not just the person
One contact's activity tells you very little. Account penetration — how many people at a company you've reached and who replied — is the number that means something.
5
Stamp the outcome with its source
Meetings live on a different event type, or become opportunities. Either way: last touch was this reply, from this activity, from this sequence. That chain is what makes the dashboard real.
6
Report it beside the reps
Same dashboard, same shape, same funnel. If a sales leader can't compare the machine to a human like for like, they can't judge it — and what they can't judge, they don't fund.
Salesforce
Email activities ingested from the engagement platform
Sequence stamped on the activity
Reply flag + sentiment (positive / neutral / negative)
Rolled to the Account for penetration
Meeting event / Opportunity stamped with source activity + sequence
HubSpot
Same fields, carried on a custom object
Stamped from the connected engagement platform
Associated to both contacts and companies
Same schema as Salesforce — transfer it, don't redesign it
No campaigns to work around, which is arguably an advantage
2.4 · Genuinely unsettled

## The attribution object question.

Flagging this honestly rather than writing it up as settled standard, because it isn't one yet.
The proposal — Sam
Rather than bending Salesforce campaigns into carrying sales activity, stand up a
dedicated attribution object : one schema, defined by type and subtype, that everything stamps into
— sequence, activity, create date, outcome — associated to both people and accounts, with opportunities
stamped on it.
Campaigns were built for marketing. Webinars, ad campaigns, a pool of people for sales to work off. They were never designed to ingest sales activity.
The junction structure fights you. Statuses and out-of-the-box behaviour you don't want, and it travels badly when another system needs to read the data later.
Campaigns and opportunities are finicky in Salesforce in ways that show up exactly when you're trying to attribute a booking.
It ports. HubSpot has no campaigns — so a custom object schema moves across as-is, through associations, instead of being re-engineered.
Worth knowing what most customers actually run today:
first touch and last touch on the lead or contact, copied onto the opportunity. The more advanced ones use
campaigns and do campaign-level reporting. Very few have a warehouse and a BI tool , so don't design
the measurement layer as though they do.
Status · open
This is not how the Attribution playbook
is written, and not how we do it in the field today. A tiger team is picking it up — Derek for the
HubSpot side, Izzy off the back of a recent hairy marketing-automation and Salesforce build, plus Alistair. Until that
lands, put the decision in your blueprint as an explicit fork rather than quietly building it either way,
and take what you learn into the closeout debrief.
The Stack

## Tools, and the reason for each.

Recommendations, with their provenance visible — some of these are hard-won, one is an openly stated
personal bias. The blueprint should carry the reason, not just the logo.
Research & asset build
Claude / custom AI
Build the account profile
Generate the thing you're actually offering
The necessary part — this is what makes an offer scalable
Workflow automation
n8n · Zapier
Moving data between systems
Ours, never the reps'
Handing this to sellers ends in disaster
Orchestration
Clay · Freckle
Clay is the default
Build the tables programmatically — we generate the whole table as JSON and import it in one click. Roughly halves the build
Freckle drives tables + workflows from the CLI. Worth watching; not yet the recommendation
Engagement
Where it sends from
AmpleMarket, Apollo, Outreach, Gong Engage
Instantly, Smartlead for deliverability
Salesloft — see below
Recommendation · stated bias

### AmpleMarket, if LinkedIn matters

Automates individual sequences as well as normal mass ones, and is the only one that does LinkedIn really well — the others are weak at it. If the ICP lives on LinkedIn, lean here. Flagged in the session as a personal preference rather than a neutral evaluation, so treat it as a strong starting point, not a rule.
Recommendation

### Instantly or Smartlead for deliverability

Once you're sending at volume, domain reputation is the risk . These rotate through inboxes so you're not crucifying yourself with spam filters. AmpleMarket does this too. If nobody has thought about deliverability, that's a gap in the blueprint.
Warning

### Salesloft — consider scrapping it

The APIs are too closed. On the last attempt, nothing came back out beyond dropping people into sequences — which makes the measurement schema above impossible to build. If a customer is on Salesloft and wants this, that's a real conversation to have early. Unclear what changes as it comes together with Clari.
The test

### Built AI-native, or bolted on?

Tools designed before this era can't retrofit it without a real deconstruction, and a tacked-on layer behaves like one. AmpleMarket ships an MCP — you can orchestrate sequence building from Claude — and Apollo has moved that way. Ask what the API and MCP story actually is before you commit a customer to a platform.
Hard rule

### Reps don't get the automation tools

n8n and Zapier stay with us. Not a judgement about reps — it's that unmanaged workflow automation across a sales team produces a mess nobody can debug, and this project depends on the data staying clean.
Intent

### Third-party signal, if they have it

6sense-class tools and enrichment feeds are what let layer two see beyond your own website. Useful, not mandatory — and don't let a customer treat buying one as a substitute for having an ICP.
3
Phase 3

## Enable.

Enable here is mostly expectation management,
and the work starts back in Blueprint. People hear "automated outbound" and they hear set-it-and-forget-it:
leads arrive, nobody prospects again. Left uncorrected, that expectation kills the project in month two —
right when the maintenance loop would have started paying.
Step 1
Set the pipeline expectation
It's a pipeline: what goes in one end decides what comes out the other. The outputs are only as good as the inputs, and some of those inputs are theirs.
Step 2
Walk the reps through the ROE
Who owns what, who gets credit, what happens when the machine and a rep land on the same account. Comp questions get answered here, by their leader, not by you.
Step 3
Show them exactly what gets sent
In their name, from their domain. Reps are right to care about this. Surprise here is how you lose the room permanently.
Step 4
Say what the freed-up time is for
Calls. Automating email should free SDRs to do the thing we still can't automate. Frame the machine as complementing them, and make sure the comp plan says the same.
Say this out loud
"The first version is not the good version . Nine times out of ten it needs real refinement."
"We'll know it's working from replies first, meetings second."
"This is one channel. It works when there's something else around it ."
"You own the messaging and the offer. We own the machine."
Set up the feedback loop
The reps are the end consumer — they read the replies , so they see what's working first.
Give them somewhere to say "this message is landing / this one is embarrassing."
Agree who reviews it and how often, before anyone needs it.
Their feedback is the raw material for the whole Maintain phase.
4
Phase 4

## Maintain.

This is the heaviest maintenance phase of any
playbook in the library, and it is where the project is actually won. Launch is a checkpoint, not an
outcome — it might work straight out of the gate, but nine times out of ten refinement has to happen before
anything meaningful shows up. Scope and price accordingly.
1
Run the A/B loop properly
You instrumented for this in Build. Compare sequences on reply rate and sentiment before you compare them on meetings — meetings are too sparse to learn from quickly .
2
Feed the rep signal back in
They're reading the replies. What lands, what embarrasses them, which accounts were scored wrong. That's your highest-quality input and it doesn't show up in a dashboard.
3
Tune the model, with one owner
The fit scoring will need real iteration. This is where projects stall — see the DRI trap below.
4
Watch the two numbers
Reply rate as the leading indicator — a reply means someone read it and thought it deserved an answer, even a brush-off. Then meetings booked against a real BDR's rate . Seventy percent of a BDR you aren't paying is a good outcome, and it's been beaten before on the inbound side.
The DRI trap — the thing that actually stalls this project
Hand a sales team a product-fit score for a hundred accounts and you will get
seven or eight different opinions about what should map to what. It's a question they've never
looked at quantitatively, and the model needs quantitative answers — otherwise you've just built another
sales rep with its own opinions instead of something structured and consistent.
Name one owner of the scoring model at kickoff. One name, one decision, documented.
Collect rep input as evidence, not as votes.
Set a revision cadence so it's a scheduled decision rather than an open argument.
If nobody will own it, say so early — that's a project risk, not a detail.
Event triggers

## Rebuild on events, not just on a clock.

Trigger

### A new product or use case

The fit model has a new column and every account needs rescoring. This is also the most common moment for the messaging to drift out of sync with what the machine actually sends.
Trigger

### The comp plan changes

Comp decides rep behaviour toward the machine. A change to what's paid on can turn a complementary system into a competitive one overnight, without anyone touching the config.
Trigger

### Territories or headcount change

New reps, departures, a re-cut of the patch. Enrollment routing is downstream of territory design — when that moves, the machine is handing accounts to the wrong people until you fix it.
So what
Set this expectation in the SOW, not in month two:
this is a maintenance-heavy project, and the maintenance is analytics work. A customer who
buys a build and doesn't buy the loop has bought the least valuable half.
Next Door

## Automated Inbound is its own playbook — and it's live.

Everything here is about people who never raised their hand. Inbound is a materially easier discovery
problem — they've filled something in, told you the use case, and asked to be contacted — so it gets its
own build and its own session. Don't stretch this one to cover it; open that one instead.
Bundle both with a Market Map and you have the whole pipeline-generation project.
This playbook · outbound
No warm signal — the ICP carries the weight
Compliance surface: you can email, you can't robocall
Lower response rate by nature; the offer is everything
Needs the market map and territories in front of it
The sibling · inbound
They engaged first — they're offering the data up
Form fill, stated use case, enrichment on a known person
Much cleaner automated discovery
Proven: more meetings booked than outbound in some months, fully autonomous
Hard prerequisite is Clay , not a market map
leanscale-automated-inbound-playbook.netlify.app
Open ↗
▶
Load the Automated Inbound Enrichment playbook
Loads it inline. Or open it in a new tab ↗
✓
Closeout

## Debrief the project.

When an Automated Outbound Sequencing 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.
The gate — which of the three prerequisites were actually in place, and which you ended up building yourself.
The comp plan — who made the ownership call, and whether the reps ended up complementing the machine or competing with it.
The measurement layer — campaigns, a dedicated attribution object, or something else, and whether two weeks held.
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.

#### What this is, and isn't

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.

#### If it doesn't load

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.

### 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 →
LeanScale · Delivery OS
The Automated Outbound Sequencing playbook — the internal standard for building, instrumenting and
maintaining a customer's outbound engine. v0.6 — updated 30 July 2026 with the
reactivation motion, public-source signal sourcing and tier routing, from the session with Sarmad
Rasheed. Expect this to change as tools and learnings do.

## Canonical

https://knowledge.leanscale.team/playbooks/automated-outbound-playbook/