For the last few months, I’ve been working with a small team on something called LocalGovMail.
It started with a fairly mundane problem. Councils receive a huge amount of correspondence through shared mailboxes, and a surprising amount of staff time goes into dealing with it before the actual service work starts.
Someone has to read each email, work out what it is about, find the relevant information, decide where it needs to go and often write a fairly standard response. None of that is particularly difficult in isolation, but at volume it becomes a significant administrative task. In my recent experience anywhere between 4 hours a day to 4 people full time.
We wanted to see how much of that work could sensibly be reduced.
What we have built
LocalGovMail is an open-source application designed specifically around council correspondence.
It connects to a shared mailbox and helps with the work that normally happens when an email first arrives. It can suggest what the email is about, extract useful information, identify something that appears to be missing, highlight correspondence that may need attention and prepare a draft response or next action.
The officer remains in control. They can accept a suggestion, change it or ignore it.
Over time, a council may decide that some predictable, low-risk tasks can go further. I don’t think that needs to be the starting point. There is useful work LocalGovMail can do simply by reducing the amount of reading, sorting and repetitive drafting that staff have to do themselves.
It isn’t another CRM
One of the decisions we made early on was not to turn LocalGovMail into another case-management system.
Councils already have CRMs, line-of-business systems, Microsoft 365 and other platforms that manage the actual service process. There is little benefit in reproducing those functions somewhere else.
LocalGovMail deals with the correspondence around them.
If an email clearly relates to an existing case, the case should still be managed in the CRM. If it belongs in a specialist service system, that system should continue to own the process. LocalGovMail can help understand the incoming message and prepare the next step.
That distinction has become quite important as we have developed it. Adding a new tool should remove work rather than create another place that officers need to keep updated.
Building it is only half the job
We now have a working application. The question we are spending more time on is how another council actually picks it up and uses it.
Publishing something as open source is relatively easy. Making it straightforward for a council to deploy, configure, assure and support is harder.
There are practical questions around connecting mailboxes, hosting, security, permissions and integration. There are also service questions. Someone needs to understand what comes into a mailbox, what information the service needs and what should happen with different types of correspondence.
AI governance adds another layer. Councils quite reasonably want to know where their information is going, how decisions are recorded, where people remain involved and what happens when the system gets something wrong.
LocalGovMail has therefore been designed to run within a council-controlled Azure environment, rather than as another external service holding council correspondence. It is also open source, so the code and the way it works are available to councils rather than hidden behind a supplier platform.
None of that removes the need for local assurance, but it should make that assurance easier.
Making the first step smaller
The approach we are developing is deliberately modest.
Rather than trying to introduce LocalGovMail across an organisation, start with one mailbox where there is enough volume or repetitive work to make it worthwhile.
Understand what arrives in it. Agree the main categories and service rules with the people who run the service. Let staff review what LocalGovMail suggests and see how well it performs against real correspondence.
Then measure it.
Does it reduce handling time? Are the suggestions useful? Where does it make mistakes? How often do staff need to correct it? Does it actually make the service easier to run?
Those answers are much more useful than a theoretical calculation of how much time AI ought to save.
They also give a council a sensible basis for deciding what happens next. Some services may want to introduce more automation. Others may find that assisted triage and drafting are enough.
What we are working on now
Our immediate focus is making that first implementation as straightforward as we can.
That includes improving the setup process, making service configuration easier, providing sensible documentation and working out what support councils will need both during implementation and afterwards.
There is a balance to get right here. We don’t want LocalGovMail to become a traditional software product with another substantial licence cost attached to every mailbox or user. Equally, open-source software still needs maintaining and councils need to know where they can get help when something goes wrong.
We are working through what a practical model for that looks like.
The next stage is to use LocalGovMail in a live council environment and then work with a small number of other councils. That should tell us much more about what needs to be standardised, what will always need local configuration and what we need to do to make onboarding considerably easier.
Coming soon
LocalGovMail isn’t ready for broad rollout yet, but it is getting closer.
Over the next few months we should have a much better picture of what a repeatable council implementation looks like and the support needed around it.
There is more information about what we are building at localgovmail.org.
And if you work in a council with a shared mailbox that consumes far more staff time than seems reasonable, I’d be interested to hear about it.