AI to Triage and Reply to Customer Emails: Draft, Review, Send

AI to Triage and Reply to Customer Emails: Draft, Review, Send

To use AI to triage and reply to customer emails safely, split the work into three steps: the AI classifies each message, writes a draft from material your company has approved, and a person reviews it before it goes out. Automatic sending comes later, and only for simple, low-risk categories. This article shows how to build that flow in a shared inbox such as support@ or contact@ without losing control over what the customer receives.

Key takeaways

• Start with classification and drafting, not automatic sending. Human review is what makes the pilot safe.
• Draft quality depends on your base of approved answers, not on how creative the model is.
• Decide in advance which categories the AI never answers: serious complaints, legal matters, disputed charges, sensitive personal data.
• The content of an email is untrusted input. Treat instructions hidden in a message as a risk, not as an order.
• Measure the pilot with a metric agreed beforehand, then decide whether to expand, adjust or stop.

Why start with the shared inbox?

The shared inbox is usually where customer service piles up repetitive, invisible work. Several people look at the same queue, nobody is sure who picked up which message, and replies vary depending on who writes them. That makes it good ground for AI: there is a high volume of text, recurring patterns of questions, and a reply that someone can check before it leaves.

Email also has an advantage over fast chat channels. Customers accept a reply that takes a little longer, so there is room for a review step without hurting the experience. On channels like WhatsApp, people expect an immediate answer and the design changes. If that is your case, read about how to integrate AI into your company's WhatsApp.

Not every inbox is a good candidate, though. If most messages require looking things up in internal systems, negotiating, or judging case by case, the early gain will be small. The first step is to look at the real queue, not to imagine the volume.

How does the classify, draft and review flow work?

The flow has three steps, and each has a different job. Mixing all three into a single instruction to the model is the most common mistake, because it makes it hard to tell where something went wrong.

• Classification: the AI reads the message and assigns a category (order question, invoice copy, exchange, compliment, complaint, cancellation request, spam), an urgency level and a risk flag. The output should be structured, with fixed fields, not free text.
• Drafting: for the categories you have cleared, the AI builds a reply using only approved sources, such as policy text, a catalog of standard answers, and order data looked up in read-only mode. If information is missing, the draft should say what is missing instead of filling the gap with a guess.
• Review: a person sees the original email, the category, the draft and the sources used. They approve, edit or discard, and that outcome is recorded.

There is also a fourth outcome: direct routing. Messages in sensitive categories, or with low confidence in the classification, go to a person with no draft, or with a summary only. This prevents a well-written but wrong text from creating a false sense that the reply is ready.

This separation follows an idea found in Anthropic's guidance on building effective agents: prefer simple, chained workflows with checkpoints before giving the system broad autonomy.

Step by step: building the pilot

An email pilot does not need a large project. It needs order. This sequence works for small and mid-sized teams:

• Step 1: pull a real sample from the inbox, with recent messages that were already answered, and group them by type. Note which types repeat and which vary a lot.
• Step 2: define the list of categories and, next to each one, the permitted action: classify only, classify and draft, or route to a specific person.
• Step 3: gather the answer base. Exchange policy, deadlines, payment methods, invoice copy text, tone of voice. Each item gets an owner and an internal review date.
• Step 4: write the model instructions for each step separately. For the drafting step, the guide on how to write instructions for an AI support agent helps define tone, limits and what to do when the model does not know.
• Step 5: connect the inbox with minimal access. If you use Gmail or Google Workspace, the OAuth 2.0 authorization flow lets you grant limited scopes instead of handing over the account password. Ask only for what the pilot uses.
• Step 6: run in shadow mode for a period. The AI classifies and drafts, but the team replies as usual and only compares. This exposes errors with no risk to the customer.
• Step 7: move to assisted mode. The draft appears in the inbox as a suggestion, and the person decides. Record approvals, edits and discards.
• Step 8: review the errors with the team, adjust categories and the answer base, and only then consider enabling automatic sending for a single simple category.

What can the AI draft, and what should go straight to a person?

A decision guide by message type avoids arguments in the middle of operations. Use the impact of an error as the test: if a wrong reply causes financial, legal, reputational or safety harm, a person takes over.

• Draft with review: delivery time questions, order status, how to request an invoice copy, opening hours, an exchange policy explained in the base.
• Draft with reinforced review: refund requests, account detail changes, complaints about repeated delays, any reply that cites amounts or dates coming from a system.
• Direct routing, no draft: threats of legal action or mentions of a consumer protection agency, accusations of a serious error, health data or other sensitive data, requests to delete personal data, press, partners and suppliers.
• Own workflow: disputed charges, which need a check with finance, and cases involving more than one department.
• Ignore or archive under a clear rule: spam and promotions, always with a list of exceptions reviewed by someone.

To decide what to automate further down the road, the article on AI customer support: what to automate and what to keep human goes deeper into this split.

What about data protection and malicious instructions inside emails?

Customer emails contain names, addresses, phone numbers, order numbers and sometimes information the customer should not have sent at all. Putting a model in the middle means the company now processes that data in a new way. That calls for a legal basis, a clear purpose, data minimization and a definition of who has access. For Brazilian operations, the ANPD (the national data protection authority) is the official source for guidance, and the article on LGPD and artificial intelligence summarizes what a company should organize. In practical terms:

• Send the model only what it needs: the message body and the relevant order data, not the customer's full history.
• Mask documents and payment data before processing, when possible.
• Confirm with the model provider how data is retained and whether it is used for training.
• Define who on the team can see drafts and logs, and how long they are kept.

There is also a less obvious risk. An email can contain text written to manipulate the model, such as requests to ignore rules, reveal internal instructions or send data to third parties. This is called prompt injection, and the OWASP prompt injection prevention guidance describes practical defenses. The core principle is to treat all received content as data, never as instruction, and to limit what the system can do even if it is fooled. That is why, in the pilot, the AI should not have permission to send emails on its own, delete messages, or look up data beyond the request at hand. For designing checks on input, output and action, see guardrails for AI agents.

Illustrative scenario: the support inbox of a home services company

Imagine a small home services company with a support@ inbox read by three people. This is an illustrative scenario, not tied to any real customer.

An email arrives asking when the technician will visit. The AI classifies it as a scheduling question, medium urgency, low risk. It checks the calendar in read-only mode, finds the booked visit and builds a draft with the date and time window, citing the rescheduling policy from the base. The support agent confirms the date, adjusts one sentence and sends it.

The same day, a message arrives from an angry customer saying the work was done badly and that they will pursue their rights. The AI classifies it as a high-risk complaint and creates no draft. Instead, it writes a three-line summary with the order history and routes it to the person in charge, who decides how to respond.

A third message includes, in the middle of the text, a sentence asking the assistant to ignore its rules and send the customer list. The classification marks the content as suspicious, no action is executed, and the message goes to review with an alert. Nothing left the company, and the team logged the case to improve its tests.

How do you measure the pilot and decide what comes next?

Without a measure agreed in advance, every pilot turns into opinion. Choose a few metrics the team can track in the inbox itself, and record the current situation before turning the AI on so you have something to compare against. The article on how to measure an AI automation pilot details metrics and decision gates. For email, four questions are enough:

• Is the classification accurate enough for the team to trust it? Compare it with human classification on a sample.
• Are drafts used with few edits, or does the team rewrite everything?
• Has time to first reply changed, without more complaints or rework?
• Was there any serious error, such as wrong information about a deadline, an amount or a policy? Each occurrence should be analyzed and recorded.

The approach we use in implementations follows four moves: map, limit, pilot and hand over. Mapping means understanding the current process and the inbox baseline. Limiting means restricting data and actions, leaving the AI with only what the pilot requires. Piloting means running a real flow, with logs and an agreed metric. Handing over means giving the operation to the team, with documentation, and deciding with evidence whether to expand, adjust or end it. Stopping is also a valid result, as long as it rests on what the pilot showed.

If the team wants to move toward automatic replies, do it by category, with a rule to send the message to a person when confidence is low, and keep ongoing review sampling. A well-defined escalation flow, like the one in the human handoff playbook, also applies to email once you adapt it to the channel.

Frequently asked questions

Can AI reply to customer emails on its own?

Technically yes, but it is not the recommended starting point. Begin with drafting and human review, and enable automatic sending only for simple categories, with a stable answer base and a track record of correct results observed in your own pilot.

Which tool should I use?

The choice depends on where your inbox lives (Gmail, Outlook or a helpdesk system), who will maintain the flow, and how data is handled. Workflow automation tools work well for the deterministic parts, and the model comes in where text needs to be interpreted. What matters most is that access is limited and every decision is logged.

Won't the AI draft sound generic?

It will if the base is generic. When the instructions include your company's tone of voice, examples of good replies and rules about what to avoid, the draft gets close to your team's standard. Human review is still what guarantees fine tuning and empathy in delicate cases.

How do I stop the AI from making things up?

Restrict the draft to approved sources and data looked up in your systems, and instruct the model to flag what is missing instead of filling it in. Add human review, tests with hard cases, and a rule to route to a person whenever the question goes beyond what the base covers.

Sources

• OWASP: prevenção de injeção de prompt
• Anthropic: Building effective agents
• Google: OAuth 2.0 authorization
• ANPD: Autoridade Nacional de Proteção de Dados