Appointment scheduling conflict rules should define which people, spaces and equipment a booking consumes, then check those resources again when the booking is confirmed. An available-looking calendar slot is only a proposal. The scheduling workflow also needs rules for holds, buffers, rescheduling and simultaneous requests so customers receive commitments the operation can honour.
Describe a bookable appointment as a resource requirement
Start with appointment types rather than a universal duration field. A consultation might require one adviser and a room; a demonstration might also require a particular device. Record the resources, duration, preparation time and cleanup time needed for each type.
Distinguish interchangeable resources from specific ones. Any suitably assigned adviser may handle an introductory call, while a follow-up may need the same adviser. A resource group can support the first case, but the second requires an explicit person. Make that distinction visible to whoever configures availability.
Identify which calendar or system is authoritative for each resource. If staff also book appointments outside the application, define how those commitments are received and how stale availability is handled. A delayed calendar feed should not be presented as a guarantee that a slot remains free.
Define overlap precisely
Use a consistent interval convention. For example, an appointment occupying 10:00 up to, but not including, 10:30 can sit directly before one beginning at 10:30 if no buffer is required. Add preparation and cleanup to the occupied interval before checking overlap.
Write separate rules for staff breaks, travel and opening hours. A fifteen-minute gap may be sufficient for two calls but insufficient for visits at different sites. Where travel cannot be calculated reliably, let staff choose a planning allowance and show it as part of the resource reservation.
Capacity matters too. A class with ten places does not become unavailable after its first participant, but it should stop accepting confirmed places at its agreed limit. Model seat reservations separately from the shared event and decide whether provisional holds count against capacity.
Temporary holds need an end
A hold can give a customer time to complete a booking form while preventing another customer taking the same exclusive resource. Store the hold's owner, resources and expiry. Decide how long it lasts using the actual booking journey, and show the user what happens if it expires.
Confirmation must check that the hold is still valid and the resources remain available. Handle competing confirmation attempts in one controlled reservation operation, rather than relying on what each user saw when opening the calendar. If a request loses the slot, retain its entered details and offer a clear next step.
Use a booking reference to recognise a repeated submission after a slow response. Refreshing the confirmation page should not create another appointment. The interface should be able to recover and display the existing booking associated with that submission.
Rescheduling should preserve the original until the move succeeds
Treat a requested move as a proposed change. Check all required resources at the new time before releasing the original reservation. If the adviser is available but the room is not, explain the conflict and preserve the existing appointment.
Once the change succeeds, update reminders and calendar references against the new version. Keep the previous time in history. A reminder created before the move should recheck the current booking before sending so it cannot direct the customer to the superseded slot.
Decide whether cancellations release resources immediately and whether a waiting list should be offered the space. An offer to someone on a waiting list may need its own expiring hold. Do not automatically confirm a new customer unless that is part of the explicitly agreed booking process.
Scheduling rules checklist
- Each appointment type names its required resources and occupied intervals.
- Time zones are stored and displayed consistently for organisers and attendees.
- Ambiguous or unavailable local times during clock changes have a defined handling rule.
- Holds expire visibly and cannot be confirmed after expiry without rechecking.
- Simultaneous confirmation attempts cannot exceed exclusive or shared capacity.
- Failed moves preserve the original appointment.
- Retries and delayed reminders refer to the current booking version.
Test the last room and a failed move
In a fictional clinic-style scheduling exercise using dummy data, create a consultation that needs an adviser and one private room. Two customers attempt the last available slot at the same time. Expect exactly one confirmation, with the other customer retaining their draft and seeing that the slot is unavailable.
Ask the confirmed customer to move to a time when the adviser is free but the room is occupied. The move should fail without cancelling the original appointment. Then choose a valid time and repeat the confirmation request after simulating a network interruption. Expect one updated booking and no additional reservation.
Run a separate test around a clock change and another with a customer in a different time zone. Verify the displayed local time, stored instant and reminders agree. For recurring appointments, state whether the intended rule preserves local wall-clock time or a fixed interval, then test that exact rule.
Give staff an exception queue they can operate
Show unresolved calendar syncs, expired holds needing follow-up and appointments missing a required resource. Record manual overrides with a reason and responsible person. An override should be an explicit operational decision, not a hidden route around every conflict rule.
For ongoing connection failures, use the approach in our integration monitoring runbook. To build scheduling around your own resources and move rules, explore Visuosofts application development and contact the team with a normal booking and a difficult rescheduling example.