Reservation Protection
The chosen slot is reserved for the customer for 3 minutes
Friday evening, a new listing, fifteen prospects on your booking page at the same time – and two of them want the same slot. Without protection both win; you are the one writing the apology email.
Always active, on every booking path – 3 minutes.
How It Works
The customer picks a slot
The booking dialog opens with date, time, property and appointment type; the 3-minute hold starts.
Enter the details
Name, email, optionally a mobile number; the reservation holds the slot exclusively in the meantime.
Complete the booking
The booking is finalised. Anyone browsing in parallel no longer sees the slot – or finds out immediately that someone was faster, instead of double-booking.
Key Benefits
When the booking dialog opens, timum reserves the slot exclusively for three minutes – nobody books it away while your customer is entering their details.
The countdown is visible in the dialog – customers always know how long their reservation holds.
Only what is genuinely free is offered: after every booking, all start times that would overlap with it disappear immediately.
One mechanism everywhere: the booking page, the embedded widget and the Open Booking API (reserve_appointment) use the same hold.
Who Needs This Feature?
See how this feature helps different users
The rush after the listing goes live
On the evening of publication many people book at once. Every slot is given out exactly once – without you stepping in or sorting it out afterwards.
Many channels, one inventory
Website widget, Google profile, booking links in emails: all channels draw on the same times. The hold prevents collisions between channels as well.
Your own frontend, the same guarantee
Anyone booking via the REST API inherits the mechanism: reserve_appointment holds the slot, an appointment already taken responds with 412 Precondition Failed – deterministic instead of a race condition.