In this guide 6 sections
A booking app stops double booking by treating each slot as a record that one request can claim at a time, never two. It checks the roster, the room or bay and the remaining seats, locks the slot while payment completes, then confirms or releases it. Buffers and cancellation rules sit around it.
A slot is a claim on staff, space and seats
A booking looks like a single tick. Underneath, it claims up to three things at once: a person, a place and a number of seats, each of which can run out independently. A dental visit needs a dentist and a chair, while a yoga class needs a teacher and a mat count inside a hall.
Each lives in its own record. The dentist has a weekly roster with leave days, the chair has opening hours, and the hall has a fixed capacity of, say, twelve mats. A closed hall removes its slots.
A slot appears only when every record it needs is free, so a rostered teacher with a hall closed for floor polishing produces no slot at all.
- Staff roster with shifts, breaks and leave
- Resource record for each room, bay or chair
- Seat count for group sessions
- Service length, set per treatment or class type
How double booking is actually prevented
Two customers tap one slot. A screen that checks first and saves afterwards lets both through, since each check sees an empty slot and neither can see the other request. Check and claim must happen together. One database transaction does that. Nothing else is safe.
The usual method is a row lock or a unique constraint on staff, resource and start time, so the database itself refuses a second row for the same combination. The first request wins. The loser sees the next free time.
Capacity works the same way with a counter, where seats remaining drops by the party size and the write is rejected whenever it would take the count below zero.
Buffers, hold timers and payment
A buffer is hidden time. Customers never see it. A car service bay needs fifteen minutes after each job to clear tools, and a salon chair needs time to swap towels. The app adds the gap to the slot length, which stops the next customer from starting before the bay is clear or the chair is reset.
Payment adds a wait. When someone reaches the payment page, the app places a temporary hold, often for around ten minutes, and shows a countdown beside the slot. Success turns it into a confirmed booking.
On failure or silence, a background job releases the hold, and skipping that job lets abandoned carts quietly fill your diary with unpaid bookings that block real customers. That job is not optional.
- Buffer before and after each service
- Hold length and what happens on expiry
- Gateway callback that confirms the payment
- Retry rule when the callback arrives late
Cancellations, reschedules and the front desk view
A cancellation frees the claim and may trigger a refund or a credit, depending on how close it is to the start time. Build a reschedule as one step. Claim the new slot first, then release the old one, because done the other way round a failed move leaves the customer with nothing.
Your front desk needs one live day view, with a column per staff member or room and a colour for each status, such as booked, arrived or no show. Walk-ins go into the same grid. Online rules apply to them too.
Reminders cut no shows. Each reply can feed back into the schedule, so a customer who answers cancel frees the slot for the waiting list without a call from the desk.
Rules to write down before any build
Most booking bugs are unwritten policies. Does a parent stay free? Can one customer book two services back to back with different staff members, and who may override a full class without leaving a note?
Settle these on paper first. Write the answers down. A developer can encode a clear rule in a day, but an unclear one gets rebuilt three times before anyone is happy with it.
Start with one service and one room, run it for a fortnight, and list every manual fix the front desk made along the way. That list is your next sprint.
Booking rules worksheet
Services run down the left side. Columns cover duration, buffer before, buffer after, staff allowed, room or bay needed, maximum seats, hold time at payment, cancellation cutoff, refund or credit rule and who may override. A second block covers walk-in, no show and late arrival rules, so the front desk applies one policy to every case that comes through the door.
Open a blank worksheet to printQuestions owners ask
What happens if two people book the same slot at once?
The database accepts the first write and rejects the second, and the second person sees a message with the nearest free times. It works only when the check and the claim happen together as one atomic step, not as two separate steps with a gap between them.
How long should a slot be held during payment?
Long enough to finish a card or wallet step, yet short enough that abandoned carts do not block real customers for the afternoon. Around ten minutes is common. Show a visible countdown beside the slot, and let a background job release it the moment the timer expires, with no human step needed.
Can one app handle staff, rooms and group classes together?
Yes. Each is a record with its own availability, so a class claims a teacher, a hall and a seat count, while an appointment claims a person and a room.
Do buffers show to the customer?
Customers see the service length and the next open start time, while the buffer is added behind the scenes so back to back bookings leave staff time to reset.