Almost every company has the mailbox that belongs to nobody and concerns everybody: office@, info@, accounting@. Orders land next to spam, complaints next to job applications, and somebody spends an hour every day sifting through it all and forwarding things. That hour is a good candidate for AI, for a simple reason: sorting and routing is exactly what language models do reliably. What that looks like in practice, where the limits are, and why we advise against auto-sending is what this post covers.

Why ordinary email rules are not enough here

Outlook and Gmail have always supported rules: if sender X, then folder Y. But the problem with a shared mailbox is not the sender, it is the content. The same customer sends an order today, a complaint tomorrow and a billing question next week. A rule that checks subject-line keywords fails on a subject like “Your message from March 12”.

A language model reads the content and understands the request, even when it is worded indirectly, written in broken language or spread across three topics. That is the difference between a rule and triage: the rule checks attributes, triage understands intent.

The volume is not taking care of itself either, quite the opposite: according to a Bitkom survey (2025), working people who use the internet on the job receive an average of 53 work emails per day, up from 26 in 2021. For 14 percent it is 100 or more. Whoever sorts this by hand sorts a little longer every year.

Average work emails per day (Germany)

202126 emails

202340 emails

202553 emails

Source: Bitkom surveys, 2021–2025

The flow: from incoming mail to a prepared case

A typical triage workflow runs in three stages. First, the category: order, inquiry, complaint, invoice, application, other. The categories come from your business, not from a catalog. Second, the routing: which person or team is responsible, and what priority does the case have? A complaint from a key account is not the same as a newsletter unsubscribe. Third, the enrichment: customer number from the CRM, open orders, previous correspondence.

The result is not black magic, it is a tidy mailbox: every email attached to the right place, with context, and the urgent cases on top. The hour of sifting shrinks to the cases that actually need attention.

Draft replies: useful, as long as a person hits send

For recurring requests, the workflow can attach a draft reply: opening hours, delivery status, standard terms, appointment confirmations. The draft has to pull from your real data, otherwise it is worthless. A delivery-status answer written without checking the inventory system is a guess, and guessed answers to customers are worse than none.

Sending still happens only after a human glance. The reason is sober arithmetic: the draft already saves eighty or ninety percent of the writing time. Auto-sending saves the remaining seconds and in exchange takes on the full risk of a wrong, inappropriate or tonally off reply in your company’s name. That trade is almost never worth it. For purely informational, low-risk replies you can revisit the question after months of good results, but it is no place to start.

Where the quality gets decided

From the projects we have delivered, the stumbling blocks are fairly easy to name:

Unclear categories: if your own team cannot consistently agree whether an email is an “inquiry” or an “order”, the model cannot either. Defining categories is a business task, not a technical one.
Multi-topic emails: “Thanks for the delivery, one item is missing, and please send me a quote for…” belongs in two processes. Good workflows split such cases or escalate them instead of losing half the email.
Attachments: often the actual request sits in the attached PDF, not the email body. A workflow that ignores attachments triages past the content.
Irony and undertones: the model does not always recognize “Well, that went great” as a complaint. Uncertain cases therefore must be allowed to be flagged as uncertain.

Measure instead of believing

Whether the triage is good enough cannot be settled by gut feeling. We recommend a simple procedure: before launch, take a few hundred real emails from the archive, have the team categorize them by hand, and then check how often the model reaches the same result. That number is the basis for deciding what may run automatically and what goes to review.

After launch, every correction should be logged: which category the model assigned, which one the person changed it to. These deviations show where category definitions are fuzzy or where a request type is more common than assumed. It is unglamorous work, but it separates a workflow that still runs after a year from one that gets quietly switched off after six weeks.

What a realistic first project covers

A sensible entry point is deliberately narrow: one mailbox, a handful of categories, routing to people, draft replies only for the two or three most common standard requests. A pilot like that is productive within a few weeks and shows on real emails whether the quality holds. Expanding is always possible: more mailboxes, ticket system integration, automatic data transfer into order processes.

What we advise against: trying to rebuild the entire communication flow including auto-sending from day one. Those projects have long ramp-ups, unclear ownership and a single big go-live that everything depends on. The narrow entry delivers the same insights at a fraction of the risk.