The number that tells you how far to overbook a car park

Most operators size their overbooking margin from the no-show rate. It is the wrong number, and in a school holiday week it will tell you to sell more at the exact moment you should be selling less.

A no-show removes a car that was never going to arrive. It gives you back a space for the whole of a stay, and it gives it back on a Tuesday afternoon as readily as on a Saturday morning. The event that actually turns a paying customer away is a different one. A car booked to leave last night is still in its space when the car that bought that space pulls up at half past four.

A no-show and an overrun are not two sides of the same coin

A no-show removes demand. An overrun removes supply, at a named hour, on a named day. Only one of them leaves you standing at the entrance with nowhere to put a car.

The two get confused because both appear as a gap between what you sold and what happened. On a spreadsheet they look symmetrical. On the ground they are not. A no-show at two in the afternoon hands you a space for six days. An overrun of ninety minutes costs you nothing at all, unless it lands inside your arrival wave. Then it costs you a refusal, a phone call, and a customer who tells people your car park was full after they had paid.

The refusal happens in one hour and you already know which one

Off airport car parks fill early in the morning and empty at night. Almost nothing leaves at five, because nobody's return flight lands then. The spaces your 05:00 arrivals need were vacated the previous evening, between seven and half past midnight, by people collecting their cars after a return flight.

That is the whole dependency. Your biggest arrival band is funded by last night's collection band. If the collection band under-delivers, the arrival band pays for it, and it pays inside ninety minutes.

You have to watch it happen once. Twenty past four, the shuttle is out, reception has a queue of six, and the row you were going to use still has cars on it. Nobody on the team is doing anything wrong. The plan was built from a daily total, and a day never arrives as a total.

Two columns and one histogram

You need the booked departure and the actual check-out for every completed stay. The gap between them is the overrun, and its distribution is the input you have been missing.

Take one peak week from last year and export it. Subtract the booked departure from the actual check-out, row by row. Keep the sign, because a car that leaves two hours early is real capacity and it should be counted. Then ignore the average. The average is dominated by the people who left on time, and they were never the problem. The number you want is the share of an evening collection band that is still on site the next morning, at the hour your arrivals start.

In ParkAgenda both columns come out of the same export. The bookings export and the analytics raw data export each carry the booked dates, the real check-in and check-out times, and the booking source on every row.

A worked example

These numbers are an example, not a customer. Take a 400 space car park in July, on a Saturday.

• 168 arrivals across the day, 46 of them between 04:30 and 06:00. That band is the constraint.
• 58 cars were booked to be collected the evening before, between 19:00 and 00:30.
• From last July's export of 1,180 completed stays, half the collections happened within twenty minutes of the booked time, three quarters inside an hour and ten, and 6 per cent of an evening band was still on site the following morning.

Six per cent of 58 is three and a half cars, so call it four. At 04:30 the board says 334 cars are on site against 400 spaces. That is 66 free spaces for 46 arrivals, and fifteen minutes of nerves rather than a refusal. Had you assumed all 58 collections happened, you would have planned on 70. The tail took four.

Twenty spaces of headroom. That is the margin, and it is a count of cars in one band on one morning.

Now run it the other way. A 3 per cent no-show rate on 376 overlapping stays gives you eleven extra bookings you feel safe selling. Where do they land? Across the whole arrival profile, in proportion to it. The pinch band holds 27 per cent of the day's arrivals, so three of those eleven land where the constraint actually is. The real headroom was twenty. The no-show method sized eleven and delivered three of them to the right hour.

The argument fits in one line. The margin is a count of spaces in a band. The no-show rate is a percentage of a book. They are not the same kind of number and one does not convert into the other.

School holidays move both numbers, in opposite directions

In a school holiday week the no-show rate falls, because a family that has paid for a week away turns up. The overrun tail usually thickens in the same week. Charters run later, return flights slip, and more people ask for an extra day while they are still in the air.

Test that on your own rows before you act on it. Run the same histogram twice, once on a holiday week and once on a week in March, and compare the right hand tail rather than the middle. If your tail is fatter in August, the period where the no-show rate is loudest about selling more is the period where it is least safe to listen. There is more on how a peak week behaves in what actually changes in a car park during peak weeks.

Split the tail by booking source

Run the histogram once per booking source. Your own bookings and a reseller's book do not overrun the same way, and every exported row already carries its source, so the split costs you one pivot.

This matters past capacity. If one channel's collections run consistently late into your morning wave, that channel is quietly eating spaces you could have sold twice, and its commission is worth less than the rate on the contract suggests. The channel mix arithmetic goes through that properly, and the unit economics of an off airport car park puts a figure on what one space earns on a peak morning.

What ParkAgenda does here, and what it does not

ParkAgenda does not overbook for you. There is no yield engine, no rate plan, no tariff grid and no recommendation. The arithmetic above is yours to do.

What it gives you is the inputs, plus warnings that never block a sale.

• Reservation occupancy for any date, past or future, computed from stay windows against capacity. It is allowed to read above 100 per cent, on purpose.
• A forward indicator for the coming days, a non-blocking warning when you write a booking into a day that is already over capacity, and an opt-in digest sent at 20:00 the evening before in the parking's own timezone.
• Hourly arrival buckets and a peak day, so you can find your pinch band without building it by hand.
• Booking pace: how many bookings are on the books for a future arrival day, against the same lead day last year.
• Exports of the raw rows, so the histogram is a spreadsheet job rather than a support ticket.

One thing does block, and it is the right one. A car cannot be checked in when the number of cars already checked in equals capacity. Reservation occupancy is a plan and it is allowed to exceed 100 per cent. Cars on site is a fact and it is not.

Pricing Trends in the analytics view is a lookback. Average booking price, average daily rate and RevPASD over a period you choose. It is not a forecast and it does not set a price.

Questions operators ask

Is the no-show rate useless then?

No. It tells you about your channel mix and your deposit policy, and it belongs in your revenue reporting. It does not size an overbooking margin, because it is not measured at the hour where the constraint bites.

How much history do I need before this works?

One equivalent period. Last July for this July. A single peak week carries enough rows to show the shape of the tail, and the shape is the whole point.

We have never overbooked. Is this still relevant?

It is the cheapest way to find out whether you should. Count the free spaces during your busiest arrival hour across a full peak week. If the answer is twenty every morning, you have been running a car park that was never full and charging as though it was.

Next step: export one peak week from last year, keep the booked departure and the actual check-out, and count how many cars were still on site at your busiest arrival hour. If you want to see where those exports and the occupancy view sit in the product, the features page is the short version.