The two questions a booking system must answer
Everything in this article reduces to two questions:
1. Is this unit free for this interval? — an overlap test against every other booking and every maintenance block for that unit.
2. Is it still free at the moment I commit? — the same test, repeated at the instant of writing, not at the instant of asking.
Manual processes answer the first and skip the second. That gap — sometimes thirty seconds, sometimes three days while a customer "thinks about it" — is where almost every collision is born.
Why stored availability always drifts
A surprising number of small operators keep an availability list: a whiteboard, a sheet with green and red cells, a "free units" tab. It is intuitive and it is always, eventually, wrong, because it requires a human to update a second place after every single change.
Consider what has to happen for a stored list to stay correct:
| Event | What must be updated |
|---|---|
| New booking | booking record + availability list |
| Booking cancelled | booking record + availability list |
| Dates changed | booking record + both old and new availability cells |
| Unit off the road for service | maintenance record + availability list |
| Late return pushing into the next slot | return record + availability list + next booking |
Five events, ten updates, and every missed one is invisible until a customer is standing in the yard. Calculated availability has one source of truth and cannot drift: if a booking exists, the interval is not free, full stop. This is one of the reasons a manual booking sheet gets harder as the fleet grows — see Running a Rental Business on a Spreadsheet.
The rule to write on the wall: bookings and blocks are data; availability is a view of that data.
Where the check belongs
If you take anything from this article, take this: the collision check must sit at the point where two simultaneous attempts actually meet.
| Layer | What it catches | What it misses |
|---|---|---|
| The person's eyes | obvious clashes | anything under time pressure, anything on a second screen |
| The user interface | a slot already shown as taken | a booking made one second earlier by someone else |
| Application logic | most conflicts | two requests processed at the same instant |
| The database | everything | nothing — it is the only serialised point |
A user-interface check is a courtesy: it stops the customer from wasting their time. It is not a guarantee. The guarantee has to be a constraint at the storage layer that simply refuses to write a second overlapping row for the same unit. Everything above it is user experience.
This matters most in exactly the situations you want to encourage: a website booking form running at the same time as a phone call, or two staff on two devices at a busy Friday counter.
Overlap, precisely
Two intervals overlap if one starts before the other ends *and* ends after the other starts. The two edge cases that catch people out:
- Touching intervals. A rental ending at 10:00 and another starting at 10:00 do not mathematically overlap. Operationally they collide, because the unit has to be checked, cleaned and handed over. Decide explicitly whether the boundary is closed or open, and make sure everyone means the same thing by "until Friday".
- Whole-day bookings. If you rent by the day, "3rd to 5th" may mean three days or two, depending on whether the end date is inclusive. Pick one, write it in your terms, and make your calendar display it the same way.
Buffer time: the fix that costs nothing
Most "double bookings" are not overlaps at all. They are two bookings that are legally adjacent and physically impossible: a trailer returned at 16:00 covered in mud, promised to someone else at 16:15.
A buffer is a fixed gap the system reserves after every rental, and it should reflect what the unit actually needs:
| Unit type | Realistic turnaround | Notes |
|---|---|---|
| Small unbraked trailer | 15–30 minutes | visual check, lights test, sweep out |
| Large or tipping trailer | 30–60 minutes | wash-down, load-securing gear, tyres |
| Van or car | 45–90 minutes | fuel, clean, mileage, damage walkaround |
| Machine with an hour meter | 60 minutes plus | hour reading, fuel, greasing, service due check |
| Campervan or motorhome | 2–4 hours | interior clean, waste tanks, gas, full inventory |
Set the buffer once per unit type and stop thinking about it. It is the single cheapest reduction in stress you can make, and it also absorbs the small late returns that would otherwise cascade — the larger version of that problem is covered in When a Customer Returns Rental Equipment Late.
The holding problem
"I'll pencil you in and you can confirm tomorrow" is a booking with no record and no expiry. It is the second-largest source of collisions after eye-checking.
Two workable patterns:
- A hold with a deadline. The slot is genuinely reserved, but it expires automatically — a short window for online payment, or a day or two for a phone enquiry you agree to hold. What matters is that expiry is automatic, not a note to yourself.
- No hold at all. Nothing is reserved until it is booked, and you say so plainly: "I can't hold it, but it's free right now if you'd like it." Customers accept this far better than being told later that the pencil mark did not survive.
What does not work is the informal hold with no expiry. It occupies the calendar in one person's head and nowhere else.
Rules for the counter
Even with the right system underneath, five habits keep the last few percent out:
1. Write it down before you say yes. The sentence "you're booked" comes after the record exists, never before.
2. One booking channel of record. Phone, email and web enquiries all end up in the same place immediately, not in a notebook to be transferred later.
3. Never confirm from memory. Not even for the unit you are sure is free.
4. Change dates, don't recreate bookings. Cancel-and-rebook briefly frees a slot that someone else can take in that window.
5. Check tomorrow, today. A two-minute look at the next day's collections and returns catches almost every remaining surprise.
When it happens anyway
It will, occasionally. What separates a bad hour from a lost customer is having a script rather than an improvisation.
1. Find out first. The day-before check is what gives you hours instead of a confrontation in the yard.
2. Call, don't email. Whoever booked second, unless one of them has an obviously more flexible job.
3. Offer a concrete alternative in the same sentence as the apology. A larger unit at the same price, a different day with a discount, or a competitor you trust. Never present the problem without an option.
4. Absorb the cost visibly. A free upgrade costs a fraction of the review.
5. Record what caused it. Booking made by phone during a busy hour, dates changed without checking, buffer too short. Three entries in that log will tell you exactly which process to change.
Where Flotello fits
In Flotello, availability is never stored — it is calculated from bookings and blocks whenever it is displayed — and the final overlap check lives in the database, so two people (or a website booking and a phone call) cannot claim the same unit even in the same second. Operators can override their own rules on length or notice with a logged confirmation, but a genuine collision is refused for everyone. You can try it on your own fleet with a seven-day trial.