Don’t Digitise The Council You Already Have

Local Government Reorganisation was supposed to be the moment.

Then, this week, a chunk of it stopped moving. Decisions for four areas withdrawn. Fourteen more paused pending review. Some authorities pressing on regardless. A programme that looked inevitable eighteen months ago now looks, at best, uneven.

If your transformation plan was quietly leaning on “we’ll sort this properly once LGR happens,” that plan just got a lot less certain. And I think that’s worth sitting with, because it exposes something that should have been obvious all along.

Take the reorganisation away, or delay it, or make it uncertain, and the underlying question doesn’t go anywhere. Residents still navigate fragmented services. Officers still re-key the same information into three systems. Demand still arrives faster than capacity. None of that was caused by the two-tier structure, and none of it gets fixed by waiting to see what the structure becomes.

So here’s the risk I actually want to flag: it would be very easy, right now, for councils to read “LGR paused” as “transformation paused.” Structural uncertainty becomes the excuse to sit on your hands for another year. That would be the wrong lesson to take from this week.

The right question was never:

It’s the one that doesn’t depend on any government timetable at all:

That question is available to every council, right now, reorganising or not, paused or proceeding. It always was.

I say this to every team I work with: people first, then process, then technology.

Most transformation programmes get this backwards — and reorganisation, when it’s happening, makes the backwards version tempting. Which system survives the merger? Which platform do we standardise on? Where could AI help? Those are migration questions. They’re not transformation questions, and answering them well doesn’t automatically produce a better service — it just produces a more efficiently delivered version of whatever you already had.

The starting point should be simpler, and it’s the same starting point whether you’re merging four authorities into one or just running the council you’ve already got: what is the person actually trying to achieve?

Someone struggling financially may need help with Council Tax, benefits, housing costs or discretionary funding. To them, that’s one problem. To the organisation, it’s four service areas, four forms, and the same information typed in four times.

Internally, the same principle holds. What does the officer need to get done? What’s slowing them down? Where are they waiting on another team, or re-keying data because two systems were never connected?

None of that requires reorganisation to fix. It requires deciding to fix it.

Putting a digital front end on an inefficient process doesn’t make the process efficient. It makes the inefficiency digital, and now it’s faster and better documented.

For years, “digital transformation” has largely meant converting paper forms into web forms and moving transactions onto portals. Useful, but not the same achievement as redesign. If a resident still has to know which department owns their issue, still provides the same information three times, and still chases the council for updates — nothing has actually changed for them. It just looks tidier.

The better question, with or without a reorganisation programme attached to it:

Remove the steps that don’t earn their place. Challenge the approvals that add friction but not value. Connect the teams where the resident’s journey crosses an organisational boundary that only exists on an org chart, not in their experience. Decide what should happen automatically and where human judgement genuinely matters.

Only once that’s sorted should technology enter the conversation. This is true inside a merged unitary authority. It’s equally true inside a district council that’s staying exactly as it is for the foreseeable future, which, after this week, is a growing number of them.

The AI question in this sector too often starts as: where can we deploy this?

Wrong question, always, but especially now. The right one: where is there friction, and what’s the simplest way to remove it?

Sometimes AI is the answer — classifying requests, pulling information out of documents, supporting officers with summaries, spotting patterns in demand. Sometimes it’s plain automation. Sometimes two systems just need to exchange data properly. Sometimes the form needs rewriting. Sometimes the process should disappear.

None of that needs to wait for a reorganisation decision, a merger date, or a review outcome. A council that’s staying independent has exactly as much reason to fix a broken process as one that’s about to be absorbed into a new unitary authority. Arguably more, there’s no migration project coming along in eighteen months to force the conversation, so if you don’t start it yourself, nobody will.

This matters more, not less, now that timelines are uncertain. Waiting for structural clarity before investing in service design just means residents wait longer for something that was never contingent on the structure in the first place.

Fragmented services don’t just frustrate residents; they blind the organisation to its own demand.

Council Tax understands Council Tax. Housing understands housing. Customer services understands whatever arrives through customer services. Each team sees a fragment. Nobody sees the whole.

A more joined-up approach, inside one council, or across several creates the chance to understand:

That’s worth far more than recording that a transaction happened. It’s what lets a council understand why people are contacting it, where demand is rising, which interventions actually work, and where poor service design is manufacturing avoidable contact. Over time, that’s the foundation for moving from reactive to proactive service, and it’s built by fixing services, not by redrawing boundaries.

Whether “go-live” means a new unitary authority’s platform or a smaller upgrade in a council that isn’t reorganising at all, the trap is the same: treating implementation as success.

A system can go live on time and still change nothing. Staff don’t trust it. Old workarounds quietly return. Someone builds a shadow spreadsheet. Residents keep abandoning the same journeys because the underlying problem was never actually solved.

Transformation isn’t:

Design → Build → Go Live

It’s:

Discover → Design → Configure → Implement → Adopt → Measure → Optimise

The second half matters as much as the first, and it’s not a one-off event tied to a reorganisation milestone, it’s ongoing, indefinitely, for as long as the service exists. Are staff using the new process? Has manual work actually dropped? Are residents completing journeys, not just starting them? Has avoidable contact fallen?

Measure the change, not the completion certificate.

Every technology decision and process redesign should be judged by what got better, not by whether a project plan turned green, and not by whether it happened to coincide with a merger.

Did residents provide less information? Did they get an answer sooner? Did staff spend less time re-keying data? Did avoidable demand fall? Did the cost of delivering the service actually go down?

“The system is live” is an output. “The resident no longer has to contact three departments” is an outcome. Those aren’t the same thing, and no government review decides which one you’re aiming for.

Reorganisation, when it happens, gives councils permission to ask uncomfortable questions they’d normally never get around to: why does this service sit in this team, why do we ask for this information twice, why are these systems separate, why does this approval exist at all.

Those are good questions. But permission to ask them was never actually withheld from councils that aren’t reorganising. It just felt that way, because LGR gave everyone a deadline and a mandate.

That deadline is now, for a lot of authorities, gone or delayed. The mandate doesn’t have to disappear with it.

Understand what people need. Design the simplest process around that need. Use technology where it genuinely improves the process. Capture the data that shows what’s actually happening. Measure whether the result is better. Keep improving it.

That sequence doesn’t require a merger, a new unitary authority, or a ministerial timetable. It requires deciding to run it; this year, next year, reorganised or not.

Because the real risk was never that LGR gets paused. It’s that councils use the pause as permission to pause everything else too, and end up, a few years from now, having changed nothing at all, with or without a new logo above the door.

Don’t digitise the council you already have.

Design the council you’d build today –  whatever happens to the one you’re in tomorrow.