1. Understanding the problem

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

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


2. Approaches taken so far

Publishing validation checklists, guides and fee calculators on websites

Most councils provide these on their websites. They are reported to make some difference, but very little, since these themselves are often missed, and users are not sure which requirements apply to their project. They also put the burden onto users to be aware-of, find and wade-through even more documents, even though this was part of the problem in the first place.

Machine-learning software that automatically checks documents

For example, Milton Keynes Council have demonstrated the use of image-recognition software to identify and check drawings by type. Other similar approaches might include teaching algorithms to read the contents of reports. This is technically very impressive, and may be useful in some areas, but as a general approach to the whole problem it would be a very complex, laborious and expensive way to solve the problem ‘downstream’ (with limited reliability) instead of intervening upstream to avoid mistakes in the first place.

Web forms with field validation

In the world of digital services the standard approach to solving this problem is to use a web form with ‘field validations’. Almost every digital service we use in our day to day lives uses this approach. The most common example of this might be a text field in a form that is marked with an * , meaning that the field cannot be left blank.

This is hugely effective in that it communicates to the user what is required, and actively prevents the submission of an invalid form. However, most digital services require relatively little information, and the required information is the same for all users (‘one form fits all’).

This is not the case for planning. Planning requires large volumes of information, and what information is required will depend on many factors, such as project size, location and the nature of what is proposed. It is also subject to change from time to time and from local council to local council. Conventional, hard-coded linear forms are too limited in scope to deal with this, a flexible dynamic form structure is required.

The project that has so far advanced the furthest in developing such a service is ‘Submit My Planning Application’, developed by Hackney Council, working with Snook and Hacktar. This project showed extraordinary promise as a step towards the future, not least in being the first to achieve the milestone of allowing users to submit a digital site boundary instead of a site drawing.


3. Our approach

Our hypothesis is that the solution to the problem lies in a shift in the way we ask for information.

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.

Data automations
It allows data to be pulled in from external sources, so users don’t have to look-up (or even know about) planning constraints that apply to their property, make a location plan, or calculate the correct fee for themselves
Dynamic forms
It allows forms to respond immediately to the information already given, so users are only asked for information that is relevant to their project.
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.

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

APIs as a service

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 will break down the service pattern into modules, allowing it to be easily understood, maintained, improved and extended by domain experts (eg planning officers, internal consultees, service designers and content designers) across different parts of government (local and national), ideally without knowing how to code. 

Standardise data

Use the same data strucures 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.
Less work
Cut out laborious work that doesn’t need to be done, 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. Understanding 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

We have been working with planning officers from across 5 councils to understand the planning process as it is today and understand key tasks and pain points. We have produced a collaborative map of the service as it currently is. 

You can view and comment on the original live, working diagram here

What have we learned? 

There are knock-on benefits through the process Aside from reducing invalid planning applications, submitting planning information as structured data will also have myriad other benefits for planning authorities, making it much easier and faster for officers to process planning applications, and meet reporting requirements.

Site boundaries 
Rather than inferring the site boundary from the property boundary, or relying on addresses, it makes sense to ask all users to draw a site boundary.

Unique requirements
Although most information requirements are the same for all councils, some information requirements and rules (for example ‘free go’ rules relating to the fee) vary from council to council.

User research & testing

Before our project began, some excellent discovery-stage user research for planning submissions services was carried out by Snook for Hackney Council, and can be found here.

During Alpha stage, we:

–     Surveyed 96 research volunteers on their planning application past experiences

–     Conducted 13 usability test sessions with 3 distinct user groups. This comprised 6 agents, 5 applicants and 2 technical officers.

–     Iterated and tested 3 versions of the RIPA prototype from paper to digital

–     Produced 263 lines of consolidated usability test findings (read them here)

The summary of our user research findings can be found in our Alpha stage project report (coming soon)

What have we learned?

Progress bar
If possible, the progress bar and service steps navigation should be combined, made more visible and repositioned. This will also allow the navigation bar to be smaller.

‘Started’ not ‘In progress’
Use the term ‘started’ or similar instead of ‘in progress’ for applications and sections of an application.

A ‘review before submitting’ step should be added with a prompt to invite an applicant.

Upload stage
Uploading drawings and reports may come as an additional stage.

Unlisted addresses
Create a clear route for properties with no address, or for which the address is not listed.

Download application
After submitting, users should be able to return to view and download their application anytime.

Additional documents upload
Even where asking for data instead of documents, give users the option to upload additional documents if they wish.

Preview stage
If possible, a step could be explored giving users a preview of likely fee and document requirements before they fill-out the application.

User stories

As an applicant I want to be told what information is required so I can see how much the process will cost

As an applicant I want to spend the least possible amount of time submitting an application so I can get on with my life

As an applicant I want to avoid my application being sent back so I can avoid frustating delays

As an applicant I want to complete the whole process in one place so I don’t have to hunt around multiple websites doing research

As an applicant I want the rules of the service to be transparent so I can trust it

As an applicant I want to be able to leave and come back to my application so I can complete it over multiple sessions

As an applicant I want to be able to share the application with my agent so they can do some of the work for me

As an applicant I want to be able to see anything my agent has filled in on my behalf so I can check that it’s correct

As an applicant I want to be able to do some or all of the work myself so I’m not paying my agent to do something I could do

As an applicant I want to use the same login I use for other council services  so I don’t have to remember multiple passwords

As an applicant I want the technical terms to be explained  so I feel empowered to make informed decisions

As an applicant I want to see where my proposal can better meet policy so I can avoid my application for planning permission being refused (not in alpha scope)

As an applicant I want to be kept up to date about the progress of my application so I know it is being processed  (not in alpha scope)

As an agent I want to manage multiple applications at once so I can see all my live applications for all my clients

As an agent I want to be able to share the application with my client so they can pay the fee

As an agent I want to process any requests for further information as part of the same original application so I can keep track of applications more easily (not in alpha scope)

As an agent I want the process and requirements to be as standardised as possible across all councils so I don’t have to relearn the process every time

As an agent I want my client to be notified when an application has been successfully submitted so I can invoice them

As an agent I want to be able to download my application after I have submitted it so I can keep a copy for my records

As a customer service agent I want to be able to access and view a customer’s applications so I can complete an application if they have already started it

Stakeholder Stories

As a planning officer I want to get all the information I need about a proposal so an assessment can be made without needing to request further information

As a planning officer I want it to be impossible to submit an invalid application so I don’t have to spend time manually validating applications

As a planning officer I want users to know what planning constraints (eg conservation areas) apply to them so they don’t need to call us to ask

As a planning officer I want to spend less time doing data entry so I can spend more time planning

As a planning officer I want applications to come in pre-assessed against policy so I can focus only on key issues  (not in scope yet)

As a planning officer I want relevant consultees to be notified automatically so I don’t have to (partially in scope)

As a planning officer I want to be able to request further information and attach it to the original application so all the information about a submission is in one place (not in scope yet)

As a planning officer I want to be able to adapt the service to our local requirements as a council so we can respond to particular local priorities

As a consultee I want applications to contain all the information I need to assess them so I can make informed decisions

As a consultee I want a say over which projects are brought to my attention and which aren’t so I can apply my time only where it is most needed

As a manager I want to reduce operational overheads so officers can spend more time on actual planning work

As a manager I want analytics and monitoring so I can understand the performance of the service and how to improve it   (not in scope yet)

As a manager I want to validate and decide applications within the allotted time so we are achieving our targets

As a manager I want to liberate planning officers from repetitive, de-motivating work so we can retain staff

As a manager I want to increase user satisfaction so I can demonstrate that we’re doing a good job

As a manager I want to ensure consistency and quality of decisions so we can avoid appeals

As a manager I want to ensure interoperability with our legacy systems so I can implement changes gradually not in scope

As a data maintainer I want to receive new entries automatically as structured data so they don’t have to be manually entered into datasets

As a data maintainer I want to pre-define fields for data so the data we receive is consistent and reliable

As a data maintainer I want to get feedback on inaccurate entries so I can keep data checked and up to date more easily   (not in scope yet)

As a government agency I want to promote standards across local government so I can ensure consistency of services