Cold email, run like a factory

Someone reading this might reasonably ask why any of this needed to be built. The honest answer: there isn't a single platform, EmailBison included, that comes ready to run high-volume, multi-domain cold outbound end to end. Every tool solves a different slice of the problem:

• Transactional email platforms (Resend, SendGrid, and the like) are built for receipts and password resets. Email clients don't treat that traffic the way they treat cold outreach, and mailbox providers punish you fast if you point one at prospecting.
• Outbound sequencers (Outreach, Salesloft, Apollo) are built around a rep's own inbox for one-to-one selling. They sequence centrally, but volume generally comes from one domain per rep, which is exactly what tanks deliverability at scale.
• Cold email platforms (EmailBison, SmartLead, Instantly) are the closest fit — multi-domain sending, warmup baked in — but "closest fit" still means a lot of programmatic and manual work to actually run a program on top of one. Nobody ships the campaign building, the deliverability watch, or the reply handling for you.

That gap between "the platform sends the email" and "the program runs itself" is what everything on this page automates.

What it is: a staged, deterministic pipeline I run in Claude Code, start to finish — not a vague "AI agent" freelancing its way through the task, but a defined sequence of steps with checkpoints. I describe a campaign in plain English ("target VPs of Marketing at mid-market SaaS"). The system pulls matching companies from our pre-scored database, checks the CRM for customers and open deals, finds the right people, matches each company to a pitch that has already won us customers, and writes a unique email for every person with about twenty AI writers running in parallel. Every email gets validated for banned words, length, and accuracy before upload. I approve at two points: the pitch angles, and the sample emails.

What it did for people: campaign turnaround went from days of list-building and copy-writing to a same-day process, without ever emailing a customer, an open deal, or someone another rep was actively working. The do-not-email rules run at three separate stages and cannot be skipped, which is what makes it safe to let AI do the volume.

Full detail on how this actually runs day to day, including the checkpoint system and the parallel AI writers: How I Run Email with Claude Code.

There are two honest ways to run outreach, and I think most programs blur them together when they shouldn't.

Evergreen, templated campaigns. Some outreach is genuinely triggered by an event: a job change, a target account starts hiring for a specific role, a dinner in a specific city. Those campaigns should be templated on purpose. The trigger already did the personalization work; the message just needs to reference it clearly and consistently. Trying to make every job-change email "unique" adds writing overhead for zero benefit — the trigger itself is the relevance.

Fully programmatic, per-person copy. Cold email to a list is different. This is the system I never fully finished building, but it's where I think the category is headed: every email assembled from several independently-prompted lines, each fed by a different public data point about the person or company, composed into one message that wouldn't make sense sent to anyone else.

Think of it the way personalized advertising already works: an ad platform doesn't write you a generic ad, it assembles one from your shoe size, your browsing history, your zip code. Nobody sees a "slop" ad; they see one that only makes sense pointed at them. There's no reason cold email, built on public firmographic and technographic data instead of ad-tech tracking, can't work the same way — a message that reads like it was written for one company, because it was.

The practical benefit isn't just relevance, it's deliverability: a genuinely unique email doesn't fingerprint as bulk the way a mail-merge template does, because there's no shared template for a spam filter to pattern-match across your whole list. And because each line comes from a distinct, isolated variable, you can run the loop backward: track which line, which variable, which persona combination drove a reply, and start tuning the inputs instead of guessing at copy. That's a recursive learning loop on messaging, not just an A/B test on subject lines.

I want to be honest about where this stands: I never fully shipped the extreme version of it, mostly time and energy, not belief. The campaign factory above is the version I did ship — one AI writer per person, working from a matched pitch angle — and it's a real step toward this, not the whole thing. The modular, multi-line, self-tuning version is the direction I'd take it next.

I don't operate email platforms directly. Claude Code is the surface operation: it's hooked up to Apollo, the CRM, and everything else in the stack, and that's where campaigns get built, leads get pulled, and copy gets written. EmailBison sits underneath, running the actual sends with all its webhooks, variables, and sequences, but nobody on the team needs to log into it. Reply handling and the actual human interfacing happen in Slack instead: a reply lands, and it shows up in a channel with the reply text and a one-click send button. That's not just faster than working out of the platform's own inbox — it's the moment a manager can read what an SDR is about to say and coach them right in the thread before it goes out, instead of finding out after.

Why we used it: EmailBison is API-first. Everything the UI can do, the API can do, which matters when Claude Code is the one operating the program, not a person clicking through a dashboard. Three capabilities did the heavy lifting for us:

• Webhooks for everything. Replies, bounces, and inbox disconnections all fire events the moment they happen, which is what made the reply and bounce automations possible at all.
• Built-in lead-state protection. When attaching leads to a new campaign, one flag automatically blocks anyone already active in another sequence. That's a whole class of "two campaigns emailed the same person" accidents prevented by the platform itself.
• Bulk lead APIs. Create-or-update in batches, then attach to a campaign. The campaign factory uploads a validated list in one pass instead of looping through records.

Why not SmartLead: we moved off it, and it wasn't a preference call. Its webhooks would silently drop replies, which is fatal when your whole reply pipeline depends on catching every one. Its pricing also charges by leads stored in the platform, so pointing a real CRM at it means paying to duplicate data you already own — and that cost scales with your CRM size, not your sending volume, so it gets expensive fast.

Why not Outreach or Apollo: those are built around a rep's own inbox for one-to-one selling. Cold outbound at volume needs dozens of dedicated sending domains spreading the load, which is a different category of infrastructure entirely.

We layered our own discipline on top: strict naming conventions, per-sender daily limits, and staggered send scheduling so volume ramps up instead of spiking and burning a domain.

How we used it: EmailGuard watched the health of the sending infrastructure itself, the layer beneath campaigns:

• Domain health checks: per-domain reputation and blocklist monitoring, surfaced in the dashboard so a burning domain was visible days before reply rates showed it.
• Domain host checks: verifying the technical setup (the DNS records that prove you're allowed to send) stayed correct across dozens of domains, because one silent misconfiguration can tank a whole domain's placement.
• Inbox placement tests: seeded tests showing whether mail lands in the inbox or the spam folder, run with recent live campaign copy pulled from EmailBison rather than dummy text, so the test measured what we were actually sending.

Every event EmailBison fires (a reply, a bounce, a disconnected inbox) flows into one handler. It was built defensively: the same event can arrive in slightly different formats, so the handler understands every variant, and warmup chatter gets filtered out before anything is stored, because storing it would cost real database money for zero information.

• Every reply is classified by AI (a small, cheap model): interested, not interested, out-of-office, auto-reply, unsubscribe request, or wrong person.
• Interested replies alert the team immediately and flow into the Slack reply workflow, where a rep can answer in one click.
• Unsubscribes and hostile replies get suppressed so those people are never contacted again.
• A daily reconciliation sweep re-pulls recent replies from the platform and compares them against what the instant alerts delivered, because alerts miss events, and a missed interested reply is lost revenue.

• Every bounce is classified by type: a dead mailbox is different from a full inbox, which is different from a spam block, and each gets different treatment.
• Hard bounces go straight to the blacklist so they can never be emailed again from any campaign. Spam-block patterns trigger a Slack alert because they signal a domain problem, not a lead problem.
• A daily bounce batch re-processes the day's bounces as a safety net behind the real-time handling.
• Bounce and validation outcomes get written back to the CRM as standardized statuses, so sales and marketing stop touching dead addresses too.

• Disconnected inbox recheck: sending accounts silently lose their connection; a recurring check catches them and alerts Slack, because a disconnected inbox means its scheduled sends just quietly stop.
• Blacklist management: one suppression list with logs and history for every automated action, reviewable in the dashboard, so "why is this person blocked" always has an answer.
• Slack alerts for everything that needs a human: spam-block patterns, disconnects, unusual bounce spikes.

Every dashboard view (domain health, provider-level analytics, placement tests, cohort comparisons) is broken down on the deliverability command center page.