Guide
Approval-first outreach without the bottleneck
Most AI SDR tools sell autonomy: connect a mailbox, describe your ICP and let it send. Approval-first outreach keeps the agent and drops the autonomy. The agent finds a reason to write and drafts the message. A person approves it, with edits if needed. Only then does it send.
The usual objection is that a human on every send becomes the bottleneck. It does, if approving one email means opening four tabs. This guide covers how to make human-in-the-loop outbound take seconds per draft, which rules have to hold when nobody is looking, and how to decide whether a play should ever run without you.
Why put a human on every send
Small markets don’t refill. If your buyers number in the hundreds, each bad message spends something you can’t buy back. The signal-based outbound guide covers this for comms buyers.
Sender reputation is slow to build and quick to lose. A run of complaints or bounces follows every later message from that domain, including the good ones.
Your outbound is your brand to everyone who hasn’t heard of you yet. For most prospects, the first email is the whole impression.
Agents make confident mistakes. A model will write a fluent, specific email about the wrong company because a headline matched a similar name. It will congratulate someone on a role they left, or cite a story that says something slightly different. None of these arrive with a warning, and a person catches most of them in a few seconds.
Approval produces data. Every edit and every rejection tells you what the drafting agent gets wrong. Fully autonomous sending throws that away.
If you are weighing an AI SDR alternative, this is the trade: you give up hands-off volume and get messages you’d sign, plus a record of how good the drafts actually are.
Make approval cheap
Put the context in the draft
The reviewer shouldn’t need another tab. Each draft should arrive with:
- the person: name, title and email
- the company and its tier
- the signal that triggered it: type, headline and source link
- the score and the reasons behind it
- the play and the step, so you know if it’s a first touch or a follow-up
- the hook, meaning what your product found, kept separate from the prose
Approve with edits, and keep the original
Most drafts need a small change. Let the reviewer edit in place and approve in one step. Store the original next to the version that sent. The share of drafts that needed edits, and how big those edits were, is the best measure you have of draft quality.
Batch it
Review once or twice a day at a fixed time, not as drafts trickle in. Sends wait for the recipient’s send window anyway, so a morning batch rarely delays anything. Order the queue oldest first so nothing sits.
Reject with a reason
A rejection without a reason teaches nothing. Use a short, fixed list and map each reason to a change:
| Reason | What to change |
|---|---|
| Wrong company (name collision) | Tighten detection, or add a check on each candidate |
| Stale signal | Shorten that signal type’s freshness window |
| Wrong person | Fix persona titles or priorities |
| Off voice | Add a voice rule or a banned phrase |
| Weak hook | Rework the offer or the analysis behind it |
Count reasons every week. A pattern is a config change, not a coaching note.
A 30-second review
When you approve AI emails before sending, check the same seven things every time:
- The signal is about this company, not a namesake.
- The signal is still current.
- The person holds the title the draft assumes.
- The first sentence is about them, not you.
- Every claim about their coverage has a source.
- There is one ask.
- It is under the word limit.
Guardrails that live below the UI
An approval button is a UI rule, and UIs get bypassed: a script, a bulk import, a teammate in a SQL client, an agent calling the API, a bug. Outbound compliance guardrails that protect recipients belong in the database, where they hold for every caller.
| Rule | What it prevents |
|---|---|
| A reply stops automation. The person’s play ends, queued automated drafts are canceled, hand-written drafts stay, and the person is marked engaged. | A follow-up landing after someone already answered |
| Suppressions are stored by address and by domain. Suppressed recipients can’t be approved, scheduled or sent to. | Emailing someone who opted out, even after their record is deleted and re-imported |
| A hard bounce adds a suppression automatically | Repeated sends to a dead address |
| One running play per person | Two plays emailing the same lead |
| A sending domain belongs to one workspace | One product’s campaign hurting another product’s sender reputation |
| Events are append-only | Losing the record of who approved what, and when |
The detail in the first rule matters. When someone replies, the automated follow-up should die, but the reply you were writing by hand should not.
Validate the config, not only the messages
Plays are config, and config can quietly switch approval off. Validate each play against the brain it runs under, and refuse an auto play when the brain requires approval:
# brain
pace:
mode: approve# plays/new-leader.yaml
slug: new-leader
mode: autoerror: mode is auto, but the brain's pace.mode requires approval for every draftA few more checks pay for themselves. Fail on unknown keys, so a typo isn’t silently ignored. Reject a send with no draft before it. Start every new play as a draft that does nothing until someone marks it active.
When to graduate a play to auto
In a small market, possibly never. In a large one, it can make sense for a play that has proven itself. Set the bar before you start, and decide from data rather than from one good week.
An example bar, which you should set for yourself:
- the last 100 drafts from this play were approved with only minor edits
- none of them were rejected for wrong company or wrong person
- replies from those drafts are steady, over enough sends to tell
If a play clears the bar:
- Graduate one play, not the workspace. Because validation ties play mode to the brain, going automatic is a deliberate change to both files, not a flag flipped by accident.
- Keep every database rule. Auto changes who approves, not what can be sent.
- Keep sampling. Read a share of automatic sends each week, and move the play back to approval if quality slips.
Where Optic fits
Optic GTM is approval-first. The approval inbox is built: list_approvals returns drafts oldest first with the person, title, email, company, play, triggering signal and its link, subject, body and hook. The database rules above are built and enforced in Postgres, and so is the validation that refuses auto plays under a brain that requires approval.
Drafting, sending, and approve and reject with edits are next on the build plan. approve keeps the original draft for the edit-rate metric. Gmail sync, which brings replies in, is next too, so stop-on-reply is enforced in the database but depends on that sync to see replies. A web UI with an approval screen is planned. More on the product page, the security page, and how the tools work in MCP for GTM.
If you want drafts you approve rather than an SDR you supervise, early access is the place to start.