Short answer. Slots are stored nowhere: they are computed on request from the practitioner's hours minus breaks, blocked days, taken appointments, holds in progress and buffers, then sliced by the service duration. Booking is a transaction that locks the slot's row and creates a ten-minute hold; the second request, whether from the site, the app, the WhatsApp agent or the counter, gets a clean refusal and alternatives, because every channel goes through the same path. The deposit or confirmation turns the hold into a booking; without it, it expires and the slot becomes free again. WhatsApp reminders the day before and two hours before, with a one-word reply, and a waitlist notified when a slot frees up, lower no-shows. Times are stored in Algiers time, fixed all year, and shown in the customer's time zone. Six weeks, the first without code.
This guide is for the manager of a practice, a salon, a centre or a workshop that takes appointments by phone, WhatsApp and website at once, the founder settled in France whose customers book from two time zones, and the person who sees one slot in four lost to no-shows. It does not repeat what a salon, a dental practice or a thermal spa expect from a booking application, described in the beauty salon guide, the dental practice guide and the thermal spa guide; it describes what gets built under all those trades so that a slot exists only once, and it extends our software engineering page.
Two customers, one slot, one booking
The figure follows two requests for the same 14:30 slot, 220 milliseconds apart: Amel from the app in Algiers, Karim through the WhatsApp agent from Paris. Both screens showed “available”. The server decides.
Amel's request opens a transaction, locks the slot's row, checks it is free and creates a hold that expires at 10:10; the transaction ends in a few milliseconds. Karim's request lands 220 milliseconds later on a held slot: clean refusal, and two alternatives, 15:00 or the waitlist. At 10:04, Amel's deposit is confirmed by the payment provider's webhook, following the online payment guide, and the hold becomes a confirmed booking; messages go out. Karim chooses the waitlist and will be notified if 14:30 frees up.
Had Amel not paid, the hold would have expired at 10:10 and the slot would have become free again, with no intervention. It is the same mechanics as the stock reservation described in the stock guide: a quantity, here a slot, that is not sold twice because the database refuses it inside a transaction, not because the screen displayed it. Times in the figure are a constructed example.
«Two requests 220 milliseconds apart do not both go through: the database decides, inside a transaction, not the screen that still showed “available”.»
From request to kept appointment, in six steps
What happens to an appointment, in order, and when each decision is taken.
Show the slots, computed from availability and shown in the customer's time zone. Hold the slot: transaction, lock, ten-minute hold, clean refusal if taken; this is the accented step, the only one that writes concurrently. Confirm by online deposit or in one gesture; the hold becomes a booking. Remind by WhatsApp the day before and two hours before, with a one-word reply, yes, move or cancel, following the template and window rules described in the WhatsApp agent guide.
Keep or release: arrival is checked in, the no-show recorded on the customer record, and a cancelled slot is released with the waitlist notified. Measure: no-show rate, mean lead time between booking and appointment, fill rate per practitioner, on the manager's dashboard following the real-time dashboard guide.
A booking system, in five layers
The lock is the layer that prevents double booking; the four others make sure slots are right, appointments are kept, and the manager knows.
Availability. Hours per practitioner or resource, breaks, blocked days, duration per service, buffer between appointments, capacity when several customers share a slot; written by the manager in the application, in Algiers time. Slot engine. Visible slots are computed on request by removing from the hours everything taken, then slicing by the service duration; nothing is stored in advance, so changing hours breaks nothing. Booking and lock. One transaction per request, a ten-minute hold with expiry, a clean refusal if the slot is taken, alternatives and a waitlist; this is the accented layer, and it must be unique: the app, the site, the WhatsApp agent and the counter go through the same path.
Confirmation and payment. Online deposit or one-gesture confirmation, cancellation under written rules, slot released and waitlist notified. Reminders and measurement. Reminders with reply, check-in on arrival, no-shows recorded, no-show and fill rate per practitioner; channel choice follows the notifications guide. The customer is the same from one channel to another, following the customer file guide: that is what makes counting no-shows per person possible.
Where slots come from: one week, layer by layer
The figure shows one practitioner's week and how the slots a customer sees are produced: by subtraction, then by slicing.
The background is the opening hours; you remove the break, Thursday afternoon blocked for training, Saturday afternoon closed, appointments already taken, the Tuesday 11:00 hold in progress that expires in six minutes, and the ten-minute buffers after each appointment. What remains is sliced into thirty-minute slots, the duration of the chosen service; a one-hour service would produce fewer slots from the same gaps. The computation is done on request, in Algiers time.
Display is done in the customer's time zone. Algeria stays at UTC+1 all year and has no summer time; France moves to UTC+2 from late March to late October. A 14:30 slot in Algiers therefore shows as 15:30 in Paris in summer and 14:30 in winter, and the note “Algiers time” appears on the confirmation and the reminder. Times in the figure are a constructed example.
«Slots are stored nowhere: they are computed on request, in Algiers time, and shown in the customer's time zone.»
Six real situations, and what the application does
The six situations found in almost every appointment system we take over, and the construction that settles them.
The first two rows are settled by the transaction and the expiring hold; the third by storage in Algiers time and display in the customer's zone; the fourth by reminders with reply, the deposit where it is accepted, and the waitlist that fills the released slot; the last two by a single engine that computes on request and that every channel uses, including the employee at the counter. None is settled by a more attentive receptionist.
Seen elsewhere: consumer online diaries, and what carries over
Consumer online booking diaries, for salons, doctors or restaurants, share three mechanisms that carry over as they are into a custom application. The short hold: the slot is blocked for a few minutes while the customer confirms, then released; what carries over is a hold with expiry, never a firm booking before confirmation. The reminder with reply: a message the day before that the customer answers in one word; what carries over is a reply that updates the appointment, not a message sent and forgotten. The waitlist: when a slot frees up, waiting customers are notified in order; what carries over is automatic filling of cancellations.
What those diaries do not decide for you: your service durations, your buffers, your hold duration, deposit or not, and your cancellation rules; the project's first week answers that. Market diaries remain the right choice when your rules fit theirs; custom starts when the appointment must talk to the customer record, stock, the till and the WhatsApp agent in the same application, or when the booking covers combined resources, a cabin and a therapist, a car and a driver, as in the car rental guide.
The rules of a slot that exists only once
Six rules, written in the first week. Slots are computed, never stored. Booking is a transaction that locks the slot. A hold lasts ten minutes and expires without confirmation. Every channel goes through the same path, the counter included. Times are stored in Algiers time and shown in the customer's time zone. Every appointment is reminded with a reply, and every no-show is recorded on the customer record.
And one rule of method: the existing diary is taken over as dated, signed appointments, not as a copied calendar; duplicates show up at the first slot computation, and the manager settles them.
Six companies, and the booking rule that was missing
Six situations composed from projects we meet; the names are generic and the figures are examples.
- A dental practice in Algiers, three chairs. Two patients at 14:30 once a week, one via the site, the other by phone. The construction: a single slot engine, the counter booking through the same transaction, ten-minute hold. Duplicates stopped in the first week; the trade case is described in the dental practice guide.
- A beauty salon in Oran, five stylists. One appointment in four did not show. The construction: WhatsApp reminder the day before and two hours before with a one-word reply, deposit on long services, waitlist notified. The no-show rate is measured per stylist since; the case is close to the beauty salon guide.
- A founder in Lyon, care centre in Algiers for the diaspora. Customers from France arrived an hour late in summer. The construction: times stored in Algiers time, shown in the customer's zone with the note, reminder in the customer's zone.
- A gym in Constantine, group classes. Twenty places per class, thirty signed up some evenings. The construction: capacity per slot, transaction that counts places, waitlist; the case is described in the gym guide.
- A garage in Sétif, two lifts. Appointments were taken for the garage, not for a lift, and two cars waited. The construction: booking per resource, duration per intervention type, fifteen-minute buffer between two cars.
- A thermal spa in Hammam Righa, combined treatments. A cure books a cabin and a therapist at the same time. The construction: combined-resource booking in a single transaction, one without the other being refused; the case is described in the thermal spa guide.
The 2027 calendar
Six weeks for a company that already takes appointments; the first week passes without code.
Week 1, rules: duration per service, buffers, hours per practitioner, hold duration, deposit or not, cancellation rules, reminder texts in both languages following the bilingual application guide; signed by the manager. Week 2, availability and engine: hours, breaks and blocks entered in the application, slot engine computed on request, display in the customer's time zone. Week 3, booking and lock: transaction per slot, hold with expiry, refusal and alternatives, waitlist, same path for every channel.
Week 4, confirmation and payment: online deposit or one-gesture confirmation, cancellation and release, practitioner's diary. Week 5, reminders and counter: WhatsApp reminders with reply, check-in on arrival, booking at the counter and through the WhatsApp agent. Week 6, measurement: no-show rate, fill rate per practitioner, mean booking lead time, first monthly review. Every week ends with a demo, following the delivery without breakage guide.
What makes a booking system fail
Five causes, seen in applications we take over. Slots stored in advance: changing hours breaks the week. Two paths to book: the site and the counter cannot see each other. The hold without expiry: an abandoned basket blocks the slot all day. The reminder without reply: you send, you do not know, the customer does not come. Time without a zone: the customer from France arrives an hour too early or too late.
And one cause of method: leaving service durations and buffers “to adjust later”. They condition every displayed slot; the first week exists to write them.
Frequently asked questions
The questions managers and founders ask when they describe a diary that overflows.
- How do you prevent double booking of a slot?
- By making the booking a database transaction: it locks the slot's row, checks it is free and creates a ten-minute hold; the second request gets a clean refusal and alternatives. Every channel, site, app, WhatsApp agent and counter, goes through the same path. The screen may show a slot a few seconds stale; the database may not.
- Why are slots not stored in advance?
- Because they depend on rules that change: hours, breaks, blocked days, service duration, buffers. Computed on request, they are always right, and changing hours breaks nothing; the application only lists the appointments already taken that conflict, so the manager can settle them.
- What is the ten-minute hold for?
- To block the slot while the customer confirms or pays the deposit, without an abandoned basket blocking it all day. Past the expiry without confirmation, the hold disappears and the slot becomes free again automatically; the waitlist is notified.
- How do you lower no-shows?
- With a WhatsApp reminder the day before and two hours before, with a one-word reply, yes, move or cancel, that updates the appointment; with a deposit where the trade accepts it; and with a waitlist that fills released slots. No-shows are recorded on the customer record and the no-show rate is measured per practitioner.
- How do you handle customers booking from France?
- By storing times in Algiers time, which stays at UTC+1 all year, and showing them in the customer's time zone. France moves to UTC+2 from late March to late October: a 14:30 slot in Algiers shows as 15:30 in Paris in summer. The confirmation and the reminder carry the time zone note.
- Why not an online diary from the market?
- Because it is often the right choice: if your rules fit theirs, take it. Custom starts when the appointment must talk to the customer record, stock, the till and the WhatsApp agent in the same application, or when the booking covers combined resources, a cabin and a therapist, a lift and a mechanic.
- How long does it take to build a booking system?
- Six weeks in the typical calendar: one to write the rules, one for availability and the engine, one for booking and lock, one for confirmation and payment, one for reminders and the counter, one for measurement. The duration depends on the number of resources and the complexity of the services.