Automated Inbound Enrichment — Delivery Playbook

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:

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

Open · flag it, don't guess

Scoping sits at 50 hours standalone against a $5,000 / 30–40 hour menu price, because the written playbook includes the pilot, the credit-tuning pass, the backfill and enablement. Either the price moves or the pilot and backfill are quoted separately. Quote the historical backfill separately regardless — 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

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

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.

Portnox on Salesforce, Patlytics on HubSpot, RunPod product-led — 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

TriggerQualify→ 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.

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.

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.

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.

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.

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.

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. Patlytics 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. RunPod runs this way.

Why the product-led branch matters more than it sounds

RunPod'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.

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.

Write the exclusions down explicitly

Deal registrations, partner requests, data imports, existing customers, internal test submissions. Portnox's trigger names three exclusions by lead type inside the condition itself. Exclusions are cheaper than filters downstream.

Push the threshold upstream where you can

RunPod 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×.

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.

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.

Sarmad and Kaveen cracked programmatic Clay table creation. Use it — hand-building a 70-column table from scratch is no longer the standard, it's the fallback.

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.

It generates the table as JSON

The whole workflow — columns, waterfalls, gates, formulas — emitted as a single importable spec.

Import it with the extension

One click, and the table builds. The reference case regenerated RunPod's 71-column contact table from scratch and it does exactly what the hand-built original does.

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
Portnox 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 RunPod's array holds all seven prior rejects

5 · Deterministic before AI

The biggest easy win

Keyword, name-suffix and domain-extension checks are free
Patlytics 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

FreeCRM 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

GateHas email & no CRM phone→ Lyne → PDL → LeadMagic→ Upcell → Wiza → Findymail→ Forager → Prospeo → ContactOut

Clearout validates every rung; accepted only on a valid status.
Patlytics 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

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

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.

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.

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.

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.

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. Patlytics 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 Portnox 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 Portnox 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.

Patlytics · 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

Portnox ran the Salesforce 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.

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

Match rate drops

Providers decay, and segments drift. This is the moment to re-run a bake-off on a fixed control set rather than adding another rung on instinct.

Trigger

The credit bill moves

Usually volume, not cost per record — which means the trigger, not the waterfall. Check what changed upstream before you touch a provider.

Trigger

The ICP moves

A move upmarket, a new vertical, a new motion. Classification logic written for the old ICP will keep confidently classifying against it.

Trigger

They ask for the backfill

They always do, once the live path is running. Same tables, same logic, batched to respect row limits and credit pacing — and quoted as its own SOW.

What this unlocks

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.

	Portnox	Patlytics	RunPod
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

Portnox — 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

Patlytics — 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

RunPod — 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.

✓

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 →

The Automated Inbound Enrichment playbook.

The audio brief.

Four phases, six stages, one fork.

Before you scope it.

Kick off a project in one paste.

Blueprint.

Six stages. Every build.

The motion decides the order.

Design the trigger before you tune the waterfall.

The field contract, signed before you build.

Build.

The tables build themselves now.

Eight rules that decide the bill.

Order them for the segment, validate every rung.

The account layer.

The race condition you will hit.

Don't break their data.

Nine vendors came out after measurement.

Enable.

Maintain.

What actually brings you back in.

A new intake surface

Routing or territory changes

Match rate drops

The credit bill moves

The ICP moves

They ask for the backfill

The infrastructure is the sale after this one.

Three builds, decoded.

Portnox — the account-resolution reference

Patlytics — the classification reference

RunPod — the de-anonymization reference

Its sibling is Automated Outbound.

Debrief the project.

Before you start

Hand over the artifacts too