Picture a dental clinic. Patients book in three ways: the online booking form on the website, the reception phone and WhatsApp. On Tuesday afternoon two patients are at the door at the same time, both holding a confirmed appointment for 2 pm. One booked on the website two days earlier, the other by phone that morning. Reception apologises, one patient waits, and the dentist runs half an hour late for the rest of the day.
When it happens again the following week, someone says "the system is broken". Yet most double bookings come not from software failing to apply a rule but from the rule never being defined. Clinic, hair salon, car service, consultancy or gym, it makes no difference: the eight questions below close the usual routes by which two people end up in the same slot.
1. Can two people pick the last free slot at the same moment?
This is the most technical cause and the one most often skipped. Two visitors open the calendar within the same few seconds, both see 2 pm as free, both press "Confirm". The system checks whether the slot is free before saving, but if the other booking slips through in the short gap between checking and saving, two confirmations go out.
The fix is to run the check where the booking is saved, not on the screen. The database should refuse a second record for the same resource and the same start time, and the second person should see a clear message: "this slot was just taken, these times are free". A simplified sketch:
UNIQUE (resource_id, start_time) -- same resource, same time: one record
If appointments can have different lengths, a single uniqueness rule is not enough; you need a structure that checks overlapping time ranges by locking them while the booking is saved. Whichever you choose, the rule belongs on the server, not in the browser.
2. Whose slot is it while the form is being filled in?
The patient picks a time, then types their name and phone number, perhaps pays a deposit. For those two or three minutes, whose slot is it? If the answer is undefined, either the slot stays open and someone else takes it, or abandoned forms fill the calendar for no reason.
The common method is a temporary hold: the moment a slot is picked it is set aside for that person for a short time, the remaining time shows on screen, and if the booking is not completed the slot frees itself. How many minutes is the business's decision; what matters is that there is a limit and that the record is actually removed when it runs out.
3. How long does the appointment really take?
The calendar is built in half-hour slots, but not every service takes half an hour. A root canal takes an hour and a half, a paint protection job takes all day, a first examination is longer than a follow-up. If the system counts every appointment as one slot, the hours during a long service look free and get sold.
Define the real length of each type of service and, where needed, the preparation time behind it (cleaning, sterilisation, getting the car onto the lift). The customer picks only the start time; the system reads the length from the service and blocks the whole range.
4. Is the calendar tied to a person or to a resource?
The dentist is free at 2 pm, but the X-ray machine or the only treatment room is taken. At the salon the stylist is free, but the colouring chair is taken. If the calendar is built only around staff, the clash happens with a room or a device, not a person.
List which resources each appointment uses together: staff member, room, device, vehicle. If you have few resources the list stays short, but until it is written down the system cannot know it. A slot should be bookable only when every resource it needs is free at the same time.
5. When does a phone booking reach the system?
When reception is busy, a phone booking goes onto a piece of paper or into a notebook and gets entered "in a minute". For those few minutes, or few hours, the website shows the same slot as free.
The rule is simple but takes discipline: a booking taken by phone or message is entered into the system before the customer is told "done". Making that easy is the software's job: the reception screen should show free slots on a single screen and take the booking in a few clicks. If entry is tedious, the notebook comes back.
6. How often, and in which direction, does it sync with outside calendars?
Staff like to check the calendar on their own phones, which is why people ask for the system to sync with Google or Outlook calendars. The issue is whether that sync is one-way or two-way and how much delay it runs with. A staff member writes "out this afternoon" in their personal calendar; if that reaches the booking system an hour later, those hours can be sold in the meantime.
Decide which calendar is the source of truth. For most businesses the right answer is that the booking system is the source and personal calendars sync for reading only. Leave and closed hours are entered in the booking system too, not in a personal calendar.
7. Are holidays, half days and time zones defined?
If public holidays, half-day hours on the eve of a holiday, a technician's annual leave or extended hours before a festival are not entered in advance, the system sells those days as ordinary working days. If some customers book from abroad, state clearly which time zone the times are shown in; if the server's clock and the business's clock differ, that difference should be handled in one place only.
Entering the year's holiday list once at the start of the year and keeping a separate screen for closed days prevents most of these errors.
8. If a clash still happens, who notices, and how?
However good the rules, a manual change or a sync delay can still create a clash. What matters is seeing it the day before, not when the patient walks in.
A simple daily check helps: if tomorrow's calendar has overlapping records for the same resource, the person in charge gets a warning in the morning. A reminder message also makes it easy for the customer to confirm or cancel, and a freed slot goes back on sale.
In short
Two people landing in the same slot usually comes not from "broken" software but from undefined rules. Run the check where the booking is saved, hold a picked slot for a short time, define each service's real length and the resources it uses, enter phone bookings into the system first, decide which calendar is the source of truth, enter holidays in advance and have tomorrow's calendar checked every morning.
In custom software projects that include an appointment or booking flow, we write these rules down on one page with the business before coding, and the software then applies that page.
Planning a project like this?
Plan it in 10 steps