Part 1 The problemWhy teams need this
01 · THE PROBLEM
Everyone knows personalised outreach wins. Nobody has the hours to research 500 companies a week. So teams send templates, reply rates sink, and the list burns. We built this for our own outbound: the research and the first draft happen automatically, and a human keeps the one decision that matters, whether this email should be sent at all.
Part 2 How it worksWhat it does, step by step
02 · WHAT IT DOES
You give it a lead. It reads the company's website and this month's news, works out which of your offers actually fits, and writes an email that proves it looked. Then it stops and waits. Nothing goes out until someone on your team says yes.
03 · HOW IT RUNS
Step by step, as built.
Normalise the lead
Leads arrive from different sources with different field names. The first step puts every lead into one shape.
Research the company
Two Exa calls: a news search for anything recent worth mentioning, and a crawl of the company's own site for what it actually sells.
Refuse to write blind
If the research came back empty or broken, the lead goes to the dead-letter queue instead of getting a generic email.
Pick the angle
Claude sorts the company into one of our customer buckets. A Switch node routes it to the prompt for that bucket, or skips it entirely.
Write, check, queue
Claude writes the email, the output is parsed and validated, a duplicate check runs, and the draft is added to the review queue in Baserow.
04 · WHERE A PERSON STAYS IN
The machine drafts. A person decides.
Every draft lands in a review queue. A person reads it and marks it Approved before a separate workflow is allowed to send it. No approval, no email.
05 · TOOLS AND APPS
Built around the systems already in the process.
06 · WHEN SOMETHING BREAKS
Failure is designed in.
- 4nodes retry automatically when an external API fails.
- 6nodes have their own error branch, so a failure is routed and handled, not just logged.
- 4decision points (IF or Switch) check the data before it moves on.
- ✓Anything unhandled triggers our central error workflow, so a crash gets reported instead of failing silently.
Standard on every build
- Schema validation before downstream writes
- Retry and error routes for external API failures
- Duplicate-safe processing and idempotent updates
- Human approval where the action carries business risk
- Execution logging for support and audit review
Part 3 The impactWhat it's worth, and how we'd build yours
07 · PROJECTED IMPACT
What it should change in the business.
Projections for a typical deployment. The calculation below shows the math, and you can put in your own numbers.
08 · ROI CALCULATION
How it pays back in your business.
The starting numbers are a hypothetical deployment sized to the projections above. Change any of them to your own volumes and costs, and the math updates underneath.
- Full-time equivalent freed
- 2.9 people
- Gross value
- $208,032
- Running cost
- −$1,800
- Return per $1 of running cost
- $115.6
The math: 2,167 leads researched and drafted × 15 min × 12 months × 80% ÷ 60 = 5,201 hours a year × $40/hour = $208,032. Net value = gross value − $1,800 running cost a year.
09 · HOW WE'D BUILD YOURS
How we'd build yours.
- Discover: map the current process, systems, volumes, owners and exceptions.
- Design: define the canonical data model, approvals, retries and system boundaries.
- Build: implement credentials, nodes, validation and observable error routes.
- Prove: run controlled data through success, duplicate and failure scenarios.
- Operate: publish runbooks, ownership and measurable service levels.
