A weekly list across a dozen councils
If you install solar panels, supply modular buildings, sell groundworks, advise on ecology or simply want to know what is being built near your sites, planning applications matter. So someone opens each council's planning portal, searches the weekly list, reads the descriptions, and copies anything relevant into a spreadsheet.
Covering a region can mean a dozen or more portals, each with its own search screen. Some list applications weekly, some daily, some by ward. Descriptions are short and inconsistent, so a promising scheme hides behind wording like erection of building for use class E.
Why planning data is hard to follow
Councils use a few common planning systems, but each installation is configured differently, and there is no single national feed covering every authority. Some councils publish open data or weekly lists as files; others only have the searchable portal.
| Source | Typical route |
|---|---|
| Council open data releases | Direct download or API |
| Council weekly lists | Published pages or files, collected politely |
| Planning portals without data exports | Public search pages, within the council's terms |
| Commercial planning data providers | Licensed feed if coverage justifies the cost |
The bigger problem is relevance. Most applications are house extensions and tree works. The handful that matter to you are buried among them, and deciding which is which takes reading.
What manual checking costs
Leads found late, after a competitor has already been in touch with the applicant or agent. Councils skipped in busy weeks. Staff time spent reading hundreds of irrelevant descriptions. And no history, so you cannot see which agents, architects or developers are most active in your area.
For those watching for risk rather than opportunity, such as a business near a proposed development, a missed consultation deadline means losing the chance to comment.
Spreadsheets of past applications also go stale. Nobody goes back to update which schemes were approved, so the list cannot tell you which leads turned into real projects, or which agents your team already knows.
How we build a planning application monitor
- We agree the councils, application types, sizes and keywords that matter, and what should happen when one is found.
- For each council we pick the best route: open data first, published weekly lists next, and polite collection of public search pages only where the council's terms allow.
- Applications are normalised into one format: reference, council, address, postcode, description, applicant and agent where published, dates, and link.
- Rules filter on location, type and keywords, and an AI model such as OpenAI or Anthropic Claude reads the description to judge relevance, with a short reason shown.
- Relevant applications go into a daily or weekly digest, or into your CRM as leads, with consultation deadlines highlighted.
- Status changes are tracked, so you see when an application is approved, refused or withdrawn.
- Each council's collection reports its health, and a named person is alerted if a portal changes and stops returning results.
Applicant and agent names can be personal data, especially for householder applications. We keep what is collected to what you need and help you think about how you use it for contact. This is general guidance, not legal advice.
One digest instead of a dozen portals
Your team opens one list of applications that fit, each with the reason it was picked and the dates that matter. Nobody logs into council portals. Approved schemes can trigger a follow-up, and over time the history shows which agents and developers are busiest where you work.
Adding a new area means adding its councils to the monitor rather than to someone's weekly routine.
Does your team do this?
- Someone checks several council planning portals by hand
- Relevant applications are found late or not at all
- Descriptions have to be read one by one to judge relevance
- Consultation deadlines have been missed