Mailbox automation

What is mailbox automation?

Mailbox automation is software reading a shared inbox and doing something with what arrives before, or instead of, a person. The mailbox is one of the four every Belgian SME has: info@, orders@, support@ or facturen@.

It is not one product. At the bottom end it is a rule that moves supplier confirmations into a folder. At the top end it is an assistant that reads a mail, looks up an order and sends the answer. The question is not whether to automate the mailbox, but how far up that range a category of mail belongs.

What makes the shared inbox worth the trouble is also what makes it hard: nobody designed it. Orders, questions, complaints, purchase invoices and a colleague in copy land in the same list, in whatever shape the sender felt like. The mailbox became the intake system by accident. The ambient agent entry uses a shared inbox as one of its trigger examples.

What lands in a shared inbox, and why it is hard

A mail is not a case. A case is a thread of six messages over four days. Treat every message as a fresh item and one question becomes five tickets.

The attachment carries the content. "See attached" plus a PDF is a complete order to a human and an empty message to anything reading the body.

Forwarded chains bury the question. Two new lines on top of four old replies, and extraction that grabs the first order number it sees grabs one that was already handled.

Two or three languages, sometimes in one message. A model you only checked on Dutch examples will quietly do worse on the French quarter of your volume.

The ladder, from a rule to an autonomous reply

Five rungs, in order of how hard they are to get right. Each is worth building on its own, and most companies never need the top one.

  1. Rules on sender and subject. No model involved. Newsletters, alerts and system-generated supplier confirmations go to a folder, because their sender address never changes.

  2. Classification and routing. A model puts one label from a fixed list on each mail and moves it to the right folder or colleague. This is text classification applied to mail, and the label set matters more than the model does.

  3. Extraction into a system. Order number, customer and requested date out of the body and the attachment, into the ERP. The cost of being wrong starts here, because a mistake now lands in a system other people trust.

  4. A drafted reply a person sends. The assistant writes the answer and leaves it in the mailbox for somebody to send or edit. For most SMEs this is the best return for the risk taken.

  5. An autonomous reply for one narrow category. Nobody looks before it goes out. Not for complaints, not for anything with a price in it, and not before a few thousand drafts you were happy with.

Which category first? The one with volume, repetition, and an answer a machine can look up, which in practice means order status and delivery dates. The answer sits in a system, you can check it, and being wrong is embarrassing rather than expensive. Complaints score the opposite on all three.

How it is wired, and what breaks in the first month

Microsoft's Office 365 Outlook connector as the example, because most Belgian SMEs already own it.

A shared mailbox, not somebody's personal one. The connector has a trigger for it, "When a new email arrives in a shared mailbox (V2)", and the account making the connection needs full access to that mailbox. Permission to send as the mailbox is not enough, and that is the most common reason a trigger never fires.

The trigger polls, and watches one folder. It fires on the received date of a message, not on the moment it was moved, so dropping old mail into the watched folder starts nothing reliably. An Outlook rule that files mail before the flow sees it makes the automation look dead.

Attachments need a deliberate choice. Both attachment options default to off, so the content arrives as null and a later step that writes the file returns a 400. Turn them on and Microsoft warns about timeouts when a batch of mails with attachments lands at once.

Deduplication and threading. Your own reply lands in the same mailbox and starts the flow again, so add a trigger condition that skips your own sending address. Key the case on the conversation identifier, or one thread becomes six cases.

Idempotency. Power Automate and Logic Apps are at-least-once by design, and Microsoft's own guidance is to build flows that are idempotent, for instance by checking whether a record exists before creating it. Write the message identifier into the record and refuse a second record for the same identifier. With Safe Attachments in dynamic delivery the trigger can fire twice for one mail anyway, the first time with an empty attachment array.

What happens to the mail afterwards. Move it to a Processed folder, label it, or leave it. Moving is the honest option, because then what is left in the inbox is still the work list.

The failures you should expect

A loop between two automated mailboxes. RFC 3834 has said how to avoid this since 2004: an automatic response should not be issued to any message carrying an Auto-Submitted header with a value other than no, and never to a null return path. Outlook stamps its own automatic replies as auto-generated and Gmail as auto-replied, so stamp yours too and read the header on the way in.

Out of office replies. Exchange sends one per sender and remembers who it answered, in a history holding 10,000 entries. A mailbox rule of the "have server reply using a specific message" kind has no such memory and answers every time, which pointed at another auto-responder is the classic mail storm.

An attachment nobody read. The classifier scored two lines of body text, the order sat in the PDF, and the mail was filed as a question.

A customer waiting for a human. The answer missed the point and the thread looks handled to everybody except the customer. The human handoff entry covers what has to travel with a conversation when a person takes over.

Order status mails, worked end to end

Take a technical wholesaler with three people on the inside desk. A month of orders@ holds about 900 messages: 340 questions about the status or delivery date of an existing order, 180 new orders, 120 automatic supplier confirmations, 90 invoice and payment questions, 60 complaints and returns, and 110 newsletters, internal copies and spam.

The 340 are the target. Rung one takes the supplier confirmations out on sender address alone. Rung two labels the rest, and there you learn that only about seven in ten status questions carry an order number anywhere in the mail; the others name an article and a delivery week and expect you to know who they are.

Rung four handles what is left. With a usable reference the assistant looks the order up, checks whether it shipped and leaves a draft with the tracking link, say 240 of the 340. The other 100 go to a person untouched: no order found, a dispute, or a complaint in the same mail.

Then the arithmetic. Answering a status mail by hand takes about four minutes, most of it switching to the ERP and back; reading and sending a prepared draft takes around 40 seconds. On 240 mails that is roughly 800 minutes, a bit over 13 hours a month, with the desk still reading every reply. Two days of somebody's month, not a headcount.

A mail rule versus a model that reads the mail

Both can route a status question to the right folder. They differ on one dimension that decides your maintenance: what happens when the wording changes.

A rule matches literally, on "order status" in the subject or a sender in a list. The customer writing "waar blijft mijn bestelling?" does not match, so nothing happens, and a trigger condition that is not met produces no run at all, so there is nothing in the history to look at either. The rule does not fail loudly, it fails invisibly, and you hear about it from the customer.

A model reads the sentence, so new phrasing, another language or a typo still gets routed. The price is a different kind of wrongness: it can be confidently wrong on a mail no rule would have touched, and its behaviour shifts when the model version changes underneath you.

Use rules for what is literally stable, such as a system sender address, and a model for anything a human typed. Rules are cheap, auditable and brittle. Models are flexible, harder to explain, and need a sample of real mails checked by hand every month.

An assistant that reads the mail and can also send

An inbox is the one system where a stranger can put text in front of your software for free, without permission, as often as they like. That makes it the textbook entry point for prompt injection, and a mail assistant the textbook lethal trifecta: it reads private data, it reads untrusted content, and once it can send mail or fetch a link it has a way out.

  • Do not give send rights early. Drafting is the same product without the third leg, and a month of drafts tells you what an autonomous version would have done at no risk.

  • Constrain the recipient, not the content. If the assistant does send, the recipient comes from the original message and not from anything the model wrote. Copilot Studio can constrain a tool's input values with Power Fx, for example limiting recipients to one domain.

  • Attachments and signatures are content too. Instructions hidden in a PDF or in white text under a mail arrive through the same door as the question.

  • Know whose account it runs under. Copilot Studio event triggers can only authenticate with the agent maker's credentials, and Microsoft warns before publishing that users may reach data through that authorisation.

What to measure, and where a small company starts

  1. Share auto-handled. Incoming mail closed without a person opening it. On its own this lies, because it improves every time the automation answers something it should have passed on.

  2. Time to first reply, on the whole mailbox from arrival. If the automated share got faster and the average did not move, the automation took the easy mails and left the queue as it was.

  3. Reopen rate. Threads marked handled that come back within the week. This is what keeps the first number honest.

  4. Mails a person still touches, per week, in absolute numbers. Percentages hide volume growth, and this is the only one that converts to hours.

Where to start, with one shared mailbox and nobody whose job this is: export a month of mail and label 200 of them by hand before building anything. That afternoon gives you the real category mix and the label set you need at rung two. Then take one category, one mailbox and one folder for processed mail, put a name against it, and run it in draft mode for four weeks with somebody reading every draft. Promote to sending only what that person stopped editing.

Last Updated: September 4, 2026 Back to Dictionary
Keywords
mailbox automation shared mailbox email automation text classification human handoff ambient agent power automate trigger prompt injection case management approval workflow automation ai