Top Tips for Planners Procuring Back Office Systems in the Modern World
Futureproofing Your Planning Back Office: What LPAs Are Quietly Asking Me
Futureproofing Your Planning Back Office:
What LPAs Are Quietly Asking Me
By Peter Kemp · Processustech · June 2026
Over the past year, I've had more quiet conversations with planning officers and heads of digital than I can count. Different councils, different sizes, different software stacks — but almost always the same question: "How do we not get this wrong?" |
This blog is for you. If you're currently in or about to enter a procurement process for a back office planning system, there are four things I want you to genuinely think hard about before you finalise your requirements. Consider this the conversation we'd have over a coffee before you submit your OJEU notice.
None of this is theoretical. It comes directly from research across contracts currently in force across England, and from the experiences of authorities who've already been through it — including a few who'd cheerfully tell you they wish they'd known this sooner.
01 — LOCAL GOVERNMENT REVIEW
The Local Government Review Problem
Let's start with the elephant in the room — the one that procurement teams are only just waking up to. Local government reorganisation isn't a theoretical risk anymore. It is happening, right now, at serious pace.
The 2024 Labour government announced in December 2024 that councils in two-tier areas of England would be reorganised into single-tier unitary authorities. In February 2025, councils across 21 areas were formally invited to submit proposals for unitarisation. Over 70 plans have now been submitted, and the government will be deciding between them during 2026.
What does that mean for your five-year back office contract? Potentially everything.
21 two-tier areas invited to submit reorganisation proposals | 70+ unitary proposals submitted to government for consideration | 2027–28 expected vesting dates for most new unitary authorities |
If your council is reorganised partway through a major system implementation, you may find yourself locked into a contract with a lame duck arrangement , a system procured by an authority that no longer exists, for functions now redistributed across a new unitary. The successor body may have different inherited infrastructure. Your carefully-negotiated contract may become a liability, not an asset.
The good news? Some authorities have already quietly started to address this. In my research of contracts currently in place with back office system providers across England, a number of local authorities have included explicit exit provisions should they become subject to local government reorganisation. It's not universal, not by a long stretch, but it's a template worth following.
✓ PRACTICAL TIP Try to include a Local Government Reorganisation exit clause. This should allow the authority to terminate or renegotiate the contract without penalty in the event of a formal LGR announcement that materially affects its functions. Work with your legal team to define the trigger point carefully announcement of a statutory order, for example, rather than mere political speculation. You might also consider provisions around data portability and transition support, so that if the worst happens, you can take your data and your institutional knowledge with you cleanly. |
02 — CROSS-SERVICE COMPLEXITY
Planning Doesn't Sit on Its Own — and Neither Should Your Procurement
Here's something that surprises people: in over 95% of the authorities we surveyed, the back office planning system wasn't just a planning system. It was shared with other teams building control, environmental health, licensing, land charges. Sometimes highways. Sometimes housing.
This is critical, and it changes everything about how you should approach the procurement. You are not just buying a planning tool. You are buying a platform that cuts across your regulatory functions, and any innovation or change you introduce needs to work across all of those service areas simultaneously.
Think about what that means in practice. A change to data standards in planning driven by, say, the Open Digital Planning programme or MHCLG's evolving requirements doesn't stay in the planning service. It cascades. If your system isn't built to absorb cross-service regulatory change gracefully, you will find yourself managing a wave of manual workarounds and interdepartmental headaches that nobody budgeted for.
"When planning catches a cold, building control sneezes. Make sure whoever you're buying from understands the whole body, not just the planning limb." — PARAPHRASING A HEADS-OF-SERVICE CONVERSATION, 2025 |
Your procurement documentation needs to reflect this explicitly. That means involving heads of service from building control, licensing, and environmental health in the requirements-gathering phase not as an afterthought, but as co-authors of your specification. Their workflows, their reporting requirements, and their regulatory change exposure all need to be factored in before you go to market.
It also means evaluating suppliers on their track record across the full suite of regulatory services, not just on their planning module demo. Ask them: how have you managed cross-service regulatory change for other authorities? Give me three examples. See what they say.
03 — RESOURCING
Resource: You Get Out What You Put In
Right, I'm going to channel my inner Enid Blyton for a moment. You may recall Daryl’s father before she headed off to Malory Towers, in so many words: you will get a lot out of this school if you put a lot in. It's the kind of advice that sounds deceptively simple and turns out to be absolutely true.
I cannot tell you how many implementations I've seen struggle or outright fail not because the software was wrong, but because the authority went into it under-resourced. Procurement teams underestimate, repeatedly, what it actually takes to deliver a programme like this.
Your supplier will project manage their side of the implementation. They are very good at that. They will have a project manager, a technical lead, a customer success manager. What they cannot do, and should not be expected to do, is project manage your organisation. And your organisation, for a programme like this, typically means 400 or more officers whose workflows, data, and day-to-day practices are being changed.
The resourcing trap to avoid: Don't assume your supplier's project manager is your project manager. They aren't. They're managing the supplier's deliverables. You need your own dedicated internal programme resource — ideally a Senior Responsible Owner with teeth, a business change lead, and a technical lead who can translate between your IT team and the supplier. These need to be in post before you sign the contract, not recruited on month three. |
I'd also encourage you to think seriously about what 'business as usual' looks like during the transition. Planning services are under pressure. Across England, authorities received 327,000 planning applications in the year to September 2025 and processed over 303,000 decisions in the same period. Your team will be doing all of this while simultaneously implementing a new system. That's not a reason to delay — it's a reason to resource properly.
Build the cost of proper resourcing into your business case. It's not optional. It's the difference between a programme that delivers and one that becomes an embarrassing audit finding.
04 — OPEN APIS
Open APIs: Yes, It's the Phrase of the Year. It's Also the Most Important Thing on This List.
I know. If I hear 'open APIs' one more time in a digital planning conference, I might actually well, I'll be professional about it. The term has been somewhat diluted by overuse. But here's the thing: the concept behind it hasn't lost any of its importance. Quite the opposite.
Almost every barrier I have encountered and helped authorities navigate in delivering genuine digital transformation in the planning space comes back to the same root cause. We couldn't link the data. We couldn't get out what we'd put in. We couldn't let a third-party tool talk to the system we'd bought from a supplier who liked their garden wall.
The Open Digital Planning programme, sponsored by MHCLG, is already demonstrating what's possible when systems are built to connect — with BOPS, PlanX, and the Digital Planning Register designed as interoperable components of a wider ecosystem. That's the direction of travel. If your new system can't participate in that ecosystem, you are buying yourself out of the future.
Open APIs are not nice to have. They are not a technical footnote. They belong — explicitly and with real teeth — in your procurement documentation, your evaluation criteria, and your contract.
What Should Your APIs Actually Do?
Here are some concrete examples of what open, well-documented APIs unlock in a modern planning back office environment:
• Planning Register → GIS Integration Push live application data to your mapping layers automatically. Officers, members, and the public see accurate, real-time application boundaries and status on your local map without manual exports or re-keying.
• Case Management → Consultation Platform Trigger statutory consultations automatically when an application reaches a defined stage. Responses feed back into the case file without a human in the middle. Saves hours per application and reduces errors.
• Planning Conditions → Compliance Monitoring Conditions attached to permissions can be pushed to a compliance management tool, allowing your enforcement team to track discharge and flag overdue pre-commencement conditions proactively.
• CIL / S106 → Finance Systems Obligation triggers and payment milestones feed directly into your finance team's ledger. No more spreadsheets. No more 'we think about £2.3m is outstanding but we're not entirely sure.'
• Back Office → Performance Dashboard Real-time KPI data — determination rates, speed of processing, application on-hand numbers — surfaced in a live dashboard for leadership without manual data pulls every Monday morning.
• AI Tools → Application Data Emerging AI-assisted validation tools, officer support systems, and summarisation tools need access to structured application data. A closed system means these can't be plugged in — full stop.
• Open Digital Planning → Your System BOPS, PlanX, and the Digital Planning Register all use open APIs as a design principle. Your system needs to be able to talk to them, or you'll be building a bridge nobody asked for at considerable expense.
It would be churlish of me to give a finite list of companies that I think you should include who they should be able to offer connectors to (and there is a whole ethics conversation we need to have about infrastructure here) but if we want innovation in our sector, and continuous innovation rather then just the one hit from Government, we need to start implementing frameworks that enable software to talk to each other.
However the mandating of connections would enable you to use the other submission systems in the market (like Submit a plan and PlandaPortal) as well as other consultation and workflow platforms we are seeing entering the market without cost and difficulty. This will enable you to access and use the benefits of AI whilst maintaining the safety and functionality of a back office system.
✓ PRACTICAL TIP In your procurement documentation, require: 1. A documented, versioned API specification (REST or GraphQL) covering all major data entities; 2. Read and write access to your own data — not just exports; 3. Named third-party integrations already live (and references you can call); 4. Commitment to API stability and deprecation notice periods; 5. Security and access controls that satisfy your IG team without requiring APIs to be switched off entirely. Any supplier who can't answer these questions clearly in their ITT response is telling you something important about how they think about your future. |
Quick Summary Checklist
Before you finalise your procurement documentation, run through these:
□ Does the contract include an LGR exit clause with a clearly defined trigger?
□ Have I involved heads of building control, licensing, and environmental health in shaping requirements?
□ Is the evaluation criteria cross-service, not just planning-module-focused?
□ Do I have a named SRO, business change lead, and technical lead in post before contract signature?
□ Have I budgeted realistically for internal programme resource (not just the licence fee)?
□ Does the ITT require a documented, versioned API specification as a mandatory deliverable?
□ Have I tested the supplier's API claims with a technical colleague — not just taken their word for it?
□ Does the contract include data portability provisions and clean exit arrangements?
None of this is designed to put you off. Modern back office planning systems, when procured well, are genuinely transformative — for your officers, for applicants, and for the communities you serve. Getting it right matters.
If any of this has sparked questions — about specific contract clauses, supplier market dynamics, or how to structure your requirements — I'm happy to talk. That's exactly the kind of quiet conversation that tends to be useful.