Find → Research → Enrich → Outreach
Outcome: your workflow mapped onto four named stages, with a check at each boundary so a failure tells you where it happened instead of just producing a bad list.
- Surface
- App and MCP server
- Level
- Beginner
- Uses
- find_companies · enrich_organization · find_work_email
- Credits
- ~5 for the worked example
- Prerequisite
- Lesson 02's column sketch
The four stages
Every pipeline in this library, however elaborate, is these four in this order.
Find
Produce the candidate set. Companies from firmographics, people from a company, businesses from a map search, engagers from a post. The only question this stage answers is who might count.
Volume is decided here and nowhere else. Every downstream cost is a multiple of this number.
Research
Answer questions no database holds. What does their pricing page say, do they have live chat, what is this company actually selling, is this the right entity at all. Scraping and AI both live here.
This stage is optional in simple builds and the whole point in sophisticated ones.
Enrich
Attach known facts: headcount, revenue, tech stack, funding, emails, phone numbers, signals. This is a lookup against data that already exists somewhere.
Most of your credit spend is here, and most of it is avoidable by gating first.
Outreach
Get the result out of the table and into the world: sequencer, CRM, Slack, sheet, webhook. Nothing you build has value until this stage runs.
Cheap first, always
The stages are also, roughly, a cost curve. Find is cheap per row. Enrich at person level is expensive per row. Research sits between and varies widely.
That is why the ordering matters more than the tooling: filtering between stages is the only optimization that compounds. Cutting 2,000 companies to 400 before the person stage removes 80% of every later cost at once — no provider choice, prompt tweak or plan upgrade comes close.
| Rows entering | Stage | Cost each | Total |
|---|---|---|---|
| 2,000 | Enrich company | ~0.5 | 1,000 |
| 2,000 | Find people (3 each) → 6,000 | ~0.3 | 1,800 |
| 6,000 | Find work email | ~1 | 6,000 |
| ~8,800 |
Same build with a gate after the company enrich, cutting to 400:
| Rows entering | Stage | Cost each | Total |
|---|---|---|---|
| 2,000 | Enrich company | ~0.5 | 1,000 |
| 400 | Find people (3 each) → 1,200 | ~0.3 | 360 |
| 1,200 | Find work email | ~1 | 1,200 |
| ~2,560 |
Nothing was removed from the design. One filter moved.
Diagnosing a failure
Each stage fails with a distinct symptom. Learn the table and debugging becomes a lookup.
| Symptom | Broken stage | Usual cause |
|---|---|---|
| List is empty or tiny | Find | Filters stacked too tight; a criterion that is really a signal |
| List is large but wrong companies | Find | ICP defined as a category, not as filters |
| Right companies, no useful evidence | Research | Scraping the wrong page, or asking the AI an unanswerable question |
| Evidence exists, fields are blank | Enrich | Wrong identifier in, or a person genuinely not in any provider |
| Everything filled, nothing sent | Outreach | Export mapping, sequencer field names, or no owner assigned |
| Sent, but replies say “wrong person” | Find | Role filter too broad — a Find problem, not a message problem |
The last row is the one people get wrong most. A poor reply rate is diagnosed as a copywriting failure roughly nine times out of ten, and is a targeting failure roughly half the time. Check the stage before you rewrite the email.
Boundary checks
A stage boundary is where you should be able to state a number. Write these four down for every build:
- After Find — how many rows, and does the count look sane against your own estimate of the market?
- After Research — what percentage came back with a usable answer rather than a null or a hedge?
- After Enrich — hit rate per column. Below 60% on work email means the input identifiers are wrong, not the provider.
- After Outreach — how many rows actually left the system, versus how many were eligible?
Any of these dropping between runs localizes the problem instantly.
Do this now
- Label each column in your lesson 02 sketch with its stage.
- Check the order: no Find column may appear after an Enrich column. If one does, you are enriching to decide who to look for — reverse it.
- Add a filter between every pair of stages, even if it passes everything today. It is the hook you will need later.
- Run a tiny version end to end: source 10 companies with
find_companies, enrich them, take one company, find one person, get one email. Note the count surviving each boundary. - Write the four boundary numbers down. They are your baseline.
Check your work
- Every column in your sketch has exactly one stage label
- Stages appear in order, with a filter between each pair
- You have four baseline numbers from a 10-row test run
- You can name the symptom you would see if each stage broke
Where this breaks
Skipping the boundary counts is what turns a small bug into an expensive one. A workflow that silently returns 40 companies instead of 400 will happily run every downstream step and produce a beautifully enriched, tiny list — and you will not notice until someone asks why pipeline is flat. Record the count at each boundary on every scheduled run, not just the first one.
Further automation
Once the boundaries are instrumented, the natural next step is alerting on them: post the four counts to Slack after each scheduled run, so a stage failure surfaces the same day rather than at the end of the month. Workspace integrations covers the Slack path, and Webhooks covers sending the numbers anywhere else.
Next lesson
04 — Waterfalls and why hit rate beats provider choice, a close look at the stage that costs the most.
Reference for this lesson: Actions, find_companies, enrich_organization, Export.