For the last six months or so I’ve been talking about the CRM we’re building at Luton. But recently I’ve started wondering whether CRM is actually the right way to describe it. Or, perhaps more accurately, whether it describes all of it.
When we first started talking about the platform, CRM was a useful shorthand for what we wanted to achieve. One place where we could build a better picture of our residents and the interactions they have with the council.
Now that we’ve built quite a bit of it, I think the reality is slightly more interesting, because most of what we’re building isn’t really customer relationship management. It’s casework management.
What is a case?
Take some of the things we’ve built already. Someone makes a complaint. Someone submits a Freedom of Information request. There’s a Subject Access Request. A councillor contacts us on behalf of a resident. A member of staff reports a data breach.
On the face of it, these are completely different processes, owned by different teams, with different rules, timescales and outcomes. But underneath, they have a surprising amount in common. Something has happened that requires a response from the council.
It needs to be recorded. Someone needs to own it. There might be documents, messages and notes associated with it. Other people might need to contribute. There may be a deadline or an escalation. Eventually something needs to happen and the case needs to be closed.
Those common case management capabilities are already emerging across the applications we’ve built.
That’s made me think differently about what the platform is.
The CRM bit happens around the person
The interesting part comes when those individual pieces of casework stop being isolated records. If they’re connected to the same resident, we can start to see something much more useful.
We can see that someone contacted us, why they contacted us, what happened and what the outcome was. That’s already part of the model we’ve been developing.
And perhaps that’s the CRM. A complaint is casework. A missed bin is casework. A Member enquiry is casework.
But to the resident, these aren’t interactions with a Complaints system, a Waste system and a Members’ Enquiries system. They’re interactions with Luton Council. That distinction matters.
Maybe we’re building both
So, I’ve started thinking about it slightly differently. Perhaps we’re building a casework management platform that creates a CRM view.
The casework layer is concerned with getting something done: receiving work, assigning it, progressing it, communicating about it and reaching an outcome. The CRM layer connects those interactions around the resident. And the platform is what allows the two to work together.
That also helps answer another question we’ve been wrestling with.
Does everything need to be in the CRM?
I don’t think it does. We aren’t trying to replace every specialist system used by the council.
There will be processes where a dedicated line-of-business system is absolutely the right place to manage the detailed work. Our emerging thinking is that those systems could instead leave enough of a “breadcrumb” in the CRM for someone to understand that an interaction happened and get to the operational record if they need it.
That feels much more achievable than trying to create one enormous system that does absolutely everything.
And it changes the question from: “Can we put this service in the CRM?” to: “Where should this work be managed, and what does the council need to know about it?” I think that’s a much more useful question.
Where General Enquiries fits
There’s another part of this that we’re starting to explore. Not every piece of work deserves its own application.
Councils have thousands of smaller enquiries, requests and bits of casework. Some teams have specialist systems to manage them. Others still rely heavily on email folders, spreadsheets and local processes. Building a bespoke application for every one of those things wouldn’t make sense.
That’s where our thinking around General Enquiries comes in: a lighter way of creating trackable cases for relatively straightforward work, without having to build another complete application every time.
At the other end of the spectrum, some services genuinely need something more sophisticated because of their integrations, workflows, payments, statutory requirements or the experience they need to provide.
So we’re starting to see different patterns emerge rather than trying to force every service into the same solution.
That thinking is shaping our current sprint. In Sprint 13, work on Waste continues at pace. We’re also iterating our pipeline and project management app, while starting to run some proofs of concept around General Enquiries to test how that lighter-touch approach could work in practice.
The distinction matters more than the label
I suspect there will be people reading this who know far more about CRM than I do and have strong views about exactly where CRM ends and case management begins. That’s fine. I’m increasingly less interested in what we call it.
What matters is whether we can manage work properly and give staff enough context to understand the person behind it.
If somebody contacts us, can we understand why? Can we see what’s already happening? Can we get their enquiry to the right place?
Can the person doing the work see what they need to do? Can we keep the resident informed? And can we understand the outcome?
If we can do those things consistently, then whether we call the thing underneath it a CRM, case management system or digital platform becomes a lot less important.
Case management is about managing the work. CRM is about understanding the person behind it. What we’re building needs to do both.
Like
Love
Haha
