Crew and staff contracts belong in the same queue as retail bookings

Search monthly parking software and every result is a commuter subscription in a city centre garage. The airport version of that product is the crew contract, the ground staff contract and the long stay agreement, and almost every operator keeps those in a spreadsheet on the office PC.

That split makes the occupancy number wrong every single day, by roughly the size of the contract base. The split belongs in the price and in the billing. It has no business being in the availability calculation.

There are two ways to get this wrong, and the careful one costs more

Either the contracts are invisible to the system, or they are held back as a permanent block of spaces. Both produce a wrong occupancy figure, and the second one is more expensive because it feels prudent.

Invisible is the obvious mistake. Capacity is set to the full site, the contract cars never appear, and the number on the dashboard understates reality by whatever is parked in the contract rows that morning. You oversell without meaning to, and you find out at the barrier.

The careful mistake is to drop the capacity by the size of the contract base and forget about it. Now the system sells against a smaller car park every day of the year, including the days when half the contract holders are away. You never oversell, and you never fill up either.

A contract is a stay pattern, not a car that is always there

Crew rotate. A crew contract is not a permanent occupant, it is a car that appears for two to four days, leaves, and comes back the following week. Ground staff are steadier but they take holidays.

Which means the honest occupancy contribution of a contract base is not the number of contracts. It is the number of contract cars physically on site on that date, and that number moves by a factor of two across a normal month. Blocking the contract base flat gets it right on maybe one day in thirty.

The arithmetic, with numbers

Take a 400 space off airport car park with a shuttle. These figures are constructed to show the arithmetic. They are not a customer's numbers.

• 60 monthly contracts: 38 airline crew, 22 ground handling staff, at 95 EUR a month each. That is 5,700 EUR a month, 68,400 a year.
• Contract cars actually on site, counted every morning through one March: 41 on average, 26 on the quietest Sunday, 58 on the busiest Thursday.
• The office holds 60 spaces back, so the system sells against 340.
• Average unused headroom: 60 minus 41, which is 19 spaces a day, or 589 space days across the month.
• At an average daily rate of 8.50 EUR, those 589 space days are 5,006 EUR of retail revenue that was never offered for sale.

So the contract base earns 5,700 EUR a month and a flat block gives back 5,006 EUR of it in retail nights nobody was allowed to sell. You have run a contract business for the price of a rounding error, and the loss never appears on a report because a space that was never offered does not show up as a refusal.

Now run the other mistake on the same site. Capacity left at 400, contracts invisible, and 355 retail bookings on the books for the first Saturday of July. The dashboard reads 89 per cent, which is comfortable, so the counter keeps selling. Contract presence that day is 52. 355 plus 52 is 407 against 400 spaces. Seven cars arrive from 05:20 with nowhere to go, and the person who finds out is the one standing on the kerb.

The block is not always wrong. On the Thursday when 58 contract cars were in, holding 60 back was very nearly right and nothing broke. It is wrong on average, which is worse, because nobody notices.

What it looks like when the contract stays are in the queue

Put every contract stay in the same queue as the retail bookings, with a real arrival and a real departure. Occupancy is then computed from stay windows over capacity, so a Sunday with 26 contract cars reads 26, not 60.

ParkAgenda computes reservation occupancy that way for any date, past or future, and lets it pass 100 per cent on purpose. Overbooking is surfaced, never blocked: a forward indicator on the coming days, a non-blocking warning when the booking is written, and an evening digest for the manager. The only hard block in the product is physical, and it is at the other end. A car cannot be checked in when the cars actually on site already equal capacity, because at that point there is genuinely nowhere to put it.

The second thing that changes is channel mix. A contract stay at zero commission sitting next to a reseller booking at 20 to 25 per cent changes what revenue by source actually means, and until the contracts are in the system that chart is a chart of your retail business only. Give the contract stays their own booking source so the mix stays honest.

An honest caveat on that last point: the booking source catalogue is managed by ParkAgenda rather than by you, so adding a Crew contract source is a request to us and not a setting you toggle in an afternoon. Better said here than discovered in week two.

The margin side of this is worked out in the number that tells you how far to overbook a car park.

The money side, and what ParkAgenda does not do

ParkAgenda does not bill your contract customers. There is no contract module, no recurring booking generator, no subscription billing for your end customers and no invoice issued to them. Stripe exists in the product to charge you for your own ParkAgenda licence, and for nothing else.

So the contract keeps being agreed, priced and invoiced the way it always was, in your accounting system or by your accountant. What changes is that the car is in the queue. That is the whole proposal, and it is smaller than a module and worth more than one.

There is one decision to make and to write down, because two reports read the same field. The amount on a contract stay. If you record zero, occupancy is correct and revenue per available space day understates by the whole contract fee. If you apportion the monthly fee across the stays you actually record, the revenue figures mean something again. Take the 95 EUR contract with five recorded stays in a month: 19 EUR a stay. Neither rule is wrong. Mixing them across parkings is, and it is what happens when nobody writes the rule down.

Getting a rota into the queue without typing it twice

There are three honest routes today and it is worth knowing which one you are being sold.

1. Counter entry. Works from day one, costs about a minute a stay, and needs somebody to actually do it. For 60 contracts turning over four times a month that is roughly four hours of typing.
2. A monthly CSV. Booking import is admin-only in ParkAgenda today, which in practice means our team runs it. The upsert is idempotent on the car park, the source and the reference number, so re-sending a corrected file updates the rows instead of duplicating them.
3. A push from your own roster system. There is no self-service API key and no partner API programme, so this is a project with a scope and a date rather than a switch in settings. Anyone who tells you otherwise has not looked at their own auth model.

And if crew already get in through a barrier and a plate reader, that kit is yours and it stays yours. ParkAgenda has no camera, no barrier control and no plate recognition. What it has is the plate as a field on the stay, so a read from your own system can be matched against a booking. Wiring that up is a connector our team builds with your supplier, and somebody local does the physical install.

The matching problem is not the reading problem, and the difference is set out in ANPR reads plates, it does not know who booked and in a barrier that opens on a plate is not a booking system.

Frequently asked

Do I have to create a booking every time a crew member parks?

Yes, in one of the three ways above. That is the cost of the proposal and it is worth being clear about it. The return is an occupancy number you can sell against on the Saturday of a half term, instead of a number that is quietly wrong by forty cars.

Does this mean I sell fewer spaces?

No. It means you stop selling against a number that was never true. On most days it goes the other way: a flat block is holding back more spaces than the contract base is using, and putting the stays in the queue hands those days back to you.

Can ParkAgenda invoice the contracts monthly?

No. There is no invoicing of your customers anywhere in the product, contract or retail, and no fiscal receipt. Keep that in the system you already use for it.

Pick one month and do the count. Every morning, write down how many contract cars are physically on site, and compare it with the block you have been holding back. If the gap is more than five spaces you have a pricing decision rather than a software problem. The features page shows how a stay is recorded, and the pricing page is worth opening in the next tab, because you will want to weigh one number against the other.