ANPR, Barriers and Capacity: The Software Behind Modern Car Park Operations

The Gap Between a Booking and a Car on Site

A booking system tells an operator that a customer intends to arrive at 4am on the 14th. A car park management system deals with what actually happens: a different car turns up, at a different time, sometimes with a booking reference the driver cannot find, in the rain, with a flight to catch.

That gap is where most airport parking operations lose money and goodwill. The booking side is well understood and reasonably well served by software. The operations side — barriers, cameras, space allocation, staff on the ground, and the reconciliation between what was sold and what was parked — is where we consistently find operators running on paper, memory, and a WhatsApp group.

This is a practical guide to the software layer that closes that gap: ANPR, barrier control, capacity management, and the integrations that make them behave as one system rather than three products that happen to share a car park.

What ANPR Actually Gives You

Automatic Number Plate Recognition is a camera and a piece of software that reads a registration plate as a vehicle approaches. On its own it is a fairly dumb sensor. Its value comes entirely from what your system does with the read.

The four things ANPR makes possible in an airport parking operation:

• Barrierless or fast entry, where a booked customer drives up and the barrier lifts without them touching anything, because the plate matched a booking for today.
• Accurate stay records, so the actual entry and exit times are captured rather than estimated from the booked dates. This is what allows an operator to bill overstays fairly and defend the charge when challenged.
• Occupancy truth, since counting vehicles in and out gives a live count that is independent of what the booking system thinks should be on site.
• Enforcement, identifying vehicles with no matching booking so they can be dealt with before they occupy a space that has been sold.

The thing operators are usually surprised by is that ANPR does not remove staff. It removes queueing. A busy car park at 4am on a Saturday in August has a queue at the entrance because every driver is fumbling for a booking reference. Removing that friction is worth more than the hardware costs, and it is the single most visible improvement a customer notices.

Plate Matching Is Messier Than Vendors Admit

Every ANPR vendor quotes a read accuracy figure in the high nineties. Those figures are measured in good conditions. Real conditions include rain, low winter sun straight into the lens, dirty plates, non-standard fonts, tow bars and bike racks obscuring the plate, foreign plates, and courtesy cars the customer never mentioned.

The software layer has to be built assuming imperfect reads. What that means concretely:

• Normalise every plate on both sides — strip spaces, uppercase everything, and store the raw read alongside the normalised value so you can diagnose failures later.
• Use fuzzy matching with a tight edit distance. A single character difference between the read and a booking for today is almost always the same car; a two-character difference usually is not. Confirming a near match against the booked arrival window makes it safe.
• Always keep a fallback. A booking reference, a surname, or a QR code from the confirmation email must let a customer in when the camera fails, and that fallback needs to be usable by a driver in a queue at 4am, not just by staff.
• Log every unmatched read. The unmatched list is where operational problems surface — customers arriving on the wrong day, bookings made under a partner's registration, and genuine trespassers all show up there first.

The mistake we see repeatedly is a system that treats a failed read as an exception to be handled by a human on the spot. At volume, exceptions are not rare. Design the exception path as a normal path.

Barrier and Hardware Integration

Barriers, ticket machines, and cameras come from a small number of manufacturers, and each speaks its own protocol. Some expose a clean HTTP API. Some expect a TCP socket connection and a proprietary message format. Some only integrate through a local Windows service the vendor supplies. All of them will, at some point, be unreachable.

The architectural rule that has saved us most often is to put a queue between your application and the hardware. Your platform publishes an intent — open lane two, record this entry, display this message — and a small local agent consumes it and talks to the hardware. That separation means a network blip or a rebooted controller delays a barrier lift by seconds instead of throwing an error into a customer-facing flow.

Two more decisions worth making early:

• Decide what happens when the connection to the central platform is down. A car park that cannot admit anyone because the internet is out is not acceptable. The local agent needs a cached list of today's expected plates so it can keep operating in a degraded but functional mode, then sync when connectivity returns.
• Record every barrier event, including manual overrides by staff. When a dispute arises about whether a vehicle was on site, the event log is the only evidence that matters.

Capacity Management Beyond a Simple Count

Selling spaces is a booking problem. Filling a car park efficiently is an operations problem, and they are not the same thing.

An operator with 600 spaces does not have 600 identical units. There are spaces near the shuttle stop, spaces that are hard to reach, undercover bays sold at a premium, EV charging bays, oversize bays, and a stacking area where cars are parked in rows behind each other because the site is at capacity and the return dates are known.

The capacity features that earn their keep:

• Zones — the site divided into areas with their own counts and rules, so premium and standard products draw from the right pools.
• Stacking and shuffle planning for meet and greet operations, where the system suggests where to park a car based on its return date so that early returns are not buried behind late ones.
• Live occupancy from ANPR counts, reconciled daily against the booking system's expected occupancy, with the difference surfaced as an alert rather than silently absorbed.
• Overbooking allowances per product and per date range, with a clear view of how much of the allowance has been consumed.
• Blackout and maintenance windows, so resurfacing 40 bays next month removes them from sale automatically.

The reconciliation point deserves emphasis. The number one operational failure in this sector is a slow drift between what the booking system believes is on site and what is physically there. Catching a 15-vehicle discrepancy the day it appears is routine. Catching it three weeks later, during half term, is a crisis.

Overstays, No-Shows and Revenue Recovery

Two categories of money leak out of car parks quietly.

Overstays are customers who return later than booked. Without ANPR the operator often never knows, or knows but cannot prove it. With entry and exit reads, an overstay is a factual record, and the system can apply the published overstay rate automatically and charge the stored card or issue an invoice. The tone matters here — a system that charges aggressively for a 40-minute delay caused by a delayed flight will generate complaints and bad reviews that cost more than the fee recovered. Sensible platforms build in a grace period and cross-reference flight status before charging.

No-shows are the reverse: a space sold and paid for but never occupied. These are not a loss, but they are information. A product with a persistently high no-show rate can support a higher overbooking allowance, which turns unused capacity into revenue. Without ANPR data, no-show rates are guesswork.

The third category, less discussed, is the unbooked vehicle. Every operator has some level of unauthorised parking. An unmatched-read report that runs daily turns that from a suspicion into a list with timestamps.

Staff Tooling on the Ground

Whatever the central system does, the people in high-vis jackets need something that works in their hands. Our consistent findings from building these:

• It must work on a phone, not just a tablet, because staff are moving between vehicles and a phone is what they already carry.
• It must tolerate poor connectivity. Car parks are frequently concrete structures or remote compounds with weak signal. Actions taken offline must queue locally and sync later, and the interface must clearly show what has and has not synced.
• The primary action is looking up a vehicle. Registration search must be the first thing on the screen, tolerant of typos, and fast.
• Photo capture at check-in and check-out is essential for meet and greet operations. Damage disputes are common, and timestamped photographs settle almost all of them.
• Buttons need to be large. People use these with gloves on, in the dark, in the rain.

This sounds obvious written down. It is routinely ignored by systems designed in an office and demonstrated on a laptop.

Where Compliance and Data Protection Bite

ANPR captures vehicle registrations, which are personal data under UK GDPR when they can be linked to an individual. That has practical consequences that need designing in rather than bolting on:

• Signage at every entrance stating that ANPR is in operation, who the operator is, and the purpose of processing.
• A defined retention period for read data and images, with automatic deletion. Keeping every image forever because storage is cheap is not a defensible position.
• A lawful basis documented for each use — contract performance for matching a customer to their booking, legitimate interests for enforcement, and these are not interchangeable.
• Subject access request handling, since a customer can ask for the images and records held about their vehicle.

For operators enforcing parking charges, membership of an accredited trade association and adherence to the relevant code of practice is what gives access to keeper data and makes a charge enforceable. This is a legal and commercial process rather than a software one, but the system needs to produce the evidence pack — reads, images, timestamps, signage photos — that the process requires.

Integrating With the Booking System

The car park management layer and the booking layer are separate concerns and should be separate services, but they need a tight, well-defined contract between them. What has to flow:

• Today's expected arrivals pushed to the local agent well in advance, so entry works even if the link goes down.
• Entry and exit events pushed back to the booking record, updating actual times and triggering overstay evaluation.
• Live occupancy fed back into availability so that a genuine capacity problem closes sales for that date automatically.
• Amendment events flowing forward, because a customer who extends their stay by three days needs the barrier to know.

Operators who buy a booking platform and an ANPR system from two different vendors with no integration end up with staff manually reconciling two screens. That manual reconciliation is exactly the cost the software was supposed to remove.

What to Do First

If you are running a car park on spreadsheets and considering this, the order that produces value fastest is not the order most vendors sell in.

Start with accurate capacity and a live occupancy view, even if occupancy is entered manually at first. Knowing the true number is the foundation for everything else. Add staff mobile tooling next, because it removes the paper and gives you clean data. Add ANPR after that, once the surrounding processes exist for it to feed. Barrierless entry and automated enforcement come last, when the matching logic has enough real data behind it to be trusted.

Buying cameras first and hoping the processes will follow is how operators end up with expensive hardware producing reports nobody reads.

We build both sides of this — the booking engines and the operational platforms that sit underneath them, including ParkPilot and the systems behind several UK airport parking operators. If you are weighing up ANPR, replacing a manual process, or trying to make two vendors' systems talk to each other, our contact page is the place to start.