1. Understanding the problem


  • On average 50% of all Householder applications are invalid on receipt, and need to be resubmitted. This causes significant delays.

  • The system is incredibly confusing for applicants to navigate

  • Applicants need to visit and understand multiple websites and documents before submitting

  • The process is hugely costly - in terms of time and money – for both applicants and planning authorities

  • There are different local and national requirements that add further confusion

  • There is no indication at the point of submission that your application will be invalidated / refused for an obvious reason

Pain points for applicants

My application keeps getting sent back. A small, easy mistake can cause a big delay, and cost.
There is no clear, standard structure to tell you what information and documents are required
You don’t know what you don’t know. You need to already be an expert to use the service.
It’s so complicated. I’d need to hire a professional to even explore my options, so I’ll leave it.
I have to research across multiple websites and documents to find the information I need to use one service successfully.
It is inconsistent, the use, interpretation and prioritisation of policies seems to vary significantly

Pain points for officers

Every application has to be manually checked and validated. This typically takes 4-5 hours per application.
Every application has to be manually assessed against current legislation. There’s pressure on us to work quickly, but not to make mistakes.
Very little of my job involves actual planning A lot of my time is taken up doing data lookup and data entry.
Theres a lot of redundant information A lot of application reports are just our own policies regurgitated back at us. It’s hard to find the actual information we need.
A lot of time is spent dealing with applicants wanting more information or attacking the system in frustration, leading to complaints, twitter rants etc

Pain points for managers and the wider public

Resources are stretched, but we still need to process applications in time.
Costs are high The time it takes to process small applications is not covered by the fee.
Risk Ensuring consistency and quality of decisions is challenging, especially with high staff churn rate.
Resilience COVID19 has demonstrated that we need to be able to run all services remotely
Transparency & monitoring  Data about planning applications and analytics data is inaccessible or does not exist. 
Roadblocks The slowness and uncertainty of the process represents a cost and barrier to development, especially development by self-builders, small businesses and other small players
Democratic participation  It is incredibly hard for most people to engage constructively in public consultation because it takes so long to dig through folders of poorly name files to find the information that matters etc

How many planning submissions do councils receive?

Every year, councils receive thousands of planning submissions. This includes applications for planning permission (on average an authority in England receives 1400 of these per year), but it also includes other kinds of submission, such as applications for a Certificate of Lawful Development, Prior Approval requests or submission of details for approval.

So, for example, Lambeth Council receives 2100 applications for planning permission each year, but around 4900 submissions in total. However, data for the number of these other submissions is not collected, so the total number of them nationwide is not known.

How do they receive them?

Source: RIPA survey of UK councils, responses received

Currently the vast majority of planning applications are received indirectly via Planning Portal, which is now a private company. The remaining few are received directly by email or post.

On average, each application takes 4–5 hours to validate. Applications are managed through back-office case management tools, with subsequent communications between the applicant and the case officer largely by email or phone. For onward reporting, case officers have to manually enter find and enter data themselves.

How many are invalid?

Source: RIPA survey of UK councils, responses received

Source: Lambeth council (data to Jan 2021)

A significant number of planning applications received are ‘invalid’. This means checking whether some required documents are missing, incomplete or incorrectly formatted. Typically 50% or more of all applications are ‘invalid’, so the application needs to be resubmitted. In some cases, applications go around this cycle as many as 9 times.

Applicants have to wait 11 days for their application to be validated (in the case of small projects). If an application is invalid, it causes an average delay of 34 days before it is resubmitted. Around 10% are withdrawn entirely.

How much does this cost applicants?

We do not have any precise data for this, however we can make some informed estimates.

If we conservatively estimate that ensuring validity typically costs 1 day of an agent’s labour, at a £400 cost, then for the 447,934 planning applications received in England alone last year, this project could drive savings of around £179m. This will especially benefit homeowners and SMEs.

There are also indirect costs that are impossible to estimate, such as the costs of those project delays, subsequent disputes and lost opportunity.

How much does this cost planning authorities?

The time to validate, report, return and revalidate submissions varies, but we estimate that validation takes, on average, 5 hours per submission (the Planning Advisory Service benchmark is 4 hours).

Assuming a typical hourly cost of £50 per hour (including overheads), that represents an annual cost of around £350,000 per year for the average planning authority.

Across the whole of England* this represents an annual cost of at least £111m. However, this only includes planning applications. Allowing for all submissions, the actual figure may even be double this.

There are also indirect costs that are hard to estimate, such as the cost of additional failure demand (emails, phone calls, etc), the burden of manual data entry work, loss of trust and the additional cost of enforcement due to lack of data on starts and completions. Further general costs might include a high staff churn rate, training costs and the wider effects of reduced user satisfaction and trust.

What are the primary causes of invalidation?

Given the scale and cost of the problem, many people are surprised to learn how mundane and avoidable many of the reasons for invalid applications are. For example, missing a red line or a north point off the location plan, or not paying the correct fee.

The graph below shows a typical breakdown:

Data from Wycombe District Council

3. Our approach

The big opportunity present by the web is to shift from a planning system that runs on documents to one that runs on data.

From documents to data
Instead of asking users to provide information by uploading documents (forms, reports, statements and drawings) that can only be read by humans, wherever possible, planning services should ask for information in the form of structured data that can be read by humans or machines.

How will this help reduce invalid planning applications?

This allows us to do a few key things.

GIS data
It allows us to build services that pull-in any available geospatial (GIS) data relating to a property (for example spatial policies such as Conservation Areas) so the user does not have to research them.

Dynamic forms
It allows us to build services that respond immediately to the information already given, so users are only asked for information that is relevant to their project and location.
Web form validations
It allows omissions to be prevented from happening before the user can click submit, in the same way that many online forms do (eg when you buy insurance online).
Rules as code
Knowledge of specific policies and their implications for the user’s application can be coded into the service, so users don’t need to be experts.
Common registers
Pulling data from– and sending data to– common data registers, such as for addresses, property types, or planning registers.

Data interoperability
Creating a service API that makes data available in a structured, machine-readable way, ideally using open, standard schemas.

There are also some important, more general aspects to our approach:

APIs as a service

On the long term, we expect the service to be used not just by human users, but also by third party software applications via a REST API. This will allow others to build complementary software applications that send data to, or fetch data from the service. (Note need for appropriate security measures.)

Modular, extendable and updateable

We are designing all the services to be made using standardised, replicable modules, which can be run on a no-code editor platform, so they can be easily maintained, improved and updated by planning teams across different parts of government (local and national), ideally without knowing how to code. 

Standardise data

Wherever possible, we are using the same data structures as other services and registers, to maximise interoperability.


We can’t solve everything in one go. Instead we aim to develop a version of the service pattern that works (a ‘minimum viable product’), and then expand it later. You can read more about our scope here.


4. Objectives & principles

Our objective is to develop a digital service pattern called ‘Apply for Planning Permission’ that:

– allows applicants and their agents to submit planning applications to councils as data, as far as possible

– makes preparing and submitting a planning application as easy, unintimidating and as painless as possible for users

– reduces the number of invalid planning applications by 80%

– is interoperable with back-office platforms that can use the planning application data, making it easier and quicker for councils to process planning applications.

– is as easy as possible for councils nationwide to adopt and adapt

Design principles for digital planning services

Planning services should be as easy to find and use as possible for all who need to use them.
Planning processes, policies and requirements should be as clear as possible as early as possible in the design process.
Don’t expect users to be experts
Don’t ask applicants for information that they have already provided, or ask them to research information that is already known somewhere.
Allow applicants to see the reasons behind any rule or decision, referenced all the way back to policy, legislation or case law.
Only show / ask users information that is relevant to what they are doing, so everyone can focus on what matters.

Put planners in control
Planning services (rules, information requirements, data etc) should be controlled by the planning authorities who own them, not suppliers or ‘AI’.


5. Testing with users & stakeholders

This service pattern has to work for two main groups of people. Users (people applying for planning permission through a planning service) and also stakeholders (for example, planning officers, who receive these applications). Only these stakeholders can determine what information is needed to determine a planning application, and therefore whether it really is possible to achieve this transformation from documents to data.



People looking to apply for planning permission. This includes professional developers, businesses and private homeowners.


Professionals working for applicants, such as architects, design and build companies or planning consultants.

Customer service staff

Council helpline or helpdesk staff who may sometimes submit an application on an applicant’s behalf, either by telephone or in person. 


Planning case officers

Planning professionals working within the planning department, receiving and processing planning enquiries and applications.

Planning consultees

Planning professionals working within the planning department or other areas of government with expertise in a particular area (eg heritage), who will input into the assessment of a planning application.


Senior managers running planning departments.

Data register maintainers

Teams maintaining and publishing national and local data registers such as GIS spatial policy maps, a National Planning Register, the Local Land Charges Database, the Local Land and Property Gazeteer and the London Development Database

Gov planning agencies

Parts of central government with responsibility for / oversight of planning and development control, such as the Planning Directorate and the Planning Advisory Service

Types of Planning Consultee

Councillors (general)
Heritage / conservation
Building control
Community Infrastructure Levy (CIL)
Environmental health
Transport & highways

Stakeholder research & testing

Throughout the process we have consulted and tested the service continuously not just with users, but also planning officers and other stakeholders who have both explicit and tacit knowledge of the complexities of the planning process.

User research & testing

Throughout every stage of the project we have conducted continuous user testing with a range of volunteer users.

View the UR findings log here (live document)

User stories

View the live user Stories Map here.


6. Scope


Our end goal is to build digital planning services for every kind of planning application. We are following a ‘long tail’ strategy: starting with the many small, repetitive applications which represent a disproportionate burden on applicants and councils. Householder planning applications represent the next big milestone.

Stages of the user journey

0 Awareness
1 Exploration
2 Preparation
3 Submission
4 Payment
5 Validation
8 Appeal
9 Discharge of conditions
10 Monitoring & enforcement

The current project scope includes all stages up to validation. It does not yet include consultation onwards, although this could be part of our future scope.

Planning documents

What planning information will now be asked for as data instead of documents, and why? 


Current status     How often is it required for householders?Does it require  a certified professional?
Application formdata always    no
Materials listdataoftenno
Ownership certificatesdataalwaysno
CIL formsdatasometimesno


Current status     How often is it required for householders?Does it require a certified professional?
Design & Access statementdata often    no, but sometimes useful
Heritage Assessmentdatasometimesno, but sometimes useful
Ecology & trees checklistdataoftennot always
Flood risk assessmentdatasometimesnot always
Drainage / SUDS statementdatasometimesnot always
Basement impact assessmentdocsometimessometimes
Structural surveydocsometimesyes
Townscape visual impact Assessmentdocsometimesno, but usually useful
Navigational Risk Assessmentdocrarelyyes
Air Quality Assessmentdocrarelyyes
Biodiversity Surveydocrarelyyes
Archaeological Surveydocrarelyyes
Tree survey  / Arboricultural Impact Assessment docsometimesyes
Landscape & visual impact Assessmentdocsometimesno, but usually useful
Sun & Daylight assessmentdocsometimesyes
Local views assessmentdocsometimesno, but usually useful
Parking surveydocsometimesno


Current status     How often is it required for householders?Does it require a certified professional?
Location plandata always    no
Existing plansdocalmost alwaysno, but must be correctly drawn
Proposed plansdoc almost alwaysno, but must be correctly drawn
Existing elevationsdoc almost alwaysno, but must be correctly drawn
Existing sections docalmost alwaysno, but must be correctly drawn
Proposed sectionsdocalmost alwaysno, but must be correctly drawn
Existing roof plandocalmost alwaysno, but must be correctly drawn
Proposed roof plandocalmost always
no, but must be correctly drawn
Site plan docsometimesno, but must be correctly drawn
Site photographsdocalmost alwaysno
Existing detailsdocsometimes
no, but must be correctly drawn
Proposed detailsdocsometimesno, but must be correctly drawn
3D massing modeldocneveryes

See the full working schema here

Users with specific accessibility needs

Non-English-speaking usersnot yet
Users with dyslexiaconsider
Users with autismconsider
Deaf or hard of hearingconsider
Visually impaired usersconsider
Blind usersyes (screen readers) 
Users with physical or motor disabilitiesconsider
Users suffering from anxietyconsider
Elderly usersconsider
Non-web usersconsider
Users with outdated devicesyes (as far as possible)