AI Email Management for Shared Business Inboxes

Every AI email tool is built for the wrong inbox

Search for AI email management and you get a listicle of assistants for your personal mail: summarise this thread, draft that reply, unsubscribe, sort, achieve inbox zero. They are good products. Gmail with Gemini and Outlook with Copilot are the sensible first stop and they cost you nothing extra.

None of them solve the inbox that is actually hurting your business.

That one is info@, pedidos@, orders@, support@. It has no single owner. Half the company can see it and nobody is responsible for it. Orders, invoices, complaints, supplier confirmations and cold outreach arrive interleaved, and someone spends the first ninety minutes of every day sorting them into human piles. Email is named a top time drainer by around half of small business owners, and the shared inbox is where most of that time goes.

A personal assistant tool helps a person read faster. A shared inbox does not need to be read faster. It needs to stop depending on someone reading it at all.

What actually goes wrong in a shared inbox

Name the failure modes before choosing tooling, because the personal-inbox tools address none of them.

• The double reply. Two people answer the same customer differently, twenty minutes apart. The customer now believes whichever answer was worse.
• The silent drop. A message gets opened, judged to be someone else's, and closed. It is now marked read and invisible forever. Nobody has done anything wrong, and the customer waits four days.
• The holiday cliff. One person knows that mails from that supplier go to production and that this customer always means the Barcelona site. In August, that knowledge is not in the building.
• The unanswerable question. "Did anyone reply to Gonzalez about the short delivery?" requires searching an inbox, a WhatsApp thread and someone's memory.
• Retyping. An order arrives as text in an email. Someone reads it and types it into the ERP. This is data entry dressed as customer service, and it is where the transcription errors come from.

Every one of these is a queue problem, not a reading problem. Ownership, state and deadline are missing, and no amount of summarising fixes that.

The pattern: triage, extract, act, escalate

1. Triage. Every incoming mail gets classified against a category set derived from your own history: order intake, order status, invoice, delivery query, complaint, supplier notice, recruitment, spam. The agent sees how similar mails were handled before, which is why accuracy on your inbox beats accuracy on a generic model's idea of business email. Building that category set is the step most projects skip and most projects die on; the method is in email triage automation.
2. Extract. The message becomes structured data with a link back to the original. Order mails flow into the order pipeline, supplier invoices into invoice processing. The email stops being the record and becomes the source.
3. Act. Routine categories get handled end to end: order confirmed against real stock, tracking link sent, invoice copy resent, delivery date answered from the ERP rather than from memory. Anything involving judgment is drafted, not sent.
4. Escalate. Complaints, unusual requests and low-confidence classifications go to a named person with a summary, the customer history and a suggested reply attached, so handling takes one minute instead of ten.

The escalation step is the one that decides whether this works. A system that routes an angry email to a person with full context is more valuable than one that answers ninety percent of mail perfectly and dumps the rest back into the pile.

Answer from systems, not from the thread

The difference between a demo and something a business runs on is where the answer comes from.

"When is my order arriving?" answered from the email thread is a guess dressed in confident language. Answered properly, the agent looks up the order in the ERP, checks the dispatch record, sees the carrier tracking, and replies with a date and a link. If your ERP predates the concept of an API, that lookup is still usually possible; the routes are in connecting a legacy ERP, and where a supplier portal offers nothing at all, an agent can read the screen the way a person would.

This is the line between an email assistant and email operations. Assistants rephrase what is in front of them. Operations look things up.

Which categories to automate, in order

Category	Volume	Risk if wrong	Treatment
Order status / ETA	High	Low, verifiable	Auto-send once ERP lookup is proven
Document resend (invoice, delivery note)	Medium	Very low	Auto-send early
Order intake	High	Medium	Extract and confirm, human approves exceptions
Supplier confirmations	Medium	Low	File and update, notify on mismatch
Delivery problems / shortages	Medium	High	Draft with full history, human sends
Pricing, credit, terms	Low	High	Draft-first, permanently
Complaints	Low	Very high	Never auto-send, route with summary

Read that as a rollout order rather than a policy. The first category is chosen for boringness, not for volume of glory.

Draft-first is how you get adoption

Nobody should trust a system that sends customer email on day one, and a team told to trust it will quietly keep working the old way in parallel.

Run every category in draft mode first. The agent prepares the reply, a human approves with one click. Two things happen within a few weeks: the team sees the drafts are usually better than what they would have typed under time pressure, and you accumulate evidence about which categories are safe. Then flip categories to auto-send one at a time, starting with the dullest.

Keep permanent guardrails regardless of how good it gets:

• Never auto-reply into anger. Sentiment routing to a human is not a tuning parameter.
• Money never moves without a person. Quotes, credit notes, payment terms, discounts. Draft-first forever, the standard human-in-the-loop boundary.
• Log everything. Which mail, which classification, which action, which human approved, which system was queried. The audit trail is what makes management comfortable and what lets you monitor whether the agent is still behaving six months in.
• Cap the blast radius. A classification bug should be able to mis-file a hundred emails, never send a hundred wrong replies.

Measure the misses, not the handles

The tempting metric is emails handled automatically. It is the wrong one; it goes up when the system gets more aggressive, which is the failure direction.

Track four instead:

1. Time to first response, by category. The number customers actually experience.
2. Unanswered after 24 hours. The silent-drop counter. This is the number that should approach zero and the reason to do any of this.
3. Human edit rate on drafts. If it is falling in a category, that category is a candidate for auto-send. If it rises suddenly, something upstream changed.
4. Retyping eliminated. Order lines and invoice fields that reached the ERP without a person typing them.

Baseline all four for two weeks before changing anything, or the payback conversation becomes opinion. The method is in calculating automation ROI.

Where to start on Monday

Export a month of your shared inbox and count the categories by hand. Almost everyone is surprised: one or two categories are usually 60 to 70 percent of volume, and they are nearly always the dull, verifiable ones. Automate the largest of those, draft-first, and leave everything else exactly as it is.

One category done well is what funds the rest, and it is the only version of this project that finishes.

Oido runs shared inboxes end to end: classification on your own history, ERP and order lookups behind every answer, drafts for the judgment calls, and escalation with context to the right person. See email management in practice, the pattern applied to service businesses and corporate operations, or send us a month of your inbox and we will tell you what is automatable.