Show and Tell: AI categorisation and distribution of shared mailbox email
In our latest Intelligent Automation team Show and Tell, Ian walked through something most teams will recognise straight away, the reality of managing a shared inbox. It’s not glamorous work, but it’s critical, and when it doesn’t work well it slows everything else down.
What we wanted to show wasn’t a concept or a future state. This is something practical we’ve been building and testing: a simple, repeatable way to use AI to help teams triage and route emails without adding more complexity.
Starting with a real problem
Shared inboxes tend to rely on people remembering to check them, interpreting emails consistently, and knowing who should pick something up. In busy services, that’s where things start to slip, messages sit unread, get picked up late, or bounce between people.
Rather than trying to fix that with more process or rigid rules, we’ve taken a different approach. We’re using AI to look at incoming emails and score how well they match a set of categories defined by the service.
Those categories, along with example emails and routing rules, are owned by the team themselves. They’re not buried in code. They’re managed in a simple SharePoint structure that can be updated as the service evolves.
The important bit, and something Ian was clear on in the session, is that the AI isn’t making decisions in isolation. It’s doing the heavy lifting in terms of interpretation, but the logic that decides where something goes is still controlled and visible. That gives us a better balance between flexibility and confidence in the outcome.
Designed to be used more than once
From a delivery point of view, this hasn’t been built as a one-off fix for a single inbox. The pattern is the thing we care about.
Once you’ve got the model in place, categories, examples, routing rules, it becomes something you can lift and apply elsewhere. That could be another inbox, another service, or a different type of classification problem altogether.
Most of the effort sits with the service defining what ‘good’ looks like, not with rebuilding the technology each time. That means we can move quicker, stand things up faster, and avoid creating lots of slightly different versions of the same solution.
We’ve also kept the underlying setup flexible. While this version uses Blue Prism and Foundry, the approach itself isn’t tied to that. It’s API-led, which gives us options depending on the use case.
What changes for teams
The outcome is fairly straightforward, but it makes a difference:
- Emails are picked up and sorted more consistently
- The shared inbox stops being a hidden bottleneck
- Less time is spent checking, chasing, and forwarding
- More time is spent actually dealing with the work
- There’s still enough visibility and control for teams to step in where needed
Over time, it also gives us better insight into what’s coming in, volumes, patterns, and where categorisation needs tightening up.
A practical approach to innovation
This is the kind of thing we’re trying to focus on as a team, not using AI for the sake of it, but applying it where it removes friction in day-to-day work.
The value comes through pretty quickly:
- Lower manual effort in high-volume inboxes
- Quicker responses, which reduces the risk of escalation
- Reuse of a common pattern, rather than solving the same problem multiple times
- Scalability, without needing large amounts of technical build each time
It’s a small change in one sense, but it’s the sort of pattern we can replicate across multiple services.
This is still early days, but it’s a good example of where we’re heading: practical, service-led use of AI that teams can understand, shape, and scale.