What a parking booking system has to do when you do not own the sales channel

Most car park booking systems are built for a buyer who owns the sale. A commercial car park does not own it. Somewhere between half and nearly all of its nights are sold by another company, on another company's website, at a price that company set. So the feature that decides whether the software works is not the booking form. It is what the system does when two channels sell the same space for the same night and neither of them tells you.

Every page currently ranking on parking booking system is desk booking for employees. Those products are good at their job. Their buyer controls the space and knows the person taking it. Yours does neither.

The booking form is the part everybody gets right

Any vendor can build a booking form. The problem in a commercial car park is that almost nobody fills it in.

Reservations arrive from resellers who have their own checkout, their own confirmation email and their own reference numbering. They arrive from your own website, from a phone call on a Tuesday afternoon, and from a driver who turns up at 05:20 with no booking at all. A system that starts from a form and treats everything else as an import is starting from the smallest source of volume you have.

Worth saying plainly, because it comes up in every demo: ParkAgenda has no booking widget for your website and no public availability search. If you sell direct, your own site is treated as one more booking source, with its own reference numbers and a commission rate of zero. The product is the operations back office, not the shop front.

Four ways a booking actually gets in

There are four capture paths, and a vendor should be able to show you all four running on a live car park. Ask for the demo in that order, because the first one is the one most products cannot do.

• The reseller's own email format. Your car park gets a monitored address. The reseller keeps sending exactly the email it already sends, and an adapter written for that vendor turns it into a booking. Nobody asks the reseller to change anything, because the reseller will not.
• An API pull. ParkAgenda pulls from Parkos today, per merchant, on a cursor over what changed since the last run, with a deliberate overlap and a reconciliation across the arrival window. The raw response is kept against the sync, so you can see what the reseller actually sent.
• A CSV import. Idempotent on the combination of car park, source and reference, so re-running the same file changes nothing. Every row comes back created, updated, unchanged or failed with a reason. This is how history gets migrated. Today our team runs it, not you.
• Somebody typing it. The counter, the phone, the walk-in. Still a booking, still attributed to a source, still in the same queue.

Now the honest part. Capture from a named reseller means a parser our team wrote and maintains. It is not a certified partnership and there is no catalogue of connectors to click through. The list of names is short and finite. Parkos and AlloPark are on it. A source that is not on the list goes through the REST API or a CSV, and building a new adapter is work that gets quoted as work. If a vendor tells you their integrations are plug and play, ask which of your four resellers they have actually parsed.

The night two channels sell the same space

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

Take a 400 space car park serving a regional airport. Average stay eight days, so on an ordinary day roughly fifty cars arrive and fifty leave. Sixty per cent of nights come through resellers, spread over four brands, at commission between fifteen and twenty five per cent. Call the average stay 72 pounds, nine pounds a night.

On Tuesday a customer books eight days through reseller A. On Thursday they find the same dates four pounds cheaper on reseller B, book again, and cancel the first one. Reseller A registers the cancellation in its own portal at 23:40. Reseller B sends its confirmation email two minutes later. If your only sync is a nightly export, you are now holding two live bookings for one car, and on Friday morning your board says 401 cars against 400 spaces.

The 72 pounds is not the expensive part. The expensive part is the fifteen minutes an operator spends at 05:00 working out which of the two is real while a queue builds behind the desk, and the reseller statement at the end of the month charging commission on a stay that never happened. Multiply by a July where that happens four times a week.

What a system should do about it: hold both records, spot that they are the same car over the same window, and let a person merge them into one booking that keeps both source references. The reference has to survive the merge, because that is what you argue the commission line with.

The second thing it has to do is ask again. Cancellations arrive late and out of order. A pull that only fetches bookings created since the last run will never see a cancellation that was back-dated. That is why the cursor carries an overlap, and why the arrival window is reconciled instead of trusted.

What happens to a booking the system cannot read

An unreadable booking should stop, keep the original email, and say why. It should never be guessed at and never silently dropped.

A reseller changes their confirmation template in the middle of August. Yours is one of eight hundred car parks on their platform and nobody tells you. For a week the parser returns nothing usable. If those bookings vanish, you find out at the kerb. If they land in a review queue with the raw email attached and a reason on each one, an operator promotes them by hand in ten minutes a day and you tell us to update the adapter.

The same queue handles the other failure: an email from an address you have never seen. ParkAgenda whitelists exact sender addresses, not domains. It is more work to set up and it is the right trade, because a domain whitelist means anybody with a mailbox at that reseller can write bookings into your operation.

From that queue a person can promote the booking, reprocess it once the adapter is fixed, whitelist the sender, or dismiss it. Nothing disappears on its own.

The name on the booking is not the name on the car

Matching is the hard part of channel work, not capture. Capture is a parser. Matching is a judgement call, and the system should put the evidence in front of a person rather than pretend.

The reseller sends Jean-Pierre Delacroix-Martin. The customer at the desk says Delacroix. The plate was typed by that customer on a phone at one in the morning and carries a space in the wrong place. Each channel numbers its bookings its own way, so the reference is the only key you can trust, and it is only unique inside its own source. That is why deduplication runs on car park plus source plus reference, and why the plate on the record is a text field somebody typed rather than something the software knows to be true.

That last point matters if you already run plate recognition on the entry lane. The read from your camera has to match a string a stranger typed into a reseller's checkout two weeks earlier. ParkAgenda does not read plates and does not drive your barrier. It holds the plate on the stay so your own system has something to match against, and our team builds the connector with your supplier.

Five things to ask a vendor to show you

1. A booking arriving by email in the reseller's own format, with the reseller changing nothing.
2. The queue where an unreadable booking waits, and the raw evidence sitting next to it.
3. What the screen does when you try to check in the 401st car into 400 spaces.
4. The same customer booked twice through two channels, merged into one stay that keeps both references.
5. The list of named sources supported today, and a quote for the one of yours that is missing.

If a vendor cannot do the first one, everything after it is theory.

Questions we get asked

Does ParkAgenda take my customer's payment?

No. The amounts on a booking are what the channel says was paid and what is still owed. Money collected at the desk is written to an append-only ledger with the operator's name on every line, as cash or as card. Card there means the customer paid on your own terminal and an operator declared it. There is no payment processing inside the product.

Is the reseller sync real time?

No, and be careful with any vendor who says theirs is. The API pull runs on a timer with a cursor and an overlap. Email intake arrives when the reseller sends the email. Nothing is ever written back to the reseller, so a cancellation you make in ParkAgenda does not cancel anything on their side.

Can I put a booking form on my own website?

Not from ParkAgenda. There is no widget and no anonymous availability search. Bookings from your own site come in as a booking source like any other channel, through the API or by email.

Where to start

If you want to know whether your channels are readable, send us one confirmation email from each of your resellers with the personal details removed. That is enough to tell you which ones parse today, which need an adapter, and roughly what the missing one costs.

The features page covers what happens after capture. The pricing page is one plan billed per car park licence. If you are coming off another system, moving reservation history without losing the reference numbers is the post to read next, and why workplace parking software cannot run a paid car park explains why so much of this market looks like a competitor and is not one.