Cold outreach when you are the SDR.

Most founders we talk to did not plan to be the SDR. They tried the obvious moves first. They posted on LinkedIn, they asked for warm intros, they sent a few cold emails from their personal inbox, they tried hiring a contractor. Each of those moves taught them something, and most of them taught the same lesson: cold outreach is too important to delegate before you understand it yourself.

The hiring path is the one that burns the most runway. A contractor SDR runs around two to five thousand dollars a month, takes a month or so to ramp, and produces reports that are mostly vibes. You suspect the reply rates. You cannot reproduce their best-performing copy. They take a holiday in week six and the pipeline drops. When you go back and read the messages they sent in your name, half of them reference the wrong product. That experience is common enough that it has become a meme in founder circles, and it is one of the most-cited reasons founders end up running outreach themselves.

The outsourcing path has a different failure mode. You hand the list-building work to an agency, they hand you a CSV of three thousand contacts in two weeks, and you spend the next ten hours deduping, re-verifying, and quietly deleting the people who left the company eight months ago. The agency is not malicious. They are operating on a cost structure that requires running the same Sales Nav export logic across dozens of clients, which means staleness is baked in. Founders see this and decide they would rather spend an hour on Monday building the list themselves with current data than spend ten hours on Friday cleaning up someone else's.

Then there is the signal problem, which is the deepest of the three. The founder is the person in the building who knows that the prospect's VP of Engineering used to work at a customer of theirs, or that the company just raised a round on a thesis their product happens to be the perfect fit for, or that the prospect mentioned the exact pain point in a podcast last Tuesday. Contractors and agencies do not have that context. They cannot reasonably be expected to. And a generic Apollo opener written by someone who has never used the product is going to sound like one. So the founder ends up reaching for the keyboard, because they are still the cheapest path to a message that sounds like a human wrote it.

The hidden cost of all this is time, and that is time the founder is not building product, closing warm-intro deals, or interviewing customers. The goal of this guide is to separate repeatable operations from decisions that need human judgement. The actual time saved depends on the workflow, provider latency, data quality, and review burden; Coil does not promise a fixed number of hours.

Cold outreach is one phrase that covers four very different jobs. They have different skills, different tools, different failure modes, and different points at which a founder operating alone tends to give up. The frame in this guide is to look at each of them in turn, name what good looks like, and be honest about where solo operators run into walls.

Job 1: List building.

List building is the work of turning a target audience description into a set of real, contactable people. The inputs are titles, geographies, headcounts, industries, funding stages, and any signal-driven filters (recently funded, recently hired). The output is a deduplicated, verified set of email addresses attached to enough context that the next job (writing) can do its work. Good list building feels boring: a sentence in, a clean CSV-equivalent out, and you trust the result enough to send against it. Bad list building feels like an arts and crafts project with a Boolean query builder, ten browser tabs, and a CSV cleanup phase at the end. The single most common failure mode for founders is exporting a Sales Nav list and discovering, three weeks of follow-ups in, that thirty percent of the contacts moved roles between the export date and the send date. The data was correct when it was extracted. It was wrong by the time it was used.

Job 2: Writing.

Writing is the work of turning a list and a positioning statement into a sequence of emails (or LinkedIn messages, or texts) that a prospect will actually open and read. The inputs are the prospect's recent activity, the founder's positioning, the angle for this particular segment, and a sense of the voice the founder wants to use. The output is a set of openers and follow-ups that reference real, specific events at the prospect's company and connect those events to a reason the prospect would want to take a call. Good writing feels like a thoughtful note from a peer who has done a small amount of homework. Bad writing reads like every cold email you have ever deleted: a forced compliment, a non-sequitur about a feature, and a “fifteen minutes next Tuesday” CTA. The most common failure mode here, for founders and contractors alike, is fake personalization, the openers that pretend to know something specific and obviously do not.

Job 3: Sending.

Sending is the operational work of getting the sequence into the prospect's inbox without getting flagged as spam, without burning the founder's domain, and with the right cadence between touches. The inputs are warmed-up sending domains, a sequencer (SmartLead, Instantly, n8n, or similar), and the message bodies from the writing job. The output is sent emails plus a record of which addresses bounced, which got delivered, and which landed in inbox versus promotions. Good sending is mostly invisible. You queue the sequence, the deliverability tooling does its thing, and the metrics come back honest. Bad sending shows up two weeks later as a sudden drop in reply rates across every campaign, which is usually the first signal that the sending domain has a reputation problem. Founders tend to under-invest in this layer early on and over-invest in it after their first deliverability incident.

Job 4: Learning.

Learning is the work of turning the results of the first three jobs into better versions of the next campaign. The inputs are reply rates, meeting bookings, segment performance, and copy-variant outcomes. The output is a set of decisions for the next week: which segment to double down on, which opener to retire, which signal type drove the best replies, whether the cadence needs to shorten or stretch. Good learning is short and decisive: a single page of “this worked, this did not, doing more of X next week.” Bad learning is a fifty-row spreadsheet that no one reads, or worse, a contractor's weekly summary that gives you reply numbers without the segment breakdown that would let you act on them. This job is the one founders skip most often, because it does not feel like outreach and there is no urgent deadline. The compounding cost of skipping it is enormous.

Each of the four jobs has a characteristic failure mode for solo operators. Naming them is half the battle. Below is the short list of failure modes we see most often, with the Coil surface that is meant to address each one. None of these are theoretical; they are the patterns that show up in the feedback widget on most weeks.

Stale Sales Nav exports. The standard workflow is to filter a Sales Nav search, export the contacts, enrich them in a tool like Apollo or Clearbit, and import the result into a sequencer. The problem is the timing gap. By the time the founder gets around to sending the sequence, anywhere from a quarter to a third of the records have stale titles, the email pattern at the company has changed, or the person has left. The cleaner pattern is to scrape directly off a Sales Nav URL at the moment of send, which is what the Sales Nav scraper in Coil is built for. The fresher the export, the lower the bounce rate, and the higher the opener relevance.

Fake personalization. The hardest writing failure mode to spot from inside the campaign is the opener that pretends to know something specific and obviously does not. “I noticed your impressive background” is the canonical example, and prospects have been trained to delete on sight. The fix is to write from real signals: a recent funding round, a recent senior hire, a product launch, a podcast quote. The signal has to be specific enough that the prospect knows you actually saw it. Coil's prospect scraper imports provider rows into the organization. Supply attributable research separately; the prospect source does not currently promise automatic signal enrichment.

Missed funding and hiring signals. Even when the data is in front of you, the highest-value signals (a Series A two weeks ago, a new VP of Engineering hire on a thesis that matches your product) are the easiest to miss. They are the ones that justify the founder reaching out personally rather than dropping the account into the generic sequence. The pattern that works is to surface the signals at the moment the list is being assembled, not after the campaign has run. Coil's recipe library supports reviewed capability graphs, but it does not currently detect funding or hiring events automatically. Any such research must be supplied through an approved capability and reviewed as provider-dependent input.

Vibes-based reporting. The fourth job (learning) breaks when the reporting is anecdotal rather than segmented. A contractor saying “the campaign went well, we got some good replies” is not a basis for next week's decisions. Reply and campaign analytics remain the responsibility of the sending system. Coil's automation surface records reviewed webhook runs and their delivery results; the separate SmartLead handoff does not create an automation result. Coil does not currently segment reply rates or compare opener variants.

The pitch for putting an agent in front of all this is not that the agent replaces the founder. It is that the agent handles the rote layer (the parts where the founder is doing the same operation for the hundredth time), so the founder can spend the saved hours on the parts that actually require human judgement. This section walks through what that looks like in practice and where the limits are.

The shift is one of operator versus driver. Every outbound tool has an operator (the platform that turns instructions into actions) and a driver (whoever is holding the reins, making decisions, and issuing the instructions). For thirty years the driver was a human. The operator got better; the human had to become more sophisticated to extract value from it. An agent-operable stack lets an approved machine actor call supported actions instead of making a human click every step. In Coil, the dashboard, API, and JSON CLI share services for documented workflows; this does not imply a shared sequencer, general chat integration, or comprehensive audit log. The longer-form version of this argument lives in the agent-driven lead gen primer, which is the companion to this page.

For the four jobs, the practical effect is narrower today. An operator can provide explicit source filters, admit a bounded provider run, inspect organization-scoped rows, and run an approved typed recipe over supplied inputs. A separate configured SmartLead handoff or admin-published webhook can hand reviewed data downstream; only the webhook path records an automation delivery result. Reply analytics, automatic signal research, and campaign optimization remain in the external systems that own those capabilities.

The honest part of this story is what the agent does not change. Deliverability is still owned by the sending tool and the founder's domain reputation. The agent does not warm a domain or repair a bad SPF record. Ideal customer profile is still a human call. An agent will cheerfully run any ICP description you give it, including the wrong one. Positioning is still a human call. An agent can write a competent opener for the angle you describe, but it cannot tell you whether the angle is the right one for this audience this quarter. Creative judgement on which segments to double down on is still a human call. The agent is a powerful driver, but the strategy belongs to the founder. The wedge is not that the founder stops thinking. The wedge is that the founder stops typing the same Boolean filter at nine on a Sunday night.

The model dependency question is worth naming honestly. An agent-driven stack depends on the underlying model being good enough at tool-use to call the platform reliably. As of 2026 that floor is solid for the major model families, but it was not in 2023, and there is a category of edge cases (long multi-step tasks, ambiguous chained instructions) where reliability still trails human operators. The right pattern is to keep a dashboard around for the cases the agent gets wrong, attribute covered mutations to a human or machine actor, retain durable run evidence where the workflow provides it, and gate consequential operations behind the appropriate human role or explicit confirmation.

Here is what a realistic week looks like for a founder running outreach on an agent-driven stack. The point is not to romanticize the workflow. The point is to show where the founder is making decisions and where the platform is doing the clicking. Most weeks look roughly like this once the muscle memory is in place.

Monday morning, list building. The founder opens a chat with their dashboard or JSON CLI and provides explicit targeting fields. The agent admits a bounded provider-backed source run only after spend confirmation, waits for terminal status, and returns the organization-scoped rows for review. Optional email verification requires a separate reviewed recipe and provider connection. Decision criterion at this step: is the segment description specific enough that the agent cannot interpret it three different ways? If the founder is using a vague title filter (“growth folks”) the agent will return a noisier list than if the filter is precise (“Head of Growth at Series A B2B SaaS in NYC”).

Tuesday morning, drafting. If the founder has supplied attributable research inputs, a reviewed recipe may run a schema-constrained OpenRouter transform. Coil does not currently discover funding, hiring, or launch signals automatically. The founder reviews generated fields before any downstream handoff.

Wednesday morning, handoff. The founder reviews the prepared rows before using the separate configured SmartLead handoff or running an admin-published webhook automation. The webhook path records its run and delivery result. Cadence, mailbox warmup, inbox placement, and send approval remain in the sending system and its operator's workflow.

Friday afternoon, review. The founder inspects source, recipe, and automation statuses plus recorded delivery outcomes. Reply rates, copy performance, and deliverability signals must be reviewed in the external sender or analytics system. Those observations can inform the next set of explicit filters and reviewed recipe inputs, but Coil does not currently calculate that campaign analysis.

The time required depends on provider latency, data quality, recipe complexity, and the amount of human review. Coil is intended to make repeatable operations easier to inspect and rerun, but it does not guarantee a particular time saving or claim equivalence to a contractor.

The honest hedges. This stack is built for a specific shape of company. It is not the right answer for everyone, and the failure modes when it is forced into the wrong context are loud enough to call out.

You are a 50+ person revenue team. If you have a RevOps engineer, a dedicated SDR team, and a workflow appetite that runs to hundreds of branching steps, Clay and Apollo are the denser tools. They reward operators who can build complex multi-stage enrichment pipelines, and they have integration coverage that Coil does not yet match. Coil's wedge is the founder doing their own outreach, not the team running outbound as an operations function.

You need a phone-heavy motion. Coil is built around email and text-based sequences. If your motion is cold-calling-first, with dialers, parallel dialing, and live-transfer workflows at the centre, the right tools are sales engagement platforms with native dialer integrations. Coil can hand reviewed rows to the separate configured SmartLead handoff or an admin-published webhook; it does not provide voice, mailbox warmup, or general inbox-eligibility reporting.

You have no inbound channel. Cold outreach works best as a complement to an inbound channel that is generating awareness and consideration in parallel. If you have no inbound, no content footprint, no warm intros, then cold outreach is the only signal the prospect has about your company, and the reply rates reflect that. The right move in that situation is to lead with content for a quarter or two, build a small amount of social proof, and then layer outbound on top of it. Outreach as a single channel is doable but slower than it needs to be.

Your product needs a custom integration story. If your prospect data lives in a vertical CRM or an industry-specific tool that requires a custom adapter, Coil's plumbing may not cover it yet. The integration list grows but it does not cover every long-tail data source. The honest move is to check the product overview before signing up, and to ping the feedback widget if your data source is missing. The roadmap is shaped by what founders ask for.

For the product-level walkthrough, the surfaces this guide refers to are documented on the product overview, with deeper pages on the prospect scraper, the Sales Nav scraper, the recipe library, and automations. The category framing lives in the agent-driven lead gen primer, and the operating method behind the product is in the Coil methodology. Pricing is on the pricing page and a short note on who maintains Coil is on the about page.