Workplace parking software cannot run a paid car park

The dividing line in parking management software is not price, or reporting, or how good the mobile screens look. It is whether the software has a concept of a paying stranger who arrives at a time a third party told you about. Workplace tools do not, because their buyer never needed one, and no amount of configuration adds it later.

That is the whole argument. What follows is six ordinary things that happen in a paid car park, walked through both models, so you can check it against your own week rather than take my word for it.

Where the two models split

A workplace tool starts from a known employee, a known badge and a bay that is free again at six o'clock whether anybody used it or not. Money either never moves or moves through payroll, and the car never leaves its bay with somebody else driving.

An operator starts from a stranger. Somebody else sold them the night, somebody else set the price, and an airline decides when they come back. Money may still be owed at the kerb. The keys may change hands twice. Everything downstream follows from that one difference.

Event one: the booking arrives forty minutes before the car

A reseller confirmation lands in your intake mailbox at 04:41 for a 05:20 arrival. In an operations platform an adapter written for that reseller turns it into a booking before the car reaches the kerb, tagged with its source and its reference. If the adapter cannot read it, it waits in a review queue with the raw email attached and a reason on it, and an operator promotes it by hand.

A workplace tool has no inbound channel at all, because employees make their own bookings in the app. There is nothing to configure here. You will be typing that booking into a laptop while the customer stands in front of you with a suitcase and a flight at 07:10.

Event two: the guest lands three hours late

The outbound leg is easy. The return leg is where a car park earns or loses its reputation, and it is the leg no workplace product has ever had to think about.

The customer booked a return on the 20:50 arrival. The aircraft lands at 23:40. Their car is in row F behind eleven others, the shuttle driver on the late rota went home at 22:00, and nobody moved the car forward.

What helps is not a clever algorithm. It is a departure board listing the cars physically on site awaiting delivery, one row per departure day, each with scheduled time, plate, model, colour and bay, refreshing on its own on a screen in the office. It is a live board anchored to now and rolling about eighteen hours ahead instead of resetting at midnight, because an operational day is not a calendar day. And it is a shift rota built against the arrivals and departures expected in each hour, so somebody is rostered at 23:40 in the first week of August.

Be clear about what nobody gives you: ParkAgenda does not track flights. No flight data enters the product and the console links out to a third party tracker like everybody else's. What it does is make the late return visible on the board and staffed on the rota.

Event three: the key goes to a second driver

In a workplace car park the driver keeps their keys. Always. There is no other case.

In a valet or a full service car park the key decision is per stay and it has to be recorded by a person. Keys handed over, customer keeps the keys, or valet. The system can suggest which one from the booking, but an operator confirms it, and if the confirmed mode differs from the suggestion it needs a reason and the stricter policy applies. If the customer keeps their keys, the car cannot be recorded as holding keys and a bay number becomes mandatory, because nobody can move that car and you need to know exactly where it is.

Alongside it sits the intake: a six step check-in that records handling and keys, the state of the vehicle, damage markers placed on a diagram with a type, a severity, a comment and photos, and a customer signature, ending in a PDF. Removed markers are kept as tombstones rather than deleted, and a finalised check-in only changes through an amendment carrying who, when, why and the difference. That is what you put in front of somebody in October who says the scratch on the nearside wing was not there in July.

Event four: cash at the desk on a Sunday

Nothing in a workplace product models money changing hands at the point of arrival, because it never does.

An operator needs an append-only ledger. One line is one amount, one method, one moment and one named person. Cash or card. Taken at check-in, at check-out, or on its own. A mistake is voided with a reason and superseded, never edited, because a line somebody can quietly change is not evidence. On top of that: outstanding balance per booking, uncollected departures, blind declared counts with the variance snapshotted at the moment of counting, handovers between operators, bank deposits and cash on hand per car park.

The honest limit, stated because it changes how you read the word card: ParkAgenda does not process payments. Card on a line means the customer paid on your own terminal and an operator declared it. There is no capture, no refunds, no change given and no second currency.

Event five: one operator covering two sites

A workplace tool assumes one building, one timezone, one set of rules.

An operator with three car parks needs each one to carry its own capacity, its own branding on customer emails, its own contact address and its own timezone, and to still be able to read bookings, agenda and analytics across all three in one view. ParkAgenda aggregates those reads server-side across whichever car parks you select.

The one place it deliberately refuses to aggregate is the dispatch board. That shows one panel per car park side by side, never merged, because two sites merged into a single dispatch stream cannot be reconciled by the person watching it. Drivers and desk staff are scoped to the sites they are assigned to, and they sign in with a name and password their manager chose. A shuttle driver does not need a company email account to use the system, which matters when half your drivers are seasonal.

What you do not get: a native app. The console is a web app and a named set of pages is designed for a phone, including bookings, agenda and analytics. Everything else shows a not-optimised screen on a mobile, and there is no offline mode.

Event six: the car park is oversold by four

Here is the worked example. The figures are constructed for the example, not measured.

Take a 320 bay car park near a UK airport. On the Friday of the first August weekend, reservation occupancy reads 341 stays against 320 bays, which is 107 per cent. Assume for the example a four per cent no-show and late cancellation rate on reseller bookings, which on 341 is about fourteen cars. That still leaves you seven over.

A workplace tool refuses the 321st booking. It is right for its buyer and wrong for you, because every off airport operator oversells and it is rational to do so.

An operations platform should show you the 107 per cent and let you decide. That means a forward indicator on the coming days, a non-blocking warning at the moment you write the booking, and a digest in your inbox at 20:00 the evening before, sent in that car park's own timezone. Seven cars is a solvable problem at 20:00 on Thursday: bring forward three departures, open the eleven bay overflow row by the fence, ring the two longest stays. It is not a solvable problem at 06:15 on Friday.

The one thing that should block anybody is physical. A car cannot be checked in when the number of cars actually on site equals capacity, because at that point there is nowhere to put it. Reservation occupancy is a forecast to manage. Cars on tarmac is a wall.

This is not a complaint about Parkable or Skedda

They are good products aimed at a problem they understand, and if your bays are for your own staff you should buy one of them rather than an operations platform. They will be cheaper and simpler and they will fit.

The failure is not theirs. It is a review directory that prints all of this in one table under one heading, and an operator who shortlists from that table loses a quarter finding out.

The question that sorts it in ten seconds

Does somebody who does not work for you decide when the car arrives?

If the answer is yes, you are not in the workplace market, whatever the directory says, and no feature comparison will change that. If the answer is no, stop reading and go and buy a workplace tool.

Questions we get asked

We have ninety bays and two staff. Is a workplace tool not enough?

Size is not the test. A ninety bay car park selling seventy per cent of its nights through two resellers has the same four channel problems as a four hundred bay one, at a smaller scale and with fewer people to absorb them. Answer the sorting question instead of counting bays.

Can the system tell me a flight is late?

No. ParkAgenda has no flight tracking and no flight data enters the product. What it gives you is the return leg visible on the departure board and a rota built against the movements expected per hour, which is what you would do with the flight information anyway.

We already have barriers and plate recognition. Where does that fit?

They stay where they are. ParkAgenda has no hardware, drives no barrier and reads no plate. It holds the plate on the stay so your own system has a booking to match a read against, and our team builds the connector with your supplier. Installation can go through a partner near you.

Where to start

Take last Friday. Write down the six events above against what actually happened, and mark the ones your current tool or spreadsheet handled without a person improvising. That list is your requirement document, and it is more useful than any feature matrix.

Then read what a booking system has to do when you do not own the sales channel, which is the pillar behind this one, and why the UK search results for car park management are full of enforcement companies. The features page covers the six events in screens, and the FAQ answers the commercial questions.