---
title: "Automated Inbound Enrichment"
type: playbook
evidence_type: method
category: "Automation"
publisher: "LeanScale"
date_modified: 2026-07-30
word_count: 5938
topics: ["demand-generation", "ai-in-gtm"]
canonical_url: https://www.leanscale.team/knowledge/playbooks/automated-inbound-playbook/
source: "LeanScale Knowledge Hub — https://www.leanscale.team/knowledge"
license: "Free to quote and cite with attribution to LeanScale."
---

# Automated Inbound Enrichment

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

Three customers, two CRMs, two motions — and the same six stages every time. The centre of gravity here sits in Blueprint: the trigger you design and the fields you agree decide what this costs and whether anyone uses it. The build itself is now largely programmatic.

## Four phases, six stages, one fork.

Three customers, two CRMs, two motions — and the same six stages every time. The centre of gravity
here sits in Blueprint: the trigger you design and the fields you agree decide what this costs and
whether anyone uses it. The build itself is now largely programmatic.
1
Blueprint
The qualifying event, the stage order, and a field contract signed before anything is built.
Output A signed field contract
2
Build
Two tables generated from JSON, gated waterfalls, and the account match-or-create layer.
Output A live, governed pipeline
3
Enable
What the data is, who consumes it, and what a not-found actually means.
Output A team that trusts the record
4
Maintain
Credits, model drift, and the new asks that arrive once they see what it can do.
Output An expansion surface
0
Before Phase 1

## Before you scope it.

Lighter than the outbound gate — these people
already raised their hand, so there's no ICP to argue about before you can send anything. But two things
have to be true, and one more should be true.
1 · Clay
Hard prerequisite · say it at scoping
You can approximate this elsewhere, but the native integrations are the reason it works . Supabase can do it if you're willing to hold an API key for every provider yourself.
Freckle is promising and we're testing it — CLI-driven tables, fast to respond to feedback. Not yet. We recommend what we have a shipped case for.
If a customer buys Freckle themselves and wants to pilot, great. Don't put them on it.
2 · CRM admin, and an owner
Hard prerequisite
Permission to create fields and build the automation that fires the webhook.
A named person who can decide the qualifying criteria and sign the field contract.
A representative export of recent inbound, so you can baseline coverage before you promise a lift.
3 · A market map
Strong recommendation, not a gate
The ICP is what tells you which fields are worth paying for . Without one you'll enrich a lot of data nobody consumes.
Run it first where you can — Parts 1 and 2 shorten materially when the ICP is already settled.
Not a blocker. Inbound arrives whether or not they've defined who they want.
Making the Clay case, when that's the sticking point
The cost argument usually makes itself, and architects should have it ready:
One client cancelled a Crunchbase contract — roughly ten thousand a year — moved funding data into Clay, and beat the match rate they'd been paying for . Clay waterfalls four or five providers plus an AI fallback; a single source can't.
Firmographics that customers buy ZoomInfo for can frequently be resolved with an AI column instead. And if credits are the concern, they can bring their own OpenAI key and run the same enrichment off it.
Frame it as consolidation, not a new line item: what does Clay replace? That's the conversation that gets it approved.
Quote the backfill separately
The historical backfill is its own line item — it's a different job on different
records, and every customer wants it once the live path is running.
Start Here

## Kick off a project in one paste.

Copy this prompt, drop in the customer name, and send it to your Claude. It does the research that lets
you walk into discovery with a drafted architecture rather than a blank spreadsheet — which is the whole
point of showing up prepared. They poke holes in a draft far faster than they fill in a template.
paste into Claude Copy prompt
# Automated Inbound Enrichment — kick off
Draft the inbound enrichment blueprint for [Customer Name] . Assume Clay.
Bring me assumptions, not questions — I want something they can correct.
STEP 1 — read the motion. From their site, pricing page and signup flow, tell me
whether this is sales-led form-fill or product-led signup — or both. That single
answer sets the stage order: company-first for form-fill, person-first for
anonymous signups. State which one and why.
STEP 2 — inventory the intake surface. Every form, trial, signup path and list
import that creates a record. Which ones already carry a company, which arrive
anonymous, and which are NOT real inbound (partner regs, deal registrations,
imports, existing customers). Those become the trigger exclusions.
STEP 3 — propose the qualifying event. The precise CRM condition that fires
enrichment. Fires ONCE on the transition, never on later edits. Estimate qualifying
volume against total volume — that ratio is the credit budget.
STEP 4 — draft the field contract. Work backwards from their routing rules and
scoring inputs. For each field: how it resolves, the overwrite rule (fill-blanks-
only by default), and which downstream system consumes it. Flag every field that
is enriched but consumed by nothing — that is pure cost.
STEP 5 — recommend the signals. Given their ICP, what firmographic and
classification signals actually change a routing or scoring decision here. Say
which ones deterministic logic can resolve for free before any AI column runs.
STEP 6 — draft the blueprint as a microsite: the six-stage diagram with their
trigger, the stage order with the delay between tables, the waterfall per data
point, the account match ladder, the field contract table, and the coverage
baseline we need from them. That page is what they mark up in discovery.
1
Phase 1

## Blueprint.

Blueprint decides three things: when this fires,
in what order, and which fields it returns. Get those right and the build is mechanical. Get the trigger
wrong and you'll spend the rest of the engagement tuning providers to fix a problem that was never in the
waterfall.
1.1 · The standard

## Six stages. Every build.

A sales-led build on Salesforce, a sales-led build on HubSpot and a product-led build — three different projects that decode
to the identical spine. What varies is the trigger, the order, and one client-specific layer at the
company stage.
The pipeline
CRM → enrichment engine → CRM
Trigger Qualify →
Rehydrate →
Resolve identity →
Resolve company →
Match or create →
Write back & associate
Rehydrate is not optional. The webhook carries the record ID and nothing
else; the engine reads every current value back out of the CRM. Minutes pass between creation and
enrichment, and payload values are stale by the time they're used.
1
Qualify
The CRM evaluates the qualifying condition and fires a webhook carrying only the record ID . Varies: the condition — lifecycle transition, MQL designation, spend threshold, form submission.
2
Rehydrate
The engine looks the record up in the CRM and normalizes name, domain and email — strip protocol, subdomain and path down to a bare domain so everything downstream matches cleanly. Varies: which fields exist to rehydrate.
3
Resolve identity
Waterfalls resolve LinkedIn, work email and phone — each gated on the prior provider failing , each paired with a validator. Varies: provider order, tuned to the client's segment.
4
Resolve company
The CRM is checked for an existing account before any paid company enrichment ; domain and firmographics resolve. Varies: whether classification logic sits on top — this is where the client-specific layer lands.
5
Match or create
The match ladder runs and branches to update or create, returning exactly one account ID . Varies: ladder depth and the fields matched on.
6
Write back and associate
Values written under fill-blanks-only governance, the association created, status and timestamp stamped. Varies: the field contract and the association type.
1.2 · The one real fork

## The motion decides the order.

This is the only genuinely architectural decision in the playbook, and you can make it from public
information before discovery even starts. Get it backwards and stage 4 has nothing to work with.
If sales-led · form fill
Company first, person reads it back
The form handed you a company name worth resolving before you touch the person. Enrich the company, classify it, then let the contact table read the finished company record back and inherit from it. The HubSpot build runs this way — company table first, contact table second.
If product-led · signup
Person first, to de-anonymize
An anonymous personal-email signup has no company at all until you identify the human. De-anonymize the person, read their employer and domain off the resolved profile, and only then route to the company table. The product-led build runs this way.
Why the product-led branch matters more than it sounds
The product-led build's signups arrive on Gmail and Yahoo addresses with no company field —
so a paying user is invisible to the account team. The de-anonymization path has now resolved
roughly twelve thousand companies . What surfaced were people at very large organizations who
signed up personally and had spent thousands of dollars on the product. That isn't data hygiene.
That's the front door to an enterprise motion that didn't exist the week before.
Worth knowing: their execs started pushing their own
priority contact lists through the same pipeline once they saw it work. Build it so a list import and a
live webhook feed identical logic — you'll need the second path sooner than you think.
1.3 · The cheapest lever you have

## Design the trigger before you tune the waterfall.

Nearly every runaway credit bill traces back to a trigger that fires too often or on the wrong records.
This is Blueprint work, it costs nothing, and it outperforms any amount of provider optimisation.
1
Fire on the transition, never on the edit
Evaluate the condition on entry into the qualifying state. Built on "update" instead, the same record re-enriches every time anyone touches it — burning credits and adding nothing . Verify with a test record that a later edit doesn't re-trigger.
2
Write the exclusions down explicitly
Deal registrations, partner requests, data imports, existing customers, internal test submissions. The Salesforce build's trigger names three exclusions by lead type inside the condition itself. Exclusions are cheaper than filters downstream.
3
Push the threshold upstream where you can
The product-led build enforces "activated and $100 lifetime spend" in HubSpot, so Clay only reads a value back. Tightening the criteria — not the waterfall — cut enrichment volume by roughly 40× .
4
Size the credit budget from the ratio
Qualifying volume against total volume, times cost per enriched record. That number goes in the SOW. Then check the threshold isn't excluding records the business actually wants — cheap and useless is still useless.
So what
Two customers with identical waterfalls can differ
fortyfold in monthly spend purely on trigger design. Spend an hour on the qualifying event.
It is worth more than a week of provider tuning, and it's the one thing you can fix before anything is built.
1.4 · The deliverable

## The field contract, signed before you build.

Work backwards from the routing rules and the scoring inputs. Every field names how it resolves, its
overwrite rule, and which system consumes it — and if nothing consumes it, it doesn't get
enriched. This is the artifact that gets written sign-off.
Output field Resolution method Overwrite rule Consumed by
Work email Finder waterfall, every finder validated Fill blanks only; preserve the original signup email Sequencing, routing
LinkedIn URL CRM value → waterfall → AI fallback Fill blanks only Rep research, multi-threading
Mobile phone Finder waterfall with validation — expensive Fill blanks only Sales Development
Company name CRM value → AI validation Fill blanks only Account matching
Company domain CRM value → enrichment → AI web search Fill blanks only Account matching, dedupe key
Employee count Company enrichment Fill blanks only Scoring, territory
Industry Company enrichment → classification Fill blanks only Routing, territory
Annual revenue Enrichment validated against filings Fill blanks only; validated value preferred Segmentation, territory
Account ID Match ladder → create Always write Routing, ownership
Enrichment status Derived from resolution outcome Always overwrite Monitoring, routing conditions
Enrichment timestamp Stamped on completion Always overwrite Monitoring, SLA measurement
Baseline before you promise anything
Export a representative sample of recent inbound and calculate today's fill rate per field .
Segment it by intake source, and by work-email versus personal-email records — they behave nothing alike.
Set target match rates against that baseline, not against 100%.
Publish it. It's what the engagement gets assessed against, and it's your defence when a legitimate not-found rate gets read as failure.
Blocking vs. enhancing
Blocking — routing or scoring can't run without it. Domain, account ID, industry, employee count. These justify a deep waterfall.
Enhancing — nice for a rep, not load-bearing. Mobile phone is the standard example, and it's the most expensive thing on the menu.
Enhancing fields belong behind a manual button , run on demand per record, not on every inbound.
The test
Read the contract back and ask, field by field:
"what breaks if this is blank?" If the honest answer is nothing, you've found a line item
that costs money on every single record and changes no decision. Delete it before it ships, not after the
first invoice.
2
Phase 2

## Build.

Two weeks, and shrinking. The build used to be
the long pole on this project; it isn't any more. What's left that genuinely takes skill is the cost
discipline, the account layer, and the timing between the two tables.
2.1 · What changed

## The tables build themselves now.

Our GTM engineers cracked programmatic Clay table creation. Use it — hand-building a 70-column table
from scratch is no longer the standard, it's the fallback.
1
Feed the skill three things
The customer's requirements as written by the architect in Teamwork, this playbook , and the seed IDs for the enrichments — pulled out of the browser's network calls in the target Clay account.
2
It generates the table as JSON
The whole workflow — columns, waterfalls, gates, formulas — emitted as a single importable spec.
3
Import it with the extension
One click, and the table builds. The reference case regenerated the product-led build's 71-column contact table from scratch and it does exactly what the hand-built original does.
4
Map the two ends by hand
The only manual work left: the inputs from the webhook (record ID, the CRM lookup column) and the outputs back to the CRM . If you're deploying into an account that already has the CRM integration, even the field mapping comes across.
So what
Call it half the implementation time, if not
more — and understand what that does to the shape of the project. When the build compresses, the
value moves upstream into the blueprint and downstream into the pilot. Sell the thinking, not the
table.
2.2 · The craft

## Eight rules that decide the bill.

These come out of all three production builds, not from theory. They're the difference between a
pipeline that costs cents per record and one that costs dollars.
1 · Free before paid
Every waterfall, no exceptions
The value already in the CRM is rung one
Paid providers gated on it being absent
The Salesforce build verifies the submitted email first — a valid work email means zero enrichment spend on that row
2 · CRM lookup before enrichment
Stage 4, always
Check for an existing account on domain, then name
Only spend when the ladder comes back empty
Most inbound at an established company is already known
3 · Sequential gating
Never parallel fan-out
Provider N+1 fires only when 1…N all returned nothing
Parallel multiplies cost by the number of providers
It's the single most common build mistake
4 · Candidate deduplication
Before you validate
Carry an accumulator of already-rejected candidates
Skip validation when a later provider returns one you've already failed
By the eighth tier the product-led build's array holds all seven prior rejects
5 · Deterministic before AI
The biggest easy win
Keyword, name-suffix and domain-extension checks are free
The HubSpot build classifies most law firms on three formula columns
The AI column is gated off all three — it runs only on genuine ambiguity
6 · Cheapest capable model
Tier it deliberately
Small models for classification and extraction
Research models reserved for genuinely hard columns
The most expensive column set to manual-only so it never auto-runs on volume
Don't pay for web search to parse a string
7 · One company, once
The largest single saving
Company enrichment lives in its own table
A lookup gates the route: already enriched, don't re-enrich
Fifty signups from one company = one company enrichment
8 · Constrain every AI column
Schema + an out
Explicit output schema on every AI column
Instruct it to return empty rather than guess
Low confidence returns null across every field
Otherwise fallback chains behave unpredictably and you can't debug the bill
2.3 · Reference waterfalls

## Order them for the segment, validate every rung.

These are the live orders from the production builds — a starting point tuned by the pilot, not a
constant. One validator vendor per data type : one price point, one standard, one place
to swap it out.
Work email · 7–8 rungs, all validated
Free CRM value →
Icypeas → Kitt →
LeadMagic → Enrow →
Findymail → Hunter →
Wiza
Findymail validates every rung in all three builds — accepted only on a verified result.
Every finder double-gated: skip entirely if the submitted email is already a valid work address .
Discovered work email goes to its own field . The signup address is the identity the product knows them by — never overwrite it.
Phone · expensive, treat it as opt-in
Gate Has email & no CRM phone →
Lyne → PDL → LeadMagic →
Upcell → Wiza → Findymail →
Forager → Prospeo → ContactOut
Clearout validates every rung; accepted only on a valid status.
The HubSpot build deleted the entire phone stack — six vendors — after measuring what it returned.
Default position: an on-demand checkbox an SDR ticks per record , not a column that runs on every inbound.
LinkedIn — and the AI rung
Free CRM value →
ReverseContact →
MixRank →
AI fallback · last rung only
The AI web-search step is always the final
fallback , never an early rung — on domain resolution too. It's the most flexible tool in the box and
the easiest one to accidentally run on every record.
2.4 · The point of the project

## The account layer.

This is the step the old library entry never had, and it's what separates "we bought enrichment" from
a working inbound motion. Fields feed a scoring model. The association is what makes routing,
territory assignment and account ownership actually work.
1
Run the match ladder in cost order
Account ID first, then normalized domain , then normalized company name. Free CRM lookups sit above every paid step, so the ladder is a cost control as much as a matching mechanism.
2
Branch: update on match, create only on empty
Two gated branches, never both. Merge them into a single resolved account ID column so everything downstream reads one field regardless of which path ran.
3
Hand the ID back across tables
The company table returns the account ID to the person table through a cross-table lookup with a delay sized to the company stage . The person record has been sitting there waiting for it.
4
Write the association, gated on both IDs
Only when person ID and account ID are both present. This is the deliverable — it's what lets an AE see which account a paying user belongs to .
5
Decide the multi-candidate rule up front
What happens when a company resolves to two plausible accounts. Decide it in Blueprint and write it down — otherwise you're making the call live, on a customer's production data, at 5pm.
2.5 · Two tables, and the clock between them

## The race condition you will hit.

Company enrichment is shared infrastructure , so it lives in its own table — that's
what makes "one company, once" possible. Which means two tables have to talk, and all three builds sequence
them with explicit delays rather than a scheduler : 5s, 10s, 60s, 300s, 500s, 600s. Size them against
the client's own routing timing, not a default.
Domain is the join key. Both cross-table architectures key on company domain — normalize to a bare domain early and everything downstream matches.
The failure looks like bad data, not a bug. The HubSpot build had the contact table reading company classification 1 second after the trigger, before it had been written. The fix was a 500-second delay. Nothing was broken; it was just early.
Roughly 25 minutes end to end is normal on the Salesforce build — trigger to final Lead write, all of it sequenced on delays.
Clay's 50k row cap isn't a ceiling. Auto-delete is enabled: oldest rows drop once the table fills, on criteria you set. It runs indefinitely.
Pitfall · the first one you'll hit
Routing fires before
enrichment lands. The CRM assigns the record on creation while your pipeline is still running, so
routing reads empty fields and the enriched data arrives too late to matter.
Measure the CRM's own routing delay during discovery , then either sequence enrichment inside
that window or gate the routing rule on the enrichment completion stamp. And make sure records that fail
enrichment still route rather than stalling forever.
2.6 · Write-back governance

## Don't break their data.

A rep corrects a title, your next run overwrites it, and you haven't just lost a field — you've lost their
trust in every field on the record. That's very expensive to win back.
Salesforce
removeNullValues: true — an empty result never clears a populated field
disableAutoAssignmentRules: true — the write never re-triggers assignment mid-flight
Lead-to-account written to a lookup field ( Account__c on the Salesforce build)
Trigger built as a flow on the qualifying transition, with exclusions in the entry condition
Enrichment status + timestamp available to routing as a condition
HubSpot
Same governance — fill blanks only per field , CRM value first in every merge chain
Workflow fires the webhook; two workflows if company and contact are triggered independently
Native contact-to-company association written once both IDs resolve
HubSpot itself can serve as the shared state store between tables — the contact table reads the company record back rather than routing rows
Guard for the classic dirty-data case: the name field populated with the domain
2.7 · Pilot, then delete things

## Nine vendors came out after measurement.

The strongest evidence in this playbook for why the pilot step exists — and why you should expect the
v1 waterfall to be too long.
The HubSpot build · June → July
The contact table went from 89 columns to 76 with nothing added . The entire
phone waterfall — six vendors plus the rollup — deleted. The email waterfall trimmed from ten finders to
seven, dropping the most expensive per hit. The contact lookup delay moved from 1 second to 500, fixing the
race. The company table needed no changes at all.
Nine vendors removed after measurement, not before. Without a pilot step, the next build reproduces
the June version — and pays for it every month.
Step 1
Run a real sample
Reflecting the actual mix of intake sources and email types. Measure fill rate per field against the baseline, and hand-verify a subset against public sources.
Step 2
Record cost per record
Actual credit consumption per record and per field. Present it with a recommendation on which enrichment steps justify what they cost.
Step 3
Cut what didn't contribute
Reorder by observed hit rate for this segment. Remove providers that added no incremental matches. Downgrade any model a cheaper one matches.
Step 4
Recalculate at full volume
Projected monthly spend against the budget agreed in Blueprint. If they don't line up, say so now — not in the first invoice conversation.
The rollout pattern
The Salesforce build ran the CRM write
behind a manual button so a human reviewed every record before anything touched the CRM.
In July — one setting change, nothing else — it flipped to automatic. Ship review-gated, earn trust,
then automate. Copy that progression on every build; it costs you a week and buys you the benefit of
the doubt on everything after.
3
Phase 3

## Enable.

Lighter than most playbooks, because nobody on
the customer's side is going to operate these tables — that takes an engineer, and that's fine. Enablement
here is about what the data is , whether anyone is using it, and one conversation that protects the
whole project.
Step 1
Ship the interactive workflow doc
The same treatment as the lifecycle stage view on a GTM Lifecycle project: the trigger, both stages, the waterfalls, the field mapping — as something you click through, not a PDF. This is the enablement deliverable.
Step 2
Walk sales through the new fields
What each field means, where it came from, and how fresh it is. If they don't know the data is there, it may as well not be.
Step 3
Walk marketing ops through the trigger
The qualifying criteria, the exclusions, and how to change them — because they will want to, and the trigger is the credit budget.
Step 4
Explain what a not-found means
The conversation that saves the project. No provider reaches 100%. If a legitimate blank reads as failure to a rep, they quietly stop trusting every field you built.
Say this out loud
"Not-found is an expected category, not an error . Here's the rate we agreed, and here's where we are against it."
"Personal-email records resolve at a different rate than work-email ones. Judge them separately. "
"We never overwrite something a human typed. If you correct it, it stays corrected. "
"Every field on this list costs money per record. Tell us the ones you're not using and we'll turn them off."
Hand off the operational bits
A monitoring view : enrichment volume, match rate and not-found rate over time.
An alert on credit balance , and on any sustained drop in match rate.
The failure modes documented, each with a first diagnostic step.
Admin access transferred, and a check-in booked at 30 days to review match rates and re-tune.
So what
The enablement question that matters isn't "can they
run it" — they can't and don't need to. It's "is anyone consuming what we're paying to enrich?"
Ask it at the 30-day check-in with the field contract in hand. Every unused field is a standing bill with no
decision attached to it.
4
Phase 4

## Maintain.

Genuinely light, and worth saying so plainly —
this is not the outbound playbook. Once it's up it runs on automation and the only standing requirement is
credits in the account. Two things need watching, and one of them is a good problem.
The real gotcha · silent AI drift
If the customer is running their own API keys rather than Clay's native
enrichments, model capability shifts underneath you. Nothing breaks. No error fires. The output quality
just quietly degrades, and you find out from a rep who stopped trusting the industry field.
Schedule a look — is it still returning what it returned at launch?
Expect to change the model over time. Their capabilities move, and yours has to move with them.
Native Clay enrichments don't have this problem. That's a real argument for using them where the cost is comparable.
The good problem · they start asking
Once a customer sees what the infrastructure can do, their imagination catches
up fast. New data points, new signals, a new classification, their market shifts and the fields shift
with it. None of that is maintenance — it's expansion, on infrastructure you already built.
Changes need an engineer, but they're day-to-day work, not a project .
If the engagement ends here, be honest: they'll need engineering capacity to change anything.
Everything they ask for next lands on the same two tables .
Event triggers

## What actually brings you back in.

Trigger

### A new intake surface

A new form, a new trial flow, a new product line with its own signup. The trigger was written against the surfaces that existed at build time; a new one silently isn't enriched at all.
Trigger

### Routing or territory changes

The field contract was derived backwards from routing rules. When those rules change, fields that were blocking become decorative and fields nobody asked for become load-bearing.
Trigger

## The infrastructure is the sale after this one.

Worth knowing when you're scoping, because the second project is cheap once the two tables exist. All of
these have been delivered for customers; none are packaged yet.
Backfill / CRM data foundation
Delivered across 6 accounts
Same logic, scheduled over existing records
Dedupe clusters, orphan contacts stitched to employers
Parent-domain lookup builds account hierarchy
Freshness monitoring
Delivered across 4 accounts
Cheap change detector first , full waterfall only on what moved
Re-enrich only past a staleness threshold
Converts a one-time project into a retainer
Database classification
Delivered across 4 accounts
Their taxonomy applied to their whole database
One classifier column, confidence + QA pass
What territory assignment actually runs on
Provider bake-off
Delivered across 4 accounts
Fixed control set, every provider on the same rows
Coverage, agreement and cost per row
A one-pager — the cheapest thing on this list
So what
Say this at the 30-day check-in, not at renewal:
"the pipeline you paid for is the expensive part, and it's built." Everything above runs on
the same two tables. That's the difference between a $5k project and an account that keeps buying.
The Evidence

## Three builds, decoded.

Every figure here comes from the exported Clay table definitions of the live builds, not from summaries.
Read the one closest to your customer's shape before you design anything.
Salesforce build HubSpot build Product-led build
CRM Salesforce HubSpot HubSpot
Motion Sales-led inbound Sales-led inbound Product-led signup
Trigger Lead enters MQL + Status New, excluding deal reg / partner / import Workflow on new contact and its company Lifetime spend crosses $100 with no company attached
Stage order Person first, company routed out Company first , contact reads it back Person first to de-anonymize, then company
Table sizes 88 + 41 columns 76 + 45 columns 75 + 33 columns
Sequencing Route-row + 300s / 600s delays Delay differential — 5s vs 500s Route-row + 600s read-back
Join key Company domain Associated company ID Company domain
Email finders 7, all Findymail-validated 7, all Findymail-validated 8, all Findymail-validated
Phone finders 9, Clearout-validated none — removed in July none
The added layer Revenue validated against filings Legal classification + attorney counts Reverse de-anonymization
Account handling Match ladder, update or create, writes the lookup Update only — company already exists Lookup, update or create, then associate
Reference build · Salesforce

### The Salesforce build — the account-resolution reference

The most complete implementation of the account layer. Use it when the customer is on Salesforce, or when lead-to-account association is the point of the project. One cheap email-validity check decides whether the entire seven-provider waterfall runs at all. Its distinctive layer is revenue: a deep-research column resolves ARR through an explicit source hierarchy — regulator filings first, then investor relations, then financial portals — returns a confidence level, nulls everything on low confidence, and then reconciles against the CRM value within 5% , keeping Salesforce's number when the research corroborates it.
Reference build · HubSpot

### The HubSpot build — the classification reference

Use it when the value isn't filling fields but deciding what kind of company this is so territory assignment can work. Three free formula signals — industry keyword, company-name suffix, domain extension — classify most law firms at zero cost, and the AI classifier is gated off all three plus the existing CRM value. Five of its eight AI columns run a small model; the expensive research model is reserved for two genuinely hard columns, and the most expensive of those is manual-only so it never auto-runs on inbound volume .
Reference build · product-led

### The product-led build — the de-anonymization reference

Use it whenever the inbound record is an anonymous personal-email signup rather than a form fill. Five providers attempt to find the human behind a Gmail address; once a profile resolves, person enrichment returns name, title, employer and domain — turning an anonymous signup into a named person at a named company . A webhook handles live traffic and list imports handle backfill, both through identical dual-source intake formulas. Two details worth copying: the discovered work email goes to a custom field so the signup address survives, and rather than spend a credit on a timestamp utility the build calls a free public time API .
The shared spine
Across all three, without exception:
thin webhook and fat lookup , one validator vendor per data type, the CRM value first
in every final merge , domain as the join key, delays instead of schedulers, and deterministic before
probabilistic. Six defaults you should not have to re-derive on your build.
Next Door

## Its sibling is Automated Outbound.

Bundle the two with a Market Map and you have the whole pipeline-generation project. Run them separately
and each still stands on its own — most customers need one of them far more than the other.
This playbook · inbound
They engaged first — they're offering the data up
Form fill or signup, a stated use case, a known person to enrich
Much cleaner automated discovery; runs fully autonomous
Needs Clay. Wants a market map, doesn't require one
The sibling · outbound
No warm signal — the ICP carries the weight
The offer decides everything, and it belongs to the customer
Maintenance-heavy: the results come from the loop, not the launch
Needs the market map and territories in front of it
the source site
Open ↗
▶
Load the Automated Outbound playbook
Loads it inline. Or open it in a new tab ↗
✓
Closeout

## Debrief the project.

When an Automated Inbound Enrichment 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 fork — company-first or person-first, what drove it, and whether you'd make the same call again.
The account layer — whether match-or-create and the association actually shipped, or the scope ended at fields.
The bill — the trigger you designed, what the pilot took out, and what a record ends up costing them.
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 Inbound Enrichment playbook — the internal standard for resolving, enriching and attaching
every qualifying inbound record before routing sees it. v0.5 — expect this to change as tools and learnings do.

## Canonical

https://www.leanscale.team/knowledge/playbooks/automated-inbound-playbook/