Approval Workflow for AI-Drafted Emails: How to Set It Up

An approval workflow for AI-drafted emails is the piece that keeps the drafting engine honest. The policy question — who is even eligible to have AI draft on their behalf — is a different document, and lives in the autonomy-policy post. This one is about what happens after a draft exists: which items send themselves, which items wait for one reader, which items wait for two, and what your team does the morning the queue is 400 drafts deep and the reviewer is out sick.

Most approval schemes fail in one of two ways. They approve everything, so every reviewer becomes a bottleneck and the AI stops saving anyone time. Or they approve nothing, so the AI sends things it should not have, quickly, at scale. The working shape sits in between and is boring: three routes, an SLA on queue age, and one clause that describes what happens when the SLA breaks. This post walks that shape end to end, with a scoring table you can adapt, a worked example on a refund thread, and an honest recommendation on which tools make the workflow enforceable rather than aspirational.

The short answer: three routes, one SLA, one escape valve#

Route AI drafts by two axes — stakes and reversibility. Low-stakes and reversible messages (out-of-office replies, meeting confirmations, receipt acknowledgements, internal 'got it') self-approve inside a named allowlist. Everything else waits in a single-reviewer Copilot queue, where the mailbox owner reads and clicks send. High-stakes or irreversible items — legal, refunds above a threshold, executive comms, first outreach to a new relationship, price changes, hiring or termination language — require two reviewers, and the second one has to be someone other than the mailbox owner.

Then put a service level on the queue itself: median queue age under one hour, tail (95th percentile) under four hours during working hours. If a draft sits longer, escalate to the reviewer's manager and, on the next breach, downgrade the drafting user to Manual until the queue is drained. That last clause is the escape valve, and writing it into the policy up front is how you stop the queue from silting into a backlog everyone learns to route around.

Criteria that actually matter#

The failure mode of most approval schemes is that they judge each draft on gut instead of on the same three or four attributes each time. The criteria below are the operational ones — the ones a reviewer can run through in ten seconds while looking at a draft, and the ones a rule engine can apply automatically when the human is not the fastest step in the loop.

• Stakes tier — what happens if the message is wrong. A misfiled receipt confirmation is a shrug. A wrong refund amount is a chargeback and a compliance flag. A wrong legal deadline is a claim. Tier your categories in writing before you tier your workflow.
• Reversibility — can the send be pulled back. A one-tap undo window (usually 10–30 seconds) is not the same as recallable delivery; assume undo fails and score reversibility on whether the recipient can act on the message in the interval.
• Recipient class — known contact on a live thread, known contact on a new subject, or a first-time recipient. First-time recipients almost always need a human read; a live thread with a known contact usually does not.
• Time sensitivity — does the recipient need this in ten minutes or by end of week. A queue SLA is the wrong tool for an eleven-minute reply. Route time-critical drafts around the queue via a named on-call reviewer, not by weakening the queue itself.
• Reviewer coverage — who is awake and paying attention. A queue with one reviewer and a laptop that closes at 5 pm is a queue that stops working from Friday afternoon to Monday morning. Coverage is a workflow input, not a footnote.
• Approval enforced by the tool, not by habit. If a busy user can send by pressing the same key they always press, the approval step will not survive a bad Tuesday. The tool has to make sending without review the harder path, not the easier one.

Scoring table: route the draft in ten seconds#

Use the table below as a triage grid a reviewer runs across the top of every draft. It is not exhaustive — every business has a category that does not fit — but it covers the eighty percent of drafts that clog queues, and it names the SLA and the breach behaviour up front so the workflow does not quietly degrade.

Where the routing image lives#

The picture below is the four-route grid the table describes, drawn as flows out of a single inbox. Reviewers keep it pinned when they onboard; new joiners can point at it during the first week and get the shape of the workflow before they get the shape of the policy behind it.

Worked example: a refund thread on a Tuesday afternoon#

A customer emails at 2:14 pm asking for a refund on an annual plan they cancelled after the renewal charge. The AI drafts a reply that offers a prorated refund. Walk through what should happen next, because this is where most workflows quietly fail.

Notice what the example does not do. It does not add a second reviewer just because the topic is money — the threshold decides that, in writing, once, so the workflow is predictable. It does not require the reviewer to open a second tool to see the queue. It does not let a Tuesday-afternoon calendar block the whole company's outbound. Each of those decisions is boring, and each of them is where the workflow lives or dies.

Red flags: signs the workflow will silt up#

If your draft approval scheme shows any of the patterns below, fix them before you widen the number of people using AI. Each is a shape we have watched become the reason a team quietly stops trusting the tool.

• Every draft needs approval. If the AI is not allowed to send a meeting confirmation to a colleague without a click, the reviewer becomes the bottleneck the AI was supposed to remove — and starts approving without reading.
• The queue lives in a different app from the inbox. A queue you have to remember to open is a queue that grows overnight. It has to sit inside the mail view the reviewer is in anyway.
• There is no SLA on queue age. A workflow without a clock is a workflow that runs on whoever is loudest. Median under one hour and a named breach behaviour is the minimum shape.
• One reviewer covers everything. Vacation, illness, or a bad calendar day and the queue backs up. Name a backup approver for every category, in writing, with the same permissions as the primary.
• Approval is a policy, not a control. If the tool lets a busy user press send-anyway with one keystroke, the approval step will be gone by the second bad Tuesday. Approval has to be enforced by the tool, not by employee habit.
• There is no downgrade clause. When the queue silts up, teams work around the queue. Writing 'the drafting user drops to Manual until the queue is drained' into the policy up front is what stops the workaround becoming the norm.
• The audit log records the send but not the edits. A draft that changed materially between AI and human is a different event from one that went out as drafted, and reviewers have to be able to tell them apart later.

What we would pick, and why (honest)#

The workflow is only as strong as the tool that has to enforce it. A three-route scheme with an SLA and a downgrade clause needs a mail client that makes the approval step the default path rather than an optional one — where a draft does not send until a human clicks, the queue lives in the same view as the inbox, and the audit log distinguishes drafted-and-sent from drafted-edited-and-sent. That is exactly what AI Emaily's Copilot mode is for. We build AI Emaily, at aiemaily.com. Copilot means every AI draft waits for a human to approve before send — the tool enforces the step, not a policy you hope people follow. Autopilot is the named allowlist on top of that: a set of routine categories you sign off on once, so the reviewer never sees a confirmation for a calendar RSVP.

AI Emaily runs on Gmail, Outlook, and any IMAP account, so a mixed-provider team can hold a single workflow across all of it. The audit log records the draft, the approver, the model tier, the classification, and any edits between draft and send. Voice comes from a user-set Personal Context brain and per-client profiles you configure — not from silently reading past mail — which matters when you are writing an approval policy an auditor will read. Packaging is a 7-day free trial on Pro and Autopilot (card required, $0 if cancelled before day 7); current numbers are on aiemaily.com/pricing.

Where AI Emaily is not the right pick: if your review workflow is a team inbox with multi-assignee routing, SLA reports per assignee, and per-message internal comments — the shared-inbox helpdesk shape — Missive and Front have built harder on collaborative assignment, per-conversation chat, and rule-engine routing for shared queues than we have. For a support desk where two agents on the same ticket is the default rather than the exception, that is the honest recommendation. AI Emaily is built for individual mailboxes and small teams where each person is the primary approver on their own drafts; the shared-queue helpdesk shape is a different tool.

Getting the workflow into production#

Write the three routes and the SLA into the same document as your AI email governance policy — one page, not five. Configure the tool to enforce the routes rather than describe them: allowlist for self-approve categories, Copilot for the default lane, a documented second-reviewer requirement on the high-stakes lane, and Manual as the fallback when the queue breaches its clock. Wire the audit log into the same review process your security team already runs for other logs, and put a thirty-minute onboarding on the reviewer role that walks through the scoring table on a real draft.

Then run the workflow for two weeks and count two numbers: median queue age, and the fraction of drafts sent within eight seconds of appearing in the queue. If the first is over an hour, the queue needs more reviewers or fewer categories in the Copilot lane. If the second is over about a quarter, you have theatre — rescope the categories in the self-approve allowlist so the queue only holds drafts a human actually needs to read.