CONFIRMED APPOINTMENTS
Do not turn two simultaneous choices into two confirmed promises.
Recheck availability when writing the appointment and enforce non-overlap for active bookings of the same resource.
Same resource · 10:00–11:00
Only one overlapping active booking is accepted for the same resource.
A slot picker alone cannot settle a simultaneous request
Two customers can open the same available afternoon before either has confirmed. Hiding occupied times is useful, but both browsers may still display an earlier free interval. Tsumira checks availability again during appointment creation and protects active intervals at the storage boundary. The supported invariant concerns overlapping confirmed appointments for the same resource, not every possible scheduling conflict in unrelated systems.
Separate the offered list from the final promise
The availability picker derives times from the service duration, opening rules and occupied intervals. That is a current offer, not a hold for every visitor looking at the page. The final creation path repeats the relevant availability calculation. A stale selection can therefore be refused when the promise can no longer be made, instead of treating the customer’s click as proof that the time remains free.
- Current offered intervals
- Final availability recheck
- Refusal of a stale choice
Protect the same resource against overlapping active intervals
The appointment data enforces a non-overlap rule for the tenant and resource while the booking is active. The protected unit is the actual time interval, so a partially overlapping longer service also matters. Cancelled appointments do not occupy that active interval, and consecutive appointments can touch at their boundaries. This complements the picker rather than relying on a browser’s timing to prevent conflicts.
- Tenant and resource-specific rule
- Actual interval overlap
- Cancelled versus active appointments
Return a useful outcome to the customer or staff
Known concurrent-write conflicts are treated as an unavailable booking outcome rather than as a second successful promise. Both public and staff-assisted creation use the shared booking path for the relevant checks. The person should choose another available time or inspect the existing appointment. A booking system cannot infer conflicts in an external calendar or a different resource unless that information is part of the supported workflow.
- Conflict-aware booking result
- Shared creation rules
- Scope kept explicit
Same resource · 10:00–11:00
Only one overlapping active booking is accepted for the same resource.
A concrete workflow
Offer the currently available times
Calculate service-fitting intervals from the current rules and occupied resource.
Submit the choice
Customer or authorized staff requests the intended appointment through the supported path.
Settle against current state
Recheck availability and the protected resource interval during creation.
Confirm or choose again
Use the actual result: confirmed booking or an unavailable interval requiring a new choice.
An illustrative working example
Illustrative workflow: two customers choose one consultation time
Two visitors see the same consultation interval before either finishes. The first successful booking makes the promise for that resource. The competing attempt is not another confirmation merely because its browser still showed the interval. It receives an unavailable result and can select another time. The rule protects that resource’s active bookings without claiming knowledge of every colleague’s unrelated calendar.
Questions about this topic
Does an available slot stay reserved while someone reads the page?
No. The display is an offer based on the current read. Final creation checks the current state again.
Are partially overlapping intervals relevant?
Yes. The rule protects the actual appointment intervals for the same resource, not only identical start times.
Can one appointment begin when another ends?
The supported interval model allows adjacent bookings that touch at their boundaries without overlapping.
Does this automatically detect every external calendar conflict?
No. The protection described here applies to the supported resource and active booking data. Unrelated external systems are not automatically included.
Explore connections around this workflow.
Ideas for intended connections. Check the actual availability, permissions and supported data for each app before using a scenario.
Calendly
Workflow concept: Compare reservation authority before designing a cross-system booking concept.
Google Calendar
Workflow concept: Treat an external calendar view as information, not a shared reservation lock.
Microsoft Excel
Workflow concept: Document resource and interval rules before testing competing slot requests.