When Two Bookings Want the Same Person

Two bookings, same person, overlapping times. Someone notices at 21:40 and the next fifteen minutes are spent deciding which guest gets disappointed.

The post-mortem is always the same: who took the second booking?

That is the wrong question, and asking it is why the same thing happens again the following week.

Why it is not a mistake

The person who took the second booking did not know about the first. In most rooms, they could not have known — the first was in a message, or on a different sheet, or taken by someone whose shift had ended.

A double-booking is what happens when two people can both say yes to the same slot. That is a property of the system, not of the person.

⚠️ The test: could someone have checked? If checking means asking a colleague who may not be in the building, the answer is no, and the mistake is not theirs.

The three ways it actually happens

One — the request came in on a channel the schedule cannot see. A message to a member of staff, a phone call taken at the door, a regular who asked in person last week. Each is a promise, none is in the system.

Two — the booking was held but not committed. Somebody pencilled it in, meaning to confirm. To them it is taken; to everyone else the slot is open. Provisional states are where most of these come from, and every venue has one whether or not it is written down.

Three — the durations do not match reality. The system thinks a booking ends at 22:00 and the floor knows it runs to 22:30 with the return journey. If the schedule models less time than the night uses, it will keep producing overlaps that are technically legal and practically impossible.

The third is the least discussed and frequently the largest.

Which fix is worth making

Ranked by how much they change, not by how easy they are.

Make one place the answer. Not "the main system" — the only one. If a booking can also exist in a message thread, you have two systems and the overlap will come back. This means the door and the phone have to reach the same record while the guest is still on the line, which is the real requirement behind it.

Make the provisional state real. Either a held slot blocks the calendar or it does not exist. A hold that other people cannot see is not a hold; it is a private intention.

Model the true duration. Including travel, turnaround, the fifteen minutes that always happen. If the schedule is optimistic, every fix above it fails.

Then, and only then, add a warning on entry. A conflict check is worth building only once the three above are true — otherwise it fires on phantom conflicts, gets ignored within a fortnight, and joins the pile of alerts nobody reads.

The one that has to be decided in advance

Sometimes it happens anyway. The question of who gets the slot should not be answered at 21:40 by whoever is nearest.

Decide the rule once, in daylight: the earlier booking, or the confirmed one over the provisional, or the one already travelling. Any of these is defensible; deciding in the moment is not, because it will be decided differently each time and both guests will eventually hear about it.

⚠️ Whichever rule you pick, the losing guest is a retention event. How that call is made — how early, by whom, and what is offered — matters more to whether they come back than the conflict itself did.

The number that tells you if it is getting better

Not double-bookings resolved. Double-bookings created, and how far in advance they were caught.

A conflict caught on Tuesday for Saturday costs a phone call. The same conflict caught at 21:40 costs a guest. Same event, different cost, and only the timing distinguishes them — which makes lead time the number worth watching.

Three to hold

Conflicts created per month. The system's error rate, not the floor's.

Median lead time to detection. Tuesday or 21:40.

Share of bookings that entered through a channel outside the schedule. The upstream cause, and usually the only one worth fixing.

Where the record has to sit

If a request can be made to a person rather than to the schedule, the schedule cannot prevent a conflict — it can only report one afterwards. That is the whole mechanism.

tasteck keeps requests, holds, and confirmed bookings on one schedule with real durations, so a slot that is taken reads as taken to whoever is looking, including the person on the phone at the door.

Nobody double-booked anybody. The system allowed a state the night could not deliver.