Reef TRHSomewhere in a shared inbox this morning, a customer wrote to say their claim was urgent. It sat at position four hundred and something, behind a request to change a mailing address and a question about a password. A person would get to it eventually: read it, realise it mattered, and forward it to the right desk. By then it had been two days.
Nobody decided to make that customer wait. That is the uncomfortable part. The inbox decided, quietly, by doing the only thing a queue knows how to do, which is serve things in the order they arrived.
The inbox sorts by arrival, not importance
For a lot of businesses this is the real shape of "we're drowning in email." Not that the volume is impossible, but that the volume hides the one message that needed a person an hour ago. At an insurer we worked with, more than 10,000 emails landed every day: claims, renewals, policy questions, complaints, all pouring into one shared address. The team spent its mornings not answering customers but reading and routing, opening each message, working out what it was, and passing it along. The answering, the part the customer actually felt, started only after the sorting was done.
And every attachment made it heavier. A claim form, a policy document, a statement: each was a file someone had to open, understand and key in by hand before the request could move at all. More email meant more people, and more people meant more of the day spent on triage instead of on the customer.
What changes when the machine reads for intent
Here is the shift, and it is smaller than it sounds. We put a model in front of the inbox that reads each email and its attachments the way a person would, works out what the message is about and how urgent it is, and sends it straight to the desk that should handle it, with the policy and history already attached. For the routine, well-understood requests it drafts the reply too, pulling the customer's details from the system, so an agent starts from a written answer to check rather than a blank page.
Notice what that is and is not. It is not "the AI answers your email." A person still sends every reply, and anything the model is unsure about, an ambiguous request or a sensitive complaint, goes to a human instead of out the door. That guardrail is not something bolted on afterwards; it is what makes the system safe to put in front of real customers. What the machine took over was the sorting. The queue stopped being ordered by arrival time and started being ordered by what actually needed attention first.
The sorting was the bottleneck, not the answer
The numbers followed from that one change. First responses that used to run as long as 48 hours came back in under 30 minutes, because the urgent messages surfaced immediately instead of waiting their turn behind the routine ones. Service costs fell by around 30%, and the team absorbed a growing pile of email without a new hire for every jump in volume. The people who used to live in the inbox went back to the work that needs a person.
If there is a lesson here that travels beyond email, it is this: a lot of "we need AI to handle the volume" is really "we need the volume to stop deciding our priorities for us." The reply an agent writes was rarely the bottleneck. The bottleneck was the twenty minutes before it, spent finding out which of a thousand messages deserved the next twenty minutes. That is the whole distance between a demo that sorts a tidy sample and a system that holds up on a real Tuesday.
That urgent claim still arrives every morning. The difference is that it no longer waits behind a password reset. It surfaces in the first minutes, with everything the agent needs already attached, and the person who wrote it gets an answer while it still matters.
Common questions
What is AI email triage?
A model reads each incoming email and its attachments, works out the intent and how urgent it is, and routes it to the right person, often with a draft reply prepared. It replaces the manual reading-and-forwarding step, not the human who answers.
Will it reply to customers on its own?
No. It prepares drafts for the routine requests and an agent reviews and sends every one. Anything ambiguous or sensitive is escalated to a person, which is what keeps it safe to run in front of real customers.
How is this different from inbox rules or filters?
Rules match on keywords and sender, so they miss anything phrased in a way you did not predict, and they cannot read an attachment. Reading for intent handles the message a customer actually wrote, including the claim form stapled to it.