AI email triage: sorting the shared inbox without losing the personal replies

AI email triage: the short answer

AI email triage means software reads each email that reaches your shared inbox, labels it, and sends it to the one person who owns that kind of email. Where the answer already sits in your records, it drafts the reply too. Automate the sorting, the routing and those routine drafts. Keep a person on complaints, bad news, money, legal letters and anything that makes a promise.

This guide is for the owner or operations lead of a firm of 10 to 50 people, where info@ or office@ is read by whoever has a minute. Some emails get two answers and some get none. Somebody has probably pitched you an AI agent that promises to answer them all.

Most guides to AI email triage come from tool vendors, and they end with the software replying on its own. We build business automations, and we would stop a step earlier. Sorting happens to every email, and a wrong label is cheap to fix. Sending is where customers notice, and where a stranger's email can start giving your software instructions.

What AI email triage does, job by job

Triage is a chain of small jobs. Software can do nearly all of them. Sending is the one that should stay with a person.

That shape is a workflow with one AI step, the reading. Anthropic, which makes the Claude models, calls this pattern routing: it "classifies an input and directs it to a specialized followup task". Its own example is sorting customer service queries into general questions, refund requests and technical support.

No job in the chain needs the model to choose what happens next, so we would build triage as a workflow rather than an agent. Our comparison of AI agents vs workflows explains why that shape is cheaper to run and easier to check.

Routing: a short list of categories, each with one owner

Routing works when every category has one owner and a time by which someone replies. So start from who should own each email, not from what it's about.

Say you run a 20-person lettings and property management firm. The office@ inbox gets repair reports from tenants, viewing requests, landlords asking about statements, contractor invoices and the odd solicitor's letter. The list might look like this.

Contractor invoices leave the inbox altogether. Our guide to automating invoice processing covers what should happen to them next.

Four rules keep a list like this working.

1. Check the sender before the model reads anything. If the sender is a contractor on your books and a PDF is attached, a plain rule can call it an invoice. Save the model for emails your records can't place.
2. Keep the list short. Every extra category is one more pair the model can confuse, and one more name your team has to remember.
3. Give "unsure" an owner. A folder called "other" that nobody owns makes the inbox look sorted, while the emails in it sit as unread as before and harder to find.
4. Store the reason as a field. With each label, record the model's confidence and one reason from a short fixed list, such as "known landlord" or "mentions a deposit". A field can be counted, so after a month you'll see which categories the model confuses and which senders keep landing in "unsure".

Write the urgent triggers yourself: gas, leak, flood, no heating, locked out. Match them on the words in the email as well as on the model's label, so one wrong label can't bury an emergency. The first reply to an emergency should be a fixed message a person wrote in advance, saying what to do right now. An emergency should never wait in a queue while someone approves a draft.

Drafting replies from your own records

A draft saves time when the answer already sits in one of your systems, such as the diary or the accounts, and the email only asks for it. So the order matters: the workflow looks up the facts first, and the model only turns them into a short reply.

If the lookup finds nothing, there is no draft, and the email goes to its owner with a note saying what was missing. A model asked to reply without the facts will still write something, and it will sound right.

Keep three things out of every draft: prices, dates nobody has confirmed, and anything that admits fault. Each is a promise, and your customer will hold you to it. Our checklist of what not to automate with AI explains why promises stay with a person.

Judge a draft by the minutes it saves. A viewing reply that takes four minutes to write and twenty seconds to check is worth drafting. A reply the person has to rebuild from the sources is not, because checking it takes as long as writing it.

Show the drafting step 20 of your team's best past replies in each category, plus a few lines of house style, so drafts start in your voice. Then watch the approval itself. A person who sends every draft unread is a rubber stamp, and our guide to designing the approval step covers how to prevent that.

The replies that stay personal

Some emails are the relationship itself. For those, the automation's job is to get the email to the right person fast, and then step back. Keep these with a person:

• Complaints, and any email from someone who is clearly upset.
• Bad news: a delay, a refusal, a deposit deduction, rent arrears.
• Money beyond a statement: refunds, fees, prices and disputes.
• Legal letters, and requests for someone's personal data.
• Hard moments in a customer's life, such as a bereavement or an illness.
• A first enquiry from someone who could matter a great deal, such as a landlord with twenty properties.

Research on AI-written messages points the same way. In a 2025 study of 1,100 professionals, Peter Cardon and Anthony Coman showed people a supervisor's congratulations message written with low, medium or high AI help. With high help, only 40% to 52% saw the supervisor as sincere, against 83% with low help. The authors conclude that AI suits routine, factual messages, while messages that need empathy or praise are better written with little of it.

A 2023 study in Scientific Reports found a twist. AI-suggested replies made conversations faster and more positive, but people rated their partner more negatively when they suspected AI was writing. A customer who complains and gets a smooth reply that could have gone to anyone will suspect exactly that.

For these emails, let the automation prepare the person instead: the last few emails with that sender, their open jobs, and what was promised last time. The reply starts informed, and it is still theirs.

Requests for personal data

One category deserves its own trigger. Under the UK GDPR, a subject access request, where someone asks for the personal data you hold on them, needs no special wording. The ICO's guidance says the person doesn't have to send it to a specific contact either. You must respond within one month of receiving it.

So a request can arrive in the shared inbox as "send me everything you have on me", halfway down a complaint. Give it its own category, match the words as well as the label, and route it to someone who knows the clock is running.

Two people, one email: ownership in a shared inbox

A shared inbox fails in two classic ways: two people answer the same email, or nobody answers because each assumed someone else had. Routing fixes most of both by giving every email one owner. Three habits close the rest of the gap.

Re-read the thread just before anything is sent. A draft made at nine can be wrong by ten, because a colleague replied or the customer wrote again. The send step should check the thread's latest message and stop if it has changed. Help Scout builds this in: its collision detection stops a reply from sending if someone else updates the conversation in the meantime, and holds it for review.

Send each chase to one person. An email with no reply after the set time goes back to its owner, not to the whole team. A reminder addressed to everyone is a reminder nobody owns.

Close with a reason. When an email needs no reply, such as a newsletter or a thank-you, the person picks why from a short list. "No reply" then becomes a recorded decision, and the only silent emails left are real gaps, which the chase will find.

An email is instructions written by a stranger

Anyone can email your shared inbox, and a model reads every word of each message, including text a person can't see. So the step that reads email should have no power to act on it.

Microsoft's and Google's own assistants have both been caught out. In June 2025, researchers at Aim Security showed that one crafted email could make Microsoft 365 Copilot pull internal data and send it out. Nobody had to click anything (Cybersecurity Dive). Microsoft said the issue was fully addressed and that it had no evidence customers were targeted.

A month later, a researcher reported through 0DIN, a Mozilla-backed bug bounty programme for AI, that Gemini in Gmail could be fooled in a similar way. Instructions hidden in an email, in zero-size or white text, made its "Summarize this email" button add a fake security warning that seemed to come from Google.

OWASP, a non-profit that ranks the top security risks for AI applications, uses almost this exact setup as an example. An assistant reads a mailbox to summarise it, but its tools can also send. A malicious email tells it to search the inbox for sensitive information and forward it to the attacker. OWASP's fixes are plain: tools that can only read, read-only permissions, and a person who reviews and presses send on every email.

Build triage the same way:

1. The reading step gets no tools. It returns a category from your list, the details it found and a reason, and nothing else.
2. Code does the moving. It checks the category exists, looks up your records and routes the email. A label that isn't on the list goes to "unsure".
3. Hidden text and formatting are stripped before the model reads the email, and the model never follows links.
4. Attachments become text first, under the same limits. A scan with no text layer gives the model nothing to read, and our guide to reading documents with AI covers that step.
5. Only a person sends, apart from fixed messages written in advance.

With those limits, a hostile email can at worst land in the wrong queue or produce an odd draft, and a person sees both before anything leaves.

Rolling it out, and checking that it worked

Measure the inbox before you change anything. For two weeks, record the time to first reply in each category, the emails answered twice, and the emails that waited more than two working days. That is your "before". We take this measurement before every automation we build, because "it feels quicker" isn't evidence.

Then switch on in stages:

1. Suggest only. The label and owner appear beside each email, but a person still sorts. Count how often they disagree, category by category.
2. Route the categories where they rarely disagree, and keep the rest in suggest mode.
3. Add drafts one category at a time, starting where the facts are easiest to look up.

Each week, read 20 emails the automation routed that nobody touched, plus everything in "unsure". A wrong label that nobody corrects is the failure that stays hidden, because the inbox still looks tidy.

Then take the "after": the same three numbers, category by category. If the time to first reply fell and nothing got answered twice, carry on. If a category keeps landing in "unsure", fix its definition before adding the next.

When you don't need AI email triage, or us

Skip the build in these cases.

• One person reads the inbox and keeps up. They are the triage, and an AI step is one more thing to maintain.
• Most emails ask the same thing. Fix the cause instead: if half the inbox asks for viewing times, put bookable slots on the listing. Map the process, delete what nobody needs, and automate what's left.
• The sender or subject predicts the category. Outlook rules and Gmail filters move email by sender or by the words in it, with no AI at all.
• You already use a help desk. Zendesk's intelligent triage labels intent, sentiment and language, and Help Scout's AI Drafts writes replies for review. Set up what you already pay for first, with the rules above.

A build pays when routing needs your own systems to decide, such as the property database, the job system or the accounts. It also pays when you need a record of why each email went where.

Read your last 100 emails with two questions

Scroll back through the last 100 emails in the shared inbox. For each one, write down who should have owned it, and whether the answer already sat in one of your systems. Note how long it waited for a first reply.

The owners you wrote down are your categories. The emails whose answers sat in a system are your drafting list. Everything else is a personal reply, and now you know roughly how many there are. The waiting times are your "before".

Questions

Can Microsoft Copilot do this in our shared mailbox already?

Partly. Copilot in Outlook now works in shared mailboxes for people with a Copilot licence, and Microsoft's guide lists reading, summarising and drafting. That helps whoever has an email open. Triage happens before anyone opens it: which category, whose job, how fast, and a record of why. If your team already has Copilot, use it for drafting and build only the part it doesn't do.

Do we have to tell customers a reply was drafted by AI?

Not when a person reads, edits and sends it, on our reading of the rules. Since 2 August 2026, the EU AI Act has required AI systems that interact with people directly to tell them they are AI. The European Commission's FAQ says direct means the AI communicates with the person without a human intermediary. A system that replies and keeps replying on its own is a different case, so tell people. We aren't lawyers, so check anything close to the line with yours.

Can an AI model read customer emails under GDPR?

Yes, with the right contract in place. Customer emails are personal data, and a provider that processes them for you is a processor. Under Article 28 of the GDPR, and the same article in the UK GDPR, you need a written contract with it. Check the provider's business terms for that contract, for whether it trains models on your data, and for where it processes it.

How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.