You have connected AI to your customer conversations and it writes good drafts. The next temptation is obvious: let it send on its own and have someone spot-check later. That is where the trouble starts. A mistake in a draft is seen by one colleague; a mistake in a sent message is seen by the customer, and you cannot take it back. This article covers which messages AI can send without a person, which should only go out after approval, how to build the check so it cannot be skipped by accident, and how to keep it from turning into mindless button-pressing.
Where this comes from: our own incident
We had exactly the rule this article is about: no text leaves the building until a human has confirmed it. The rule was written down, and the approval gate existed and worked. Even so, our outreach automation sent 42 messages over three days that nobody had signed off.
The cause was mundane. One sending component read the wrong folder and simply never consulted the gate. The check was there; nobody had considered that it could be skipped. We halted sending, made approval mandatory in code and rewrote the templates — it turned out the copy going out was weak as well. The full write-up is in the case study "42 messages went out unapproved".
The lesson this article is built on: "we agreed not to do that" is not a safeguard. A safeguard is something that cannot be bypassed.
Which actions need approval
Approving everything leads to fatigue and clicking without reading. Approving nothing means one day you hear about a problem from a customer. A better approach is to sort actions by the cost of a mistake: how visible it is outside the company, and whether it can be undone.
| Action | Cost of a mistake | Mode |
|---|---|---|
| Answering a common question from the knowledge base (address, hours, delivery terms) | Low; the answer can be checked against the source | AI replies; a person reviews a sample |
| First message to a new contact, outreach, follow-up | Medium: reputation, complaints, account restrictions on the platform | Only after approval |
| Prices, discounts, deadlines, stock | High: the customer reads it as a commitment | Only after approval |
| Bulk send to a contact list | High: the error multiplies by the number of recipients | Approve both the text and the recipient list |
| Complaints, refunds, disputes | High and emotionally sensitive | AI drafts; a person replies |
| Legal, medical or financial wording | Critical | Human only; AI at most gathers facts |
For anything not in the table, ask one question: if this message goes out wrong, who finds out first — you or the customer? If it is the customer, it needs approval.
How to build a gate that cannot be bypassed
Approval only works if it sits on the sending path rather than next to it. Ours sat next to it: a separate component could send without passing through. These are the principles we now treat as mandatory.
1. One way out
Every customer message goes through a single sending module. No other component — the text generator, the scheduler, an import script — holds the messaging or email credentials. If it has no access, it has nothing to bypass the gate with.
2. Every draft has a status
Each message has a lifecycle: draft → in review → approved → sent (or rejected). The sender only picks up "approved" items and checks the status at the moment of sending, not when the item was queued.
3. Deny by default
If the status is missing, the file cannot be read, the database is down or the check returns something unexpected, sending stops. A failed check must mean "do not send", never "probably fine".
4. Approval is tied to the exact text
A person approves a specific version of the text, not "the message to customer X". If anyone — the AI or a colleague — edits a single word afterwards, the approval resets.
5. A log and an alarm
Every send is logged: who approved it, when, and what exactly went out. A daily job compares sent messages with approved ones and alerts the owner on any mismatch. Our failure took three days to notice; a check like this would have caught it on day one.
A checklist for your own automation:
- Can you name every place in the system that physically sends messages? More than one is a risk.
- If the approval service is down, does sending stop or carry on?
- Does editing a text reset its approval?
- Is there a test that tries to send an unapproved message and expects a refusal?
- Who gets alerted if what was sent does not match what was approved?
What approval looks like day to day
Approval works best wherever your team already spends the day — Slack, Teams, WhatsApp or Telegram. A bot posts a card and the decision takes one tap. An illustrative card (the client and details are made up):
For review: follow-up, client — interior design studio, last contact 6 days ago
Context: they asked for a proposal for a lead-handling chatbot; proposal sent, no reply.
Draft: "Hello! We sent you a proposal for handling enquiries from Instagram. If useful, I can show you in 15 minutes how it would handle your real customer questions — any day this week."
Source of facts: deal record in the CRM.
[Send] [Edit] [Reject] [Do not contact this client]
What matters on the card: the context that made the AI decide to write, the source of the facts, and a separate "do not contact" button — otherwise a rejected contact pops up again next week. For how to design the follow-ups themselves, see "Follow-up without a sales rep".
Keeping review from becoming a rubber stamp
The most common way a gate fails is not technical. Someone receives forty cards in a row, reads the first ten and approves the rest unread. On paper there is control; in practice there is none.
| Stage | What AI does | What stays with a person |
|---|---|---|
| Preparation | Writes the draft, pulls facts from the CRM and knowledge base | Sets the rules: what may and may not be said |
| Triage | Flags risky content: prices, deadlines, complaints, new contacts | Decides which categories get line-by-line review |
| Review | Highlights what differs from the template | Reads and decides |
| Sending | Sends only the approved version | — |
| Retrospective | Collects stats on what was rejected and why | Updates templates and rules weekly |
Practical ways to fight approval fatigue:
- A daily cap. If there are more drafts than a person can read carefully, the rest wait until tomorrow. Sending less beats sending unread.
- Batch by type. All complaint replies first, then all follow-ups. Switching between kinds of text is more tiring than reading similar ones.
- A reason for rejection. One button with options: "wrong fact", "wrong tone", "should not be sent". After a couple of weeks you can see what to fix in the templates.
- Seeded test drafts. Occasionally the system inserts a deliberately flawed draft and checks whether the reviewer catches it. It sounds strict, but it is the only way to know the cards are being read.
When to relax the control
Approval does not have to stay forever on every message type. But lift it category by category and based on data, not because "nothing has gone wrong for a while".
- Pick one narrow category — say, appointment confirmations where date and time are already agreed.
- Check how many of those drafts went out without edits over recent weeks. If any were edited, the category is not ready.
- Switch it to "sends automatically, a person gets a copy" for a fixed period.
- Keep sampling and keep the daily log reconciliation running.
- Keep a one-tap switch that puts the category back under approval.
Some messages should never leave approval: off-list prices and discounts, deadline promises, complaint replies and any first message to a stranger. The outreach messages that slipped through in our case belonged to that last group — and that is where a mistake costs the most. We cover how to evaluate decisions like this during a pilot in "AI pilot: the first weeks"; more on rollout is in the implementation section.
FAQ
Doesn't approval defeat the point of automation?
No. Most of the time goes into gathering context and writing the text, and the AI does that. Reading a finished draft and tapping a button takes seconds. Your team stops writing and starts editing.
Who should approve — a manager or the account owner?
Whoever owns the customer relationship and knows the context, usually the person running the deal. Reserve the manager for rare categories: non-standard discounts and serious complaints.
How do we check our current automation cannot skip the gate?
Ask your developer to list every place in the code that sends and check each one. Then run a test: create an unapproved message to your own number and confirm it never arrives. Check the code, not the process description — you already know the description.
What if messages have already gone out unapproved?
Stop all sending, not just the broken component. Pull from the log who received what. Decide who needs an apology or a correction. Only then fix it — in a way that makes a repeat technically impossible.
If you plan to connect AI agents to customer conversations and want approval built into the architecture from day one, get in touch. Cost depends on scope and data; the first conversation is to work it out.