Why double-booking happens
Ask anyone who has been in rental for a season and they will tell you about the Saturday two events wanted the same 200 chairs. The story is always the same in shape: someone checked, someone said yes, and the check was wrong.
It is worth being precise about why, because the usual conclusion - “we need to be more careful” - is the one fix that reliably does not work. There are four separate failures hiding under the same symptom:
- The count was right, but stale. The spreadsheet said 200 free. It was accurate on Tuesday. The booking that took them was made on Wednesday, by someone who has not saved their copy yet.
- The count was right, but for the wrong dates. Stock is not free or unavailable; it is free for a window. A tally that has one number per item cannot answer a question about a date range.
- The count ignored the turnaround. The linens come back Sunday night, so they are marked available Monday - except they are in a laundry bag, and they will not be foldable until Wednesday.
- The count included stock that cannot go out. Twelve of the forty chairs have a broken leg and are stacked at the back waiting for a repair. They are still in the total.
Only the first of those is a discipline problem. The other three are arithmetic that no amount of care will fix, because the record was never capable of producing the right answer.
Rule one: availability is derived, never stored
This is the single change that removes most double-bookings, and it is worth stating plainly: do not keep a number called “available”.
The moment availability is a figure somebody maintains, it has to be updated by hand every time a booking is made, changed, cancelled or returned. Each of those is a chance to forget. And a stored figure gives you no way to tell the difference between “this is correct” and “this has not been touched in a fortnight” - they look identical.
Instead, calculate it every time it is asked for, from the bookings that created it:
available for a window = serviceable stock − everything committed during that window
Derived availability cannot drift, because there is nothing to drift from. If a booking exists, its claim is counted. If it is cancelled, the claim is gone the next time anybody asks. Nobody has to remember to do anything, which is the only kind of process that survives a busy season.
Rule two: book windows, not days
A rental is not a date. It is a period during which you do not have the stock, and that period is always longer than the event.
Break a booking into the four moments that actually matter:
- Out - the day the stock physically leaves. For a marquee this may be three days before the first guest arrives.
- Event - what the customer cares about, and the only one of the four most systems record.
- Due back - the day it returns to you.
- Ready again - the day it can go out to somebody else, which is the due-back date plus turnaround.
Availability has to be blocked from out to ready again. Most double-bookings that survive a move to proper software are caused by systems that block only the event date, which is the shortest and least useful of the four.
The practical test: if your record cannot tell you what is committed on a Wednesday when no event is happening, it is not modelling the window.
Rule three: turnaround belongs to the item
Turnaround is the number of days an item needs between coming back and being fit to go out again. It is not a general policy; it varies enormously by what the thing is.
- Stacking chairs: wipe down, same day.
- Table linens: wash, dry, press, fold - two or three days.
- Marquee lining: inspect for tears, launder, re-roll - often a week in a busy month.
- Generators: refuel, service check, test run.
When turnaround lives in someone’s head, it gets applied to whichever items that person happens to think of. When it is a property of the item - set once, when the item is created - it gets applied to every booking automatically and identically, including the ones taken by the person who started last week.
Set it honestly. A turnaround set optimistically to win one booking costs you the next one, because the stock genuinely will not be ready and you will be the one explaining it.
Rule four: promise serviceable stock, not owned stock
The number of chairs you own and the number you can rent out are different numbers, and the gap between them is where a surprising share of double-bookings live.
Owned stock includes everything you have ever bought and not thrown away. Serviceable stock is what is left after you take out:
- Damaged - broken, stained, unfit to send to a customer.
- In maintenance - currently being repaired, cleaned or serviced. Coming back, but not today.
- Missing - unaccounted for after a return. Not damaged, not retired; simply not there.
- Retired - written off, still on the books for history but never going out again.
Keeping these as separate pools rather than as one vague “unavailable” bucket matters for two reasons. It keeps the availability figure honest, and it tells you something useful when you look back: a line of stock that is constantly in maintenance is a purchasing decision, and one that is constantly missing is a process problem at the loading bay.
When you should overbook on purpose
None of this means the system should refuse outright. Sometimes you take the booking anyway - you know a sub-hire is available, or the customer has agreed to fewer chairs, or the returning event has always come back early.
That is a legitimate business decision, and the software should let you make it. What it must not do is let you make it accidentally. The distinction is the whole point:
- An overbooking you chose is flagged, recorded, and visible to whoever is loading the van on the day.
- An overbooking you did not notice is discovered at 6am by a driver, and it is the customer who finds out first.
So: warn loudly, allow the override, and then keep showing it. Anything that is overbooked should stay visible on a list somebody reads every morning, alongside every booking contending for the same units - because fixing it means deciding whose order gets cut, and you cannot make that decision without seeing all the claims side by side.
A checklist you can run this week
You do not need new software to get most of the way here. You need the record to be able to answer the right question. Work through these in order:
- Write down your real turnaround per item type. Ask the person who does the washing, not the person who does the quoting.
- Split your totals into pools. For each item: owned, damaged, in maintenance, missing. The serviceable figure is what is left, and it is usually smaller than people expect.
- Record out and due-back dates, not event dates. Go back through the next two months of bookings and add them.
- Stop maintaining an availability column. Work it out when asked. If that is too slow to do by hand, that is the signal that the tool needs to change - not the signal to go back to a stored number.
- Make overbookings visible every morning. One list, read before anything is loaded.
The pattern behind all five is the same. Double-booking is not a failure of attention; it is a record that was never able to answer the question being asked of it. Change the record and the problem largely stops happening on its own.
How Event Managr models rental inventory covers the pools and the seven figures they reconcile into, and the full rental cycle walks from booking through to return.
