The outbound system

Steps

1. Register a dedicated outreach domain that is obviously yours, for example a variation on your business name (your-outreach-domain.com). Point the bare domain at your real website so a curious recipient lands somewhere real.
2. Create one mailbox on it in a real person's name, yours or the approver's. One is enough at the volumes in this guide, and warm-up is per mailbox and per domain.
3. Publish SPF, DKIM and DMARC (records in the templates). SPF names the servers allowed to send for the domain; DKIM signs each message with a key only you hold; DMARC tells receivers what to do when those fail and where to send reports. Start DMARC at p=none (report only), watch the reports for two weeks, then move to p=quarantine (failures go to spam).
4. Create two aliases. unsubscribe@your-outreach-domain.com delivers into the same mailbox, or into a shared one that somebody reads every working day. dmarc@your-outreach-domain.com receives the DMARC reports; they arrive as zipped XML that nobody reads by eye, so sign up for a free DMARC report viewer and either forward them to it or put the viewer's address in the record's rua= instead.
5. Confirm plus-addressing on the alias: mail sent to unsubscribe+test@your-outreach-domain.com must land in the outreach mailbox with the +test tag still visible in the To header. The sender puts a per-recipient token after the plus on the unsubscribe alias, so an opt-out can be tied to the exact person it was sent to; replies are matched by the sender's address. If your provider drops the tag on aliases, create a second real mailbox named unsubscribe instead of an alias.
6. Enable programmatic access on the mailbox with send plus read scopes. Send-only sounds safer; it is a trap (see pitfalls).
7. Set a plain signature: name, business, website, postal address. No images, no banners.

Steps

1. Pick the system of record. It needs five calls: create a lead; add a timestamped note to a lead; read a lead's history back; create a task with a body; read a task's status and result text. If the CRM has no tasks, a separate task tracker with an API covers the last two (we use a self-hosted one).
2. Define the lead record. The fields we would not go without: business name; contact name (only if published); email; email type (business-domain, a role address such as info@ or office@, or free-mail); phone (only if published); website; street address; category; source (which finder produced the row); source_url (where the email was published); acquired_on; funnel category (Phase 6); consent posture; status; notes.
3. Learn the dedupe rule. Most CRMs dedupe on email, so a second form submission from the same address becomes a note on the existing lead rather than a new lead. Make sure your bridge and your reports expect that.
4. Create one API credential with the narrowest scope the CRM offers for creating leads. Keep it in a secrets manager or an encrypted file. Never in a repository, never pasted into a chat.
5. Wrap the five calls in a tiny command-line tool so a person or an agent can record work in one line. Everything that happens later is a lead, a note or a task in this system.

Steps

1. Put one form on your site: name, business, email, phone (optional), what they want to talk about, a consent checkbox in plain words, and a hidden honeypot field that a person never sees and a bot fills in. A small script on the page fetches the bridge's config endpoint, then posts the fields as JSON; a plain HTML form post is not enough for the checks below.
2. Do not post the form to the CRM from the browser. Post it to a small server-side bridge you run (a few hundred lines in any language) that holds the CRM credential.
3. In the bridge, validate in this order: the request came from your own site (Origin and Sec-Fetch-Site, two headers the browser sets and a page cannot forge, plus a per-page CSRF token: a one-time value the config endpoint issues and the submit must echo back); the body is JSON and small; no unknown fields; each field has the right type and length and no control characters; consent is true; the honeypot is empty.
4. Throttle: a small number of submissions per minute per client at the web server, and the same again inside the bridge. Answer 429 (too many requests) before writing anything.
5. Write a receipt before calling the CRM: a random submission id (the form can mint it; the bridge validates it and uses it as the receipt reference), a hash of the payload, and a stage. No personal data in the receipt. Then create the lead, add a note carrying the submission id, and read the history back to confirm it landed.
6. Return {ok, reference} to the browser, or an honest error. Show the reference on the thank-you message so the person can quote it if they call.
7. At the web server, allow exactly the two paths the bridge needs (config and submit) and return 403 (forbidden) for everything else under /api/.
8. Run the bridge as its own system user under systemd, with the credential handed to the process by the service manager rather than written into a config file.

A dental office's “which location” field and a landscaping company's “property type” field are the first personalization slots you get for free; carry them into the lead's notes.

Steps

1. Public registries. Your state's business registry (new filings by county and formation date) and any license roll relevant to who you serve: contractor licenses for a B2B firm that serves builders, food-service licenses for a wholesale bakery. Read the registry's terms of use first. Use the registry's bulk download or API where one exists, and stop if the terms forbid automated access. Keep any automated collection polite: one page at a time, off-peak, nightly or weekly rather than continuously. Count rows per run; if a run returns far fewer than the last one, the page changed, not the world.
2. Maps and places data. Good for categories, addresses and “still open” signals. If you pay for an API, put a hard spend cap in the code path that makes the call, not only in the vendor console, and store only the fields you need.
3. Your own inbound (Phase 3). Hand-raisers are a finder too, and the best one.
4. Hand research. The landscaping owner's list of forty property managers; the boutique's list of local stylists and event planners. Write them into the same CSV shape as everything else, with source = hand research.
5. Partners and referrers. Firms that could send you customers: an accountant for the bookkeeper, a general contractor for the landscaper. These get one-to-one notes from a person, never a sequence.
6. Every finder writes a candidate CSV with the first six columns of the 15-column CSV filled: id, source, name, category, address, website. Put the date you collected the rows in the file name. No email column is filled in yet. That is Phase 5's job.

Steps

1. Split the candidate list into chunks of about a dozen businesses, small enough that one agent can hold the chunk and its sources in context.
2. Agent A, the finder, per chunk: for each business, look only at the business's own website, its contact page, or a public directory entry. Return a published business email, its type (business-domain, role, or free-mail), the exact source_url, and whether the business appears to be still operating. It may not guess or construct an address, may not use data brokers or “email finder” services, and may not return a personal address. Respect each platform's terms: most maps and social platforms forbid automated collection, so anything from a maps or social listing is read by a person, not fetched by a script.
3. Agent B, the verifier, in a fresh context, per chunk: open every source_url; confirm the page is about this exact business and the exact street address appears on it; confirm the email is shown as a contact on the page, not hidden in page code; set verified yes or no with a one-line reason. Its job is to refute.
4. Merge: rows marked verified survive; rejects go to a second file with the verifier's reason. They are your training data for the next prompt. Dedupe on email.
5. Write the 15-column CSV. Provenance means three things at once: verified is yes, source_url is an http(s) URL, and still_operating is yes. Anything else may be stored but is never planned or sent.
6. Record the yield every run. For us, roughly six in ten candidates become send-ready rows. A sudden drop means a source changed or the finder started cutting corners. Investigate before you send.

Prompt outline

FINDER  (one chunk of about 12 businesses, fresh agent)
Given per row: name, street address, category, website if known.
Allowed sources: the business's own website or contact page; a public
  directory entry. Do not fetch maps or social listings.
Return per row: email, email_type (business-domain | role | free-mail | none),
  source_url, still_operating (yes | no | unknown), note.
Never: guess or construct an address; use a data broker or an email-finder
  tool; return a personal address.
Output: JSON matching the schema, one object per input row, no prose.

VERIFIER  (same chunk, fresh agent, opposite brief)
Given: the finder's rows.
For each row: open source_url; confirm the page is about this exact business
  and the exact street address appears on it; confirm the email is shown as
  a contact on the page, not only in page code; set verified (yes | no) and
  verify_note saying what you saw and where.
Your job is to refute. A row you cannot confirm is a no.
Output: JSON matching the schema.

Any AI coding agent that can fan out parallel sub-agents, run web searches and enforce a JSON schema on the output can play this. Fresh context for the verifier every time; an agent grading its own work agrees with itself.

Steps

1. Tag every row with the finder that produced it. The finder decides the category; a person can re-categorize with a note saying why.
2. Write a one-page brief per category (template): consent posture, best channel and the reasoning, a second channel, do-nots, a copy brief, and named personalization slots that say where each slot's content comes from.
3. Write a claims checklist: phrases you will never write (guarantees, competitor names, “free”, “no risk”, anything you cannot prove on request), and the lines every message must carry (the solicitation line, your postal address, the opt-out line). The sender runs both halves on the rendered message, not on the template.
4. Import into the sender one category at a time, so a wave's copy and do-nots match everyone in it.

The boutique that fills out a stylist's contact form is a hand-raiser the stylist may answer today. The same boutique found on a maps sweep is a cold contact that waits for verify. Same business, same industry, different permissions; that is why the category is the grouping.

Steps

1. Build, or have your coding agent build, a command-line sender with a small database: contacts, waves, send attempts, the suppression list, daily counters. Commands: import, preview, plan, send, sync, status, suppress, resume. Dry-run is the default; live needs an explicit flag and everything below.
2. Configure it. Two secrets, the mailbox credential from Phase 1 step 6 and the task-tracker credential, come from the secrets manager exactly as in Phase 2 step 4. Everything else lives in one configuration file that holds no secrets: the mailbox address and sender name; the unsubscribe alias; the sending window and its time zone; the postal address and the solicitation line for the footer; the stop-file path; the maximum age of an approval; the warm-up ceiling; the touch limit and the minimum gap between touches; the list of your own addresses the canary gate may send to; and canary_checked_on, left empty until Phase 8. Choose the numbers and write them down. As starting points rather than rules, we would pick a ceiling of a few dozen a day, an approval that expires in days rather than weeks, three touches at most, and at least a week between them.
3. import reads the 15-column CSV. A row without provenance (verified yes, an http(s) source_url, still_operating yes) is stored as not eligible and can never be planned.
4. preview renders every message with its slots filled and runs the claims checklist and the structure check on the rendered text.
5. plan builds one wave: one category, N recipients, one subject, one body. It hashes recipients plus subject plus body and opens exactly one approval task in your task tracker (shape) whose body carries the preview, the counts and a confirmation word derived from the hash.
6. Approve: a person reads the task and marks it done with the confirmation word in the result. Nothing else counts. Change one recipient or one word and the hash changes, the old approval is worthless, and you plan again. The task is assigned to the named approver from the prerequisites, and “result” means the task's free-text completion field, which some trackers call the comment or the resolution. Setting the task to blocked cancels the wave, even mid-run; that is the approver's emergency stop besides the stop file.
7. send: before every single message the guards below all pass; then a reserved attempt row is written; only then is the mail API called. The reserved row is the idempotency record: proof that this message was attempted once, so an unknown outcome is never retried blindly. If the API's outcome is unknown, the row stays unsettled and nothing retries automatically.
8. Pacing: a weekday daytime window in your time zone; a warm-up ramp keyed to days since the first live send (count the canary as that first send), starting at 10 a day and rising over about two weeks to the ceiling you configured; a random gap of a few minutes between messages, so one mailbox never sends in bursts and stays well inside what a single person could plausibly write. A follow-up is a new wave, planned and approved like the first; the touch limit and the minimum gap are what space it.
9. The message: plain text; a real person's name in From; at most one link; no tracking pixels and no tracked links; a List-Unsubscribe mailto header carrying the per-recipient token; a visible opt-out line; the solicitation line; your postal address in the footer (skeleton).
10. sync reads the mailbox. A live send runs it first and refuses to send if the mailbox could not be read; it runs again every few sends during the run. A reply stops that contact's sequence, is written as a note on the CRM lead so the hand-raiser rule takes over (a personal answer within one business day), and opens a task so a person sees it. A hard bounce suppresses the address and counts toward the circuit breaker; a soft or delayed notice is only recorded. An opt-out is detected by phrasing patterns (“remove me”, “take us off”, a subject beginning “unsubscribe”, a lone “stop” on its own line), or by any mail arriving at the unsubscribe alias. “Stop by the shop sometime” is a conversation, not an opt-out. Honoring never waits for a person: an opt-out matched by its token is honored silently; one recognized from phrasing or from the sender's business domain is honored at once and opens a task so a person can glance at it; one from an address that matches no contact suppresses that sender and, unless it is a consumer-mail domain, every contact at its business domain, and opens a task.
11. Anyone who tells you to stop by any other channel, a phone call, a word at the counter, a reply to your company address: run suppress with the address and a reason the same day, and add a note on the CRM lead. The compliance box applies to every channel, not only the mailbox.
12. Circuit breaker: a bounce spike over trailing sends, repeated provider errors in a row, or any single bounce or provider refusal that blames the sender (unsolicited mail, authentication, unusual volume) halts the mailbox until a person runs resume after reading why.
13. When it stops: run status and read the halt reason and the last attempt rows. A bounce spike means the list is the problem: stop that category, re-verify or suppress it, and plan a fresh wave. Repeated provider errors mean the provider or the credential is the problem: wait, confirm the mailbox is reachable, then resume. After resume, the remaining recipients continue only if the approval is still valid and the content unchanged; if the approval aged out during the halt, plan again. A paused wave follows the same rule.
14. Log every attempt: contact, wave, approval, timestamp, outcome, and the guard that stopped it if one did.

The checks before every message (roughly sixteen)

Then reserve, then send. Cheap global checks run first so an incident, a remote pause or an off-hours run never reaches per-contact logic. Approval is checked before window and cap, so an unapproved wave never even learns its quota.

Steps

1. Leave the canary gate closed. Until an operator sets canary_checked_on in the configuration file, the sender will only address the own-address list from that file; every other recipient is left pending.
2. Plan a wave of one: yourself, at a different provider. Approve it properly through the task tracker, confirmation word and all. No shortcuts for the test.
3. Send live. Open the message and read the headers against the checklist below.
4. Reply to it, then run sync: your contact row shows replied, the sequence is stopped, and a task appears. Plan a second wave of one to another address from your own-address list, approve and send it, reply “remove me” from that address and run sync: that contact becomes suppressed and a task appears. Finally, from a third address you can afford to lose (suppression is permanent; there is no undo command), send “unsubscribe” to the alias and run sync again: that sender is suppressed and a task appears, because the address matches no contact.
5. Only now set canary_checked_on in the configuration file. The gate opens.
6. First real wave: one category, the smallest sensible group (ten or fewer), hand-raisers or hand-researched first. Approve, send, and watch sync for two working days before planning the next.

First-wave checklist

Steps

1. Every Friday, fill in one scoreboard: rows are the funnel categories, columns are the channels (email, call, door, letter), and each cell holds three numbers: delivered first touches, genuine replies, meetings booked.
2. Count a reply as genuine only if a person wrote it. Auto-replies, bounces and “unsubscribe” are not replies; the last two are suppressions.
3. You have no open or click numbers, on purpose. There is no tracking in the message. Replies and meetings are the signal.
4. Decide next week's hours from the table. The landscaper may find that doors beat email for property managers and email beats doors for HOA boards; the bookkeeper may find that letters to new filings outperform everything else. Follow the meetings.
5. Review the claims checklist and the category briefs monthly against what people actually wrote back.
6. Keep the suppression list growing and shared with everyone who sends for you. Every opt-out that reaches you by phone, in person or at the company address goes in with suppress the same day.