In our scheduling project, a room is free at 10:00 and the practitioner is available. The appointment still cannot go ahead: the assessment kit is already allocated to another room.
That is the difference between displaying a calendar and designing a booking system. A bookable appointment depends on all the required resources being available together, including the time needed between uses.
The room and equipment scheduling workspace follows one conflict through to a proposed alternative. It gives us a useful way to explain the rules a scheduling brief needs to contain.
Why the first available room is the wrong answer
Request S?303 asks for a 10:00?10:45 appointment in Room 01. The room is available. Kit K?01, however, is allocated to an existing appointment in Room 02 until 10:45.
Moving the request to 10:45 does not solve the problem. The kit has a 15-minute reset, so it remains unavailable until 11:00. The project compares all three start times rather than making the coordinator discover each conflict separately.
| Proposed start | Room | Shared kit | Outcome |
|---|---|---|---|
| 10:00 | Available | Allocated elsewhere | Cannot proceed |
| 10:45 | Available | Reset in progress | Cannot proceed |
| 11:00 | Available | Available after reset | Can be proposed |
The existing booking remains intact. The alternative changes the start of the new request; it does not resolve the conflict by quietly moving another person's appointment.
The room is free, but the kit is not
The calendar should show occupied time, not just appointment time
A reset is operationally significant even when nobody is receiving the service during it. If the calendar only blocks customer-facing appointment time, a coordinator can accidentally schedule work into preparation or clearance time.
The revised proposal runs from 11:00 to 11:45 and retains a reset from 11:45 to 12:00. That makes a 45-minute appointment occupy a 60-minute allocation. These are the rules in our sample schedule, not a universal recommendation for appointment length.
In a production brief, define the buffer for each resource. A room might need a different turnaround from a shared device. Travel between sites may add another constraint. Keeping all of those under one unexplained ?buffer? field makes future changes difficult.
Separate a proposed time from a confirmed appointment
The 11:00 slot passes the resource checks, but the request still awaits acceptance. We make that visible in the request page and the scheduling response.
This distinction protects both sides of the conversation. The coordinator can discuss a feasible alternative without claiming that the person has accepted it. The recipient can see precisely which time and resources are being proposed.
If a system supports temporary holds, specify how long they last and what happens when they expire. A coloured block on the calendar needs an agreed meaning: occupied, held, proposed and unavailable are different states.
Time and resources
- 01RequestCapture the activity and proposed time.
- 02CheckReview people, room, equipment and turnaround.
- 03ConfirmReserve only after the required conditions pass.
Explain the conflict at the point of decision
?Unavailable? may be enough for a public booking picker. A coordinator needs to know what prevents the appointment and what can change.
Our conflict view identifies the existing allocation, the kit reset and the next feasible start. The request page then carries the chosen alternative forward. Keeping those views connected means the coordinator does not have to re-enter the explanation in a separate message.
It also makes a useful distinction between changing time and changing resources. An alternative room will not help when the same kit is required. A substitute kit may require a suitability check. The interface should not treat every available resource as interchangeable.
Use this scenario when comparing scheduling tools
Ask a supplier to demonstrate a shared item, a protected reset and an appointment awaiting acceptance. Then change the requested time while another user is working with the same calendar. The system needs to recheck availability when it saves a commitment, not rely indefinitely on an earlier screen.
Our custom versus off-the-shelf guide explains how to turn those scenarios into a product comparison. A standard tool may fit well; the important thing is to test the actual constraints rather than count calendar features.
A workable alternative still needs acceptance
For custom software development, these rules become part of the record model and acceptance checks. For public enquiries, the website may need only to collect a preference and explain that staff will confirm it. Our venue website guide looks at that earlier stage, before a visitor's preferred date becomes an operational commitment.
Sources and calculation notes
The scheduling example follows request S–303 and kit K–01 in our original project. Existing use ends at 10:45; a 15-minute reset protects the kit until 11:00. The revised 11:00–11:45 appointment retains a reset to 12:00: 45 + 15 = 60 minutes allocated. These are sample scheduling rules.
- Our room and equipment scheduling project. The project page includes the design account, delivered scope and screenshots discussed in this article.
External references checked on 31 October 2026.