Why shared inboxes become a bottleneck
Shared inboxes become a bottleneck because every message is handled by hand, one at a time, in the order someone happens to open it. In a bank, insurer, energy retailer or council, a single mailbox can carry claims lodgements, supplier invoices, hardship requests, meter disputes and building consent documents, all mixed together.
The work behind each email is usually the same four steps. Someone reads it, works out what it is, keys the details into a core system such as a claims platform, an ERP or a consenting system, and then sends a reply. Most of that effort is reading and retyping, not judgement.
Adding people to the team moves the queue around but does not change its shape. Backlogs build after storms, price changes or end of month, and the messages that matter most (a vulnerable customer, a complaint that should be escalated, a statutory deadline) look like everything else until someone opens them.
What can be automated in a shared inbox
Most of the handling steps can be automated, with people kept for decisions and exceptions. The work breaks into six jobs that run on every message as it arrives.
Classify
Work out what the message is and how urgent it is: new claim, claim update, invoice, remittance query, complaint, consent application or noise. A message can carry more than one request, and good classification picks up each one.
Extract
Pull the details out of the email body and its attachments: policy or account number, invoice total and GST, ICP number, property address, dates. Attachments include PDFs, scanned forms and phone photos.
Route
Send the work to the right team or queue, using the classification, the extracted data and your own business rules.
Create the case
Open or update the record in the core system, link the email and attachments, and set the due date.
Acknowledge
Send a low-risk acknowledgement automatically, with a reference number and the expected response time.
Draft the reply
Prepare a substantive reply from the case data and your approved templates and policies, for a person to check and send.
The order matters. Classification and extraction feed everything else, so they deserve most of the design effort and most of the testing.
How RPA and AI agents work together
RPA and AI agents do different jobs, and a shared inbox needs both: agents read and decide, robots key and file. An AI agent is good at reading a messy email thread, deciding what the customer actually wants and pulling fields from an unfamiliar document. A software robot is good at logging into an older core system with no usable API and entering those fields the same way every time.
Agents for reading and deciding
Classifying intent, extracting from unstructured attachments, summarising a long chain, drafting a reply in line with policy, and flagging anything that looks like a complaint or hardship.
Robots for keying and filing
Creating cases, entering invoice lines, updating claim status, attaching documents and moving work between queues in systems that were built for people at keyboards.
Both main platforms support this pattern. UiPath brings its Document Understanding and Communications Mining capabilities together under UiPath IXP, alongside its robots for system work. In the Microsoft stack, Power Automate cloud flows can trigger on a shared mailbox, AI Builder extracts data from documents, desktop flows handle legacy screens, and Copilot Studio agent flows add AI actions and human approval steps. Microsoft publishes a reference architecture for AI document processing that follows the same email, extract, review and respond shape.
The right platform is usually the one you already license and support. More on each side: robotic process automation and AI agents.
Human review and confidence thresholds
People stay in the process wherever the system is unsure or the stakes are high, and confidence thresholds decide which is which. Every classification and every extracted field comes with a confidence score. You set a threshold per field and per message type, and anything below it goes to a person in a validation queue with the source document beside the extracted values.
Thresholds should follow risk, not convenience. A supplier name on an invoice from a known vendor can pass at a lower threshold than a bank account number, a claim value or a payment amount. Some fields should always be checked by a person, whatever the score.
- Automatic: acknowledgements, filing, routing and case creation where confidence is high and nothing is paid or promised.
- Review before action: extracted values below threshold, new suppliers, changed bank details, anything over a value limit.
- Always a person: complaints, hardship and vulnerability indicators, claim decisions, and any substantive reply to a customer.
Whatever goes out under your organisation's name, your organisation owns. Drafted replies should be read and sent by a person until you have evidence that a category is safe to automate.
Audit trail, privacy and data handling
Every automated decision should be logged so that you can show what the system did, why, and who checked it. For each message, record the classification and its confidence, the fields extracted, the routing rule applied, the case created, and the name of any person who validated or changed a value. Your risk, audit and complaints teams will ask for this, and it is also how you find and fix the cause of a misfiled message.
The Privacy Act 2020 information privacy principles apply to the personal information in these mailboxes. In practice that means:
- Limit scope. The automation reads the nominated shared mailboxes only, not staff mailboxes.
- Keep security and retention in step. Extracted data, model inputs and logs follow the same access controls and retention schedule as the core system they feed.
- Know where data goes. Confirm the region your platform and AI services process data in, and check any disclosure outside New Zealand against principle 12.
- No training on your data. Confirm in the contract that customer content is not used to train vendor models.
- Be open. Update privacy statements and tell staff what is being read and why.
How to measure shared inbox automation
Measure against a baseline taken before anything changes, or you will not be able to show the result. Take at least four weeks of data from the mailbox and the core system, covering a busy period if you can.
- Volumes: messages per day by type, and how many need action versus noise.
- Handling time: minutes per message from open to case created, by type.
- Backlog age: the age of the oldest unactioned message and the share handled within your service level.
- Error rate: misrouted messages, keying errors found later, and duplicate cases.
- Straight-through rate: once live, the share of messages that need no human correction.
Report these weekly during the pilot. The straight-through rate tells you how much to trust the thresholds, and the error rate tells you whether to raise or lower them.
A pilot-first rollout
Start with one mailbox and two or three message types, prove it, then widen the scope. A pilot keeps the risk small and gives you real evidence for the business case.
Pick the pilot
Choose a mailbox with high volume, repeatable message types and a clear owner. Accounts payable is often a good start because invoices are structured and the outcome is easy to check.
Run in shadow mode
The automation reads live mail and records what it would have done, without acting. The team compares its decisions with their own and the thresholds are tuned.
Go live with review
Switch on case creation and acknowledgements, with every low-confidence item going to the validation queue.
Widen in steps
Add message types and mailboxes one at a time, each with its own baseline and shadow period.
Shared inbox automation usually sits within a wider business process automation programme. If you want to talk through a pilot, get in touch.
Questions we are asked
Can AI reply to customer emails automatically?
It can, but for most organisations it should only send low-risk acknowledgements at first. Substantive replies should be drafted by the system and read and sent by a person until evidence shows a category is safe to automate.
Do we need both RPA and AI for shared inbox automation?
Usually yes. AI reads and classifies messages and extracts data from attachments, while RPA keys that data into older core systems that have no usable API.
Which mailbox should we automate first?
Pick one with high volume, repeatable message types and a clear owner. Accounts payable is often a good first choice because invoices are structured and results are easy to check.
How does the Privacy Act 2020 affect inbox automation?
The information privacy principles apply to the personal information in the mailbox, including security, retention and disclosure outside New Zealand. Limit the automation to nominated mailboxes, keep logs under the same controls as the core system and tell people what is being read.