How a booking system works starts with one subtraction: the system takes your opening hours, then cuts away holidays, time blocks, bookings already taken, and the gap between sessions. What remains becomes the slots on your booking page. That calculation is correct only when you first set opening hours, service duration, and time zone. The limit matters too: the slot list on screen is a preview, not a promise. A slot belongs to somebody only at the second the book button is pressed.
I wrote this page for a service owner who does not read code. You will see the machine behind the "Pick a time" button, including the 2 failures that cost the most money: 2 people book the same hour, and 1 person gets booked twice. For the plain definition and the feature list, start with my pillar article about booking systems.
How a booking system works in 5 steps
Scheduling software runs the same 5 steps under any brand name. This table names each step and the part that breaks.
| Step | What the system does | Main risk |
|---|---|---|
| 1. Read rules | Load weekly opening hours per day | Wrong hours entered |
| 2. Subtract | Remove holidays, blocks, taken bookings | A block never entered |
| 3. Slice | Cut the rest into duration plus gap | Zero gap exhausts staff |
| 4. Show | Send candidate slots to the page | Buyer treats slots as certain |
| 5. Lock | Re-check the slot as the order lands | No lock, double booking passes |
Step 5 is the step a beginner build skips. Steps 1 to 4 produce a display. Step 5 produces the truth.
Five inputs that decide if a slot appears
A slot is not a row you store. A slot is a result, computed again each time the page opens. These 5 inputs decide that result.
| Input | Sample value | Effect on slots |
|---|---|---|
| Opening hours | Monday to Friday, 09:00 to 17:00 | Sets the outer edge |
| Service duration | 30 minutes | Sets the width of 1 slot |
| Buffer before and after | 0 minutes and 10 minutes | Adds space between sessions |
| Time block | Wednesday 13:00 to 14:00, meeting | Deletes slots in that range |
| Holiday | A national public holiday | Closes a full day |
Owners forget the buffer. A buffer belongs to the service, not to the opening hours. Think of it as room cleaning time. When a session runs 30 minutes and the buffer after runs 10 minutes, one cycle eats 40 minutes, and the count of slots per day drops. The rules for writing each input sit in the Termilo availability documentation, including how opening hours are stored as minutes after midnight.
Storing a clock time as a plain number sounds odd, but it helps the machine. 09:00 becomes 540. 17:00 becomes 1020. The engine only subtracts numbers, and it never parses a clock string.
Why 2 people can book the same hour
Picture 2 customers who open your page at the same second. Both see Wednesday 10:00. Both press the book button half a second apart. With no guard, the server handles both requests side by side, and both read "the slot is free" before either one writes. The result is 2 bookings in 1 hour.
The fix is called a lock. As an order lands, the system asks for the lock on that slot. Only 1 request holds it at a time. The holder re-checks availability, writes the booking, then releases the lock. The second request arrives after that, reads a taken slot, and gets refused with a message that somebody just claimed the hour.
The closest analogy is a fitting room. The "free" sign on the door is a preview. The locked handle is the truth. So treat the slot list on screen as a set of candidates, and demand that the system re-checks at the last second.
You can see this behaviour in the error the system returns. Termilo, for example, documents the code BOOKING_SLOT_UNAVAILABLE with status 409 for a slot already taken when re-checked under the lock. The rest of the codes sit in the Termilo API reference. When you test a candidate product, ask for a demo of this failure, not only a demo of a smooth order.
Why 1 order can arrive twice
The second problem runs the other way. A customer presses the book button on the road, the signal drops, the screen spins, and she presses again. Sometimes the first order reached the server and only the answer was lost. The server receives 2 identical requests, and it writes 2 bookings.
The guard is called an idempotency key. Think of it as a queue ticket. The app creates 1 random number for 1 intent to book, then sends that number with each attempt. The server stores the pair of number and result. A second attempt with the same number creates no new booking. The server returns the first one.
Termilo requires an Idempotency-Key header on its public booking endpoint. The documentation states that a new booking answers 201, while a repeat with the same key answers 200 plus an idempotentReplay marker. The detail sits in the Termilo booking lifecycle documentation.
Ask a vendor one question about this. What happens when a customer taps twice on a weak signal? If the answer is "we delete the copy by hand in the admin panel", your staff pays that cost each week.
Time zones and why a time is stored as an instant
This is the quietest source of error. The text "Wednesday 10:00" is not 1 point in time. It depends on a zone. Wednesday 10:00 in Jakarta is not Wednesday 10:00 in Makassar, and it is certainly not Wednesday 10:00 for your client in Singapore.
So a correct system stores time as an absolute instant, usually as an epoch number, which counts milliseconds after 1 January 1970 UTC. That number reads the same for anybody on earth. The time zone is applied only to display that number as a human clock time.
Air travel is the analogy. An airline stores 1 departure instant, then shows it as a local time in Jakarta and a local time in Singapore. Both labels point at the same second.
Here is the test to run on a trial account. Open the booking page on a device whose zone you switched to Asia/Makassar. If the displayed times shift with the zone and the booking still lands in the correct session, the storage is healthy. If the times do not move at all, the product stores clock text, and you will meet customers who arrive at the wrong hour.
Booking statuses from held to no_show
A booking moves through a short list of statuses. Statuses keep your reports honest, because a cancellation and a missed session are counted apart.
The table below uses the vocabulary Termilo documents, because that vocabulary is public and you can check it yourself. Other products use other names, but the meaning is close.
| Status | Meaning for the owner | Final |
|---|---|---|
| held | Slot parked for a moment, not valid yet | No |
| confirmed | Valid booking, slot locked | No |
| completed | The session was delivered | Yes |
| cancelled | Called off by owner or customer | Yes |
| no_show | The customer did not arrive | Yes |
The held status is a temporary park. Termilo documents a new booking as born in held with a 10 minute hold. If nobody confirms it inside that window, the hold expires and the slot opens again. A reschedule keeps the status; it only moves the time, then locks and checks for overlap again.
Read the Final column with care. The last 3 statuses never move again. That rule protects your numbers, because a session marked complete cannot quietly turn into a cancellation at month end.
A simulation with dummy clinic data
This worked example uses invented data for practice. Cemara Clinic is not real, and the numbers are not a client result.
Starting condition. Open Monday to Friday, 09:00 to 17:00. One service, "30 minute consultation". Buffer after the session, 10 minutes. One doctor. An internal meeting each Wednesday, 13:00 to 14:00. One confirmed booking already sits at Wednesday 10:20.
Input. A customer opens the page and asks for Wednesday availability.
Calculation steps. The Wednesday window holds 480 minutes. One cycle eats 40 minutes, which is 30 minutes of session plus a 10 minute buffer. The meeting block removes 60 minutes in the middle. The morning side, 09:00 to 13:00, holds 6 cycles. The afternoon side, 14:00 to 17:00, holds 4 cycles, because a fifth cycle would pass closing time. That gives 10 candidate slots. The booking at 10:20 removes 1 of them.
Observable output. The page shows 9 slots: 09:00, 09:40, 11:00, 11:40, 12:20, 14:00, 14:40, 15:20, and 16:00.
Decision. Nine slots a day is too few for a target of 12 patients. The arithmetic above leaves 2 options: cut the buffer from 10 minutes to 5 minutes, or add a second doctor with separate opening hours. The second option raises capacity without squeezing the cleaning time.
A checklist before you pick a system
Use this list during a trial. Each item tests 1 mechanism explained above.
- Ask for a demo of 2 orders on one slot, and read the refusal message.
- Press the book button twice with the connection switched off, then count the bookings.
- Switch the device zone to Asia/Makassar, then check the displayed times.
- Set the buffer after a session to 15 minutes, then confirm the slot count drops.
- Add 1 holiday, then confirm the day disappears from the page.
- Cancel 1 booking, then confirm the slot returns.
- Look for a report that separates cancellations from missed sessions.
If you want this engine inside your own product, we build it through our web application development service. If you only need a booking page that runs this week, I recommend Termilo. Let me state the relationship plainly: Rama Digital recommends Termilo, and Rama Digital does not operate it. PT Nafanesia Kebermanfaatan Indonesia in Bandung operates Termilo. The term map behind this article sits on the Termilo core concepts page.
For schedules that start in a conversation instead of a page, read how to let an AI assistant set meetings automatically.
Questions people ask
Are slots stored in a database? No. Slots are computed again on each page load, from opening hours minus holidays, blocks, taken bookings, and buffers.
Why did a slot I saw disappear? The slot list is a preview. Somebody booked it first, and the system settles availability only while the order is processed.
What is an idempotency key in plain words? A queue ticket for 1 intent to book. A second attempt with the same ticket returns the first booking, not a new one.
How long does a system hold a slot? It depends on the product. Termilo documents a 10 minute hold on the held status before the slot is released.
Does a reschedule delete the old booking? Not in a tidy system. Termilo documents a reschedule as a move of the time, while the booking status stays the same.
Why do time zones deserve this much care? A clock time with no zone points at a different instant for each reader, and customers arrive at the wrong hour.
Sources
I read these pages on 17 February 2026, and each technical term in this article comes from them.
- Termilo availability documentation, termilo.id/docs/availability
- Termilo booking lifecycle documentation, termilo.id/docs/booking-lifecycle
- Termilo APIAPIThe official door 2 systems use to exchange data, without anybody copying it by hand.Open the glossary reference, termilo.id/docs/api
- Termilo core concepts, termilo.id/docs/concepts
- Termilo documentation map for AI agents, termilo.id/llms.txt
