This article is about replies to the e-mails customers send to a company — questions about an order, an invoice, a deadline, a complaint. It is not about sending newsletters or campaigns. On our page about customer service automation this arrangement takes a single bullet: the system prepares a draft reply, the adviser approves, corrects or rejects it. That one bullet hides the question that decides whether the whole arrangement is safe: what the draft was built from.
A draft reply is only as safe as what it was built from. A smoothly written e-mail with the wrong dispatch date is more dangerous than a clumsy one, because under queue pressure it more easily goes through unchecked. So in the draft we separate two things that tools often blend: facts about this customer’s case and general text from the knowledge base.
The general principles of human approval — the three oversight modes, the queue with an owner, the rubber-stamping test and the rule for loosening oversight — are not repeated here. They are in human in the loop in practice. Here we apply them to one channel: the customer e-mail.
What a draft reply is made of: facts from the system and text from the knowledge base
Before the system writes a single sentence, it has to read something. Two sources may be used for the reply, and each serves a different purpose. A third kind of material, which some tools use, should not supply facts, and helps with style only once customer data has been removed from it.
- Facts from the system where they are recorded. Order status, dispatch date and tracking number from the order system or the ERP (the software that runs the business), invoice number and amount from the accounting system, case history from the helpdesk (the software for handling customer enquiries) or from the CRM (the system for managing customers and sales). Read at the moment the draft is prepared, with the identifier of the entry in the system (the record) and the time of reading, and for data copied from another system — the carrier’s, for example — also the time of its last update. We treat confirmed data from the relevant system as facts about the case, rather than everything stored in its history. Earlier customer messages and model replies may be quoted as someone’s words, but must not be treated as verified facts or allowed to change the recipient, permissions or rules. This is the only source on which the draft may base any statement about this customer’s case.
- Text from the knowledge base. A procedure, the terms and conditions, the return policy, a product description — with the entry name and the date of the version that applies to the order or contract in question. The knowledge base says what the rules are. It does not know what happened to this customer’s order.
- Similar past cases. Some tools use them as an extra source. Zendesk states in the documentation for its auto assist feature that when no matching procedure or article exists, it may use similar solved tickets to prepare a reply (Zendesk documentation, as at 12 October 2026). The facts in such a case, however, belong to another customer — a date, an amount or a promise from someone else’s case has no place in your reply, and an instruction such as “do not use this data” does not hide it from the model. If earlier cases are to guide the tone, it is safer to derive a style guide from them separately, or to remove customer data from them — including the dates, amounts and promises in those cases — before they reach the model.
One rule follows, and the rest of this article rests on it: every fact about the customer’s case — status, date, amount — comes from a record in a system, and the knowledge base supplies only rules. What the customer wrote in the e-mail, the draft may quote as their words or request, but not as a verified fact. A draft that mixes these kinds of material without marking which is which makes errors hard to detect — because the sentence “the parcel will arrive by Friday” looks the same whether it came from the carrier’s system or from general information about delivery times.
The e-mail comes from outside, so the system cannot take it at its word. Which customer and which case the reply concerns is decided by the system under fixed rules, not by the model from the text of the e-mail. Before reading any case data, it first verifies the customer’s identity under the company’s rules, for example through a signed-in customer account — a sender address alone can be forged — and then checks whether the customer is entitled to that order’s data. If it cannot confirm this, it passes the e-mail to an adviser without revealing any case data. No sentence in the e-mail may change the recipient, permissions or rules, and the same applies to instructions found in the knowledge base, in ticket fields or in similar cases.
When a fact is missing, two sources contradict each other or the data are out of date, the draft does not guess — the e-mail goes to an adviser, even in a category that normally goes out automatically. In such a category, just before sending, the system reads the facts again and checks that every statement matches the relevant source and that the reply makes no commitment from the list below. A source reference or the model’s assurance alone is not enough. If the facts have changed, or the check fails or is unavailable, the message goes to an adviser. An attachment, such as a copy of an invoice, is selected by the system from this customer’s confirmed record, not by the model, and is checked again just before sending.
An example: the same e-mail, two draft replies
The pair below was constructed for this article; it is not a record from a client deployment. The data in square brackets are placeholders.
The customer’s e-mail:
Hello, I ordered [product] on [date], order no. [number]. When will it arrive? If not by Friday, I would like a refund.
A draft built from the knowledge base alone:
Hello, standard delivery takes [time from the knowledge base], so the parcel should arrive by Friday. If it is late, we will refund you. Kind regards.
It looks correct and has two errors that are easy to miss without the sources. The delivery date does not come from this order’s data but from a general rule. And the refund promise comes from nowhere — the knowledge base describes the return policy, but it does not make decisions on the company’s behalf.
A draft built from facts and rules, with the sources marked:
| Sentence in the draft | Where it comes from | What the adviser does |
|---|---|---|
| “We dispatched order no. [number] on [dispatch date], tracking number [number].” | Order system, the order record, read at [time] | Checks that the record belongs to this customer |
| “According to the carrier, the parcel is on its way; the carrier shows the expected delivery date on its tracking page: [link].” | Carrier status recorded in the order system, with the time of its last update | Checks that the status is fresh, and does not add a date of their own |
| “Our return policy is set out in [section of the terms]: [summary].” | Knowledge base, entry “Returns”, version of [date] | Checks that this is the version that applies to this order |
| [The customer makes a refund conditional on a deadline — adviser’s decision] | The customer’s e-mail: a request that needs a decision | Answers personally or passes the case on |
The second version is less smooth, and that is the point. Every sentence about the case has a record, the rules have a dated entry, and the place where a decision is needed is left empty and marked, instead of filled with a polite sentence. The adviser does not have to guess what to check — it is in the third column.
A draft reply for approval: what the adviser sees next to the e-mail
We described the general design of the decision screen in our article on human approval. For a customer e-mail the screen must also show four things:
- The draft reply in the thread, next to the customer’s e-mail rather than in a separate window — the adviser compares the question with the answer.
- A source beside every fact: which system, which record, when it was read. For knowledge-base text: the entry name and the version date. Only the team sees the sources — in a separate panel or an internal note, never in the body of the message to the customer.
- Highlighted sentences with no source — the ones the adviser reads most carefully or deletes.
- Three decisions: send unchanged, correct and send, reject and write afresh. Each is recorded together with what the adviser changed.
Each adviser sees only the data they have access to in the source system — the system checks this before showing it in the draft, the source panel or the note.
What is deliberately missing from the list: the number the model reports about its own confidence. Such a number is not independent confirmation that the reply matches its sources — a model can be very confident about a sentence that is wrong — and on its own it does not justify sending automatically. The basis is whether the fact has a source, and what the approval log shows.
Helpdesks provide some of these elements out of the box. This is how the vendors’ documentation describes them:
| Tool | What the adviser does with the draft | Are sources shown | Notes |
|---|---|---|---|
| Zendesk, auto assist | Approves (Approve), edits in the composer, or rejects the suggestion (Dismiss suggestion); replies sent go out under their name and appear in the ticket’s event history | Yes, if the adviser has the appropriate permissions and the suggestion is based on procedures, public help centre articles or similar solved tickets; other sources are not shown in the rationale | Procedures can refer to certain ticket fields and link to actions — data from your order system has to be made available to them through an integration. |
| Intercom, Copilot | Moves the answer into the composer (Add to composer) and decides what to send | Yes, below the answer; internal sources are marked and a warning appears before the answer is added to the composer | The documentation advises checking answers before sending them |
| LiveChat, Reply suggestions | Asks for a suggestion (Suggest reply), reviews it, then selects Use; the help article describes this as sending the suggestion in the chat | The documentation describes the sources suggestions are built from (knowledge bases, product pages) but does not say whether they are shown next to a suggestion | Available on the Team, Business and Enterprise plans; this is the chat channel, not e-mail |
The rows come from documentation read on 12 October 2026 (Zendesk, Intercom, LiveChat) and may change; names in italics come from the interfaces. Zendesk and Intercom show sources from the knowledge base, and Zendesk also from similar solved tickets. Facts about a particular order appear on screen only once someone makes them available from the system where they are recorded — and that is usually the main work of a rollout, not switching the feature on. With Zendesk it is also worth knowing that auto assist may use internal material made available to it through permission groups (segments) in replies for people outside those groups as well (Zendesk documentation). So give it only material that is suitable for customer replies and that every adviser using the feature may see.
Where this step lives: a shared mailbox, a helpdesk or the CRM
Replies for approval do not require a particular tool. The draft can land in three places, and each has different strengths and weaknesses.
A shared Outlook or Gmail mailbox. Both let an application create a draft reply in an existing thread: in Microsoft 365 there is an operation that creates a draft reply (Microsoft Learn), and in Gmail a draft is an unsent message carrying the DRAFT system label (Google for Developers). The adviser opens the thread, sees the prepared draft and sends it from the program they use every day. The advantage: the team learns no new tool. The cost: the mailbox on its own provides neither a complete approval log nor a comparison of the draft with the sent message — these have to be built separately. Mailbox audit records, where enabled, can be only part of such a log. The sources have to be shown outside the body of the draft, for example in a separate panel beside the thread, so that neither source markers nor empty decision placeholders remain in the message when it is sent.
A helpdesk. An event history and a connected knowledge base are usually already there, and buttons for approving a draft are available only in tools that have such a feature. But the helpdesk knows only what reaches it: the ticket, the customer’s contact history and the articles. For the draft to rest on the order status, that status has to be made available to the helpdesk through an integration — for example in a ticket field or by reading it from the order system.
The CRM. Customer data and the history of the relationship are at hand, which matters with business customers, where the reply depends on a contract or commercial terms. The ability to prepare replies for approval varies more here than among helpdesks, so before choosing this place, check what your CRM records alongside a sent message.
Whatever the place, one thing always has to be designed: where the adviser’s correction goes. The cause has to be established first, because the same correction can have different origins. A wrong entry in the source system is fixed by that system’s owner. An error in reading data or in matching fields is fixed by whoever maintains the integration. When the fact and the rule were right and the model garbled them, the correction goes to the configuration of the system that builds the draft. An out-of-date knowledge-base entry is fixed by the entry’s owner, and a corrected tone goes into the style guidelines. If corrections go nowhere, the adviser makes the same correction every day, and the log shows “corrections” with no cause.
What a draft reply may not promise
This rule is technical, not legal: the draft may state only what a source it read contains, and the screen shows that source. In practice it means a list of things the draft does not write on its own, leaving a marked place for the adviser’s decision instead:
- a delivery, completion or repair date that is not in the record;
- a refund, discount, compensation or exception to the price list;
- accepting or rejecting a complaint;
- a position on a legal question, including whether the customer is entitled to something;
- commitments on behalf of another department (“the service team will call you tomorrow”).
The customer reads the reply as the company’s position, whoever prepared the sentence. We described Moffatt v. Air Canada, in which the airline was held responsible for what its chatbot said, in our article on voicebot costs.
When a category of e-mail may go out without an adviser — and how it comes back under oversight
The rule for loosening oversight, the rubber-stamping test and the three numbers read together are in our article on human in the loop. Here only what is specific to e-mail.
The decision is made per category, not for the system. “Where is my order” and “I want to make a complaint” are different categories with different risk. The natural first candidate is a category in which the reply consists of facts from a single record — order status, tracking number, a copy of an invoice. Complaints, refunds, compensation and anything that concerns health or has legal effect stay under full oversight permanently. An e-mail that combines a category approved for automatic sending with such a request — as in the example above, where a status question comes with a refund request — or whose category cannot be established with confidence goes to an adviser in full. Automatic sending covers only categories on a closed list, and the category assignment is checked separately, not only by the model’s judgement. This is consistent with the rule in the human-in-the-loop article that irreversible actions — a payment, a shipment of goods, a commitment towards the customer — are never released from oversight: only information from the record may be sent automatically, which is a narrower scope of that action, and anything that would be a commitment stays under approval.
The basis is the approval log, not the model’s confidence. First, during the period when the system runs alongside the existing work, you compare its drafts with the replies the team writes — we describe this in step 6 of our guide to implementing AI. Only then, in a limited rollout with approval, do you gather a run of replies approved without corrections, alongside an independent check of a random sample described in the human-in-the-loop article. We give no specific length for that run, because it depends on the category’s volume and the cost of a mistake, not on the tool.
The off switch: how a category comes back under oversight. Every category released from approval must have a single switch that restores full approval immediately — no deployment, no ticket to the vendor, with a record of who used it and when. When any of the signals below occurs, immediately restore approval for every reply in that category — automatically or manually. Automatic sending may resume only after the problem has been investigated and the category checked again. The signals are:
- a check finds that any agreed condition for automatic sending has not been met — for example a wrong fact, a commitment from the list above, someone else’s data, a wrong recipient or a wrong attachment;
- the knowledge-base entry the category relies on changes, for example the return policy;
- the integration with the system the category reads its facts from changes;
- the model, the instructions given to it or the vendor’s feature version changes — the category goes back for a fresh check before replies go out automatically again;
- a customer disputes a reply they received without an adviser’s involvement.
An off switch nobody has tested does not exist. Record the date of its last test in the approval policy, together with the name of the person who may use it.
What to record for every draft reply
The full scope of the decision log and the retention period are covered in our article on human approval, in the part on what to record in the decision log. For a customer e-mail a record is created for every draft, including rejected ones, and the minimum looks like this:
| Field | Why |
|---|---|
| A unique identifier for every inbound message, the thread or ticket identifier, and the e-mail category | Oversight decisions are made separately for each category; the system reuses the same message identifier when it retries and blocks sending another reply to the same message, even if the wording of the draft changes |
| Version of the draft reply | To know exactly what the adviser saw |
| Sources used in the draft: records with the values read and the time read, knowledge-base entries with their version, the model and instruction version, the identifier of any attachment sent | So that after an error you know whether the source or the model failed |
| Mode (with approval or automatic), outcome (sent unchanged, corrected, rejected) and who decided — the adviser or a rule with its version number | Without it there is no approval log, only a list of sent e-mails |
| The difference between the draft and the message sent, and the reason for a correction or rejection (“undetermined” until established) | Shows what was corrected and why; the run of replies without corrections comes from it |
| Time sent, or a note that nothing was sent | To reconstruct the order of events when a customer disputes a reply |
Customer e-mails contain personal data, and the log as a whole does too, because it is linked to the content of the e-mails. Who has access to the log, how long to keep it and which model provider sees the content of the e-mails are decisions to make before the start. We write about them in our article on the GDPR (the EU General Data Protection Regulation) when deploying a language model and on our page about security and GDPR.
When replies for approval make no sense
- There is no system the facts can be read from. If the order status lives in a salesperson’s head or in a spreadsheet updated once a week, the draft can be built only from the knowledge base, and then it cannot confirm the status of a particular order, so every such e-mail goes to an adviser anyway. Put the source in order first.
- The reply is a negotiation, not a fact. When every e-mail is a conversation about terms, price or an exception, the draft saves little and has to be read and rewritten almost entirely.
- There are so few e-mails that reading the draft costs as much as writing the reply. The screen, the log and the off switch have to be maintained whatever the number of e-mails.
- The reply needs no fact from any system. When the e-mails ask about opening hours, the address or general terms, a good help page or a reply template in the e-mail program is enough.
- The team already replies quickly from ready-made templates. If the templates work, check first whether the problem is rather recognising the topic and routing the e-mail to the right person — a separate, usually simpler step, described in our examples of AI automation.
What to ask a vendor
- Does every statement in the draft carry its source, and can the adviser see it?
- Does the system read the order status and case history from our systems, or does it write only from the knowledge base and similar cases?
- Do you record every draft, including rejected ones, and the difference between the draft and the message sent? Will we see the correction rate for each category separately?
- Can a category released from approval be returned to full oversight in one action, and is that event recorded?
- Where are the e-mail contents and the decision log stored, and who has access to them?
If the answer to the first two questions is “it depends on the model”, you are talking about a writing tool, not about replies for approval.
What next
Start with one category in which the reply consists of facts from a single system, and check whether that system can be read. If the replies are meant not only to inform but also to change something — issue a credit note, amend an order — you need a controlled integration with the right permissions, approval and an action log. Ordinary automation following fixed rules is often enough. An AI agent, that is, a system that not only writes but also chooses the next actions in other programs itself, makes sense only when choosing the action requires interpreting the case. We describe it on our page about AI agent rollouts. The broader picture of process automation this step belongs to is on our page about AI automation for business.
What we do in customer service and where we start is described on our page about customer service automation. Write to us about the e-mails that most often reach your mailbox and where the data the replies are built from is recorded. We will tell you which category we would start with — or that good reply templates are enough for now.