Double-booked by the booking agent: where the slot lock went missing

Before reading a single log, reproduce it. Have 2 channels request availability for the same provider at the same moment, then have both commit the same slot a few seconds apart, and record 5 timestamps: when each channel read availability, when each attempted to write, and when the practice system accepted each write. The gap between the read and the write is where double bookings live, and the size of that gap tells you whether you are looking at a caching problem, a missing hold, or a scheduling system that will accept 2 appointments in one slot without complaint.

The underlying rule is short enough to put on a wall. Availability may be cached; a commitment never may. Everything a booking surface shows a patient is a read of a fast-moving list, and reads can safely be seconds stale. The moment the patient says yes, the system has to stop working from its own copy and go back to the source, conditionally, in a way that fails if the world moved. Agents make this visible because they hold a caller in conversation for 40 to 90 seconds between offering a time and confirming it — a window a web form closes in 3.

Force the collision on purpose, then read the 5 timestamps

1. Pick one provider and one afternoon in a test environment, or a genuinely empty session in production if there is no test copy that shares the same scheduling rules.
2. Read availability from both channels within a second of each other and record both responses in full, including whatever version or revision marker the response carries.
3. Commit from channel A and let it succeed. Do not refresh channel B.
4. Commit the same slot from channel B roughly 30 seconds later, still inside the window where its cached list says the slot is free.
5. Record what happened: an error naming the conflict, a silent success producing 2 appointments, or a success that overwrote the first booking. Those 3 outcomes have 3 different owners.
6. Repeat with the desk as channel B, booking directly in the practice system while an agent call is in progress. This is the case teams forget, and it is the one that cannot be fixed by any change to the agent.

The reservation that has to exist between the offer and the yes

A hold is a real object, not a flag. It names the slot, the channel and the conversation that owns it, it carries a creation time and an expiry, and it makes the slot unavailable to every other reader for as long as it lives. Three properties decide whether it helps or hurts.

• It expires without being told to. Calls drop, patients hang up mid-sentence, browsers close. A hold that survives its conversation is a slot removed from the day by a caller who never booked. Pick an expiry from the real conversation length — 2 to 3 minutes covers a phone exchange with a slot offer and a confirmation, and anything above 10 minutes will quietly empty an afternoon.
• It is owned, so it can be released early. When the caller picks a different time, or the agent escalates to a human, the hold on the rejected slot has to be dropped immediately rather than left to time out.
• It converts, rather than being replaced. The commit turns the hold into an appointment against the same identifier. Where the commit writes a fresh appointment and separately deletes the hold, there is a window between the 2 operations in which the slot is free — which is the exact defect the hold was introduced to remove.

The commit itself has to be conditional. Send the version or revision marker the slot carried when it was read, and require the practice system to reject the write if that marker has changed. Where the interface offers no such marker, the fallback is to re-read the slot inside the same transaction and refuse to write if it is no longer free — weaker, because it narrows the race rather than closing it, but far better than writing blind. A booking that succeeds unconditionally is not a booking; it is an assertion.

A slot a patient has been offered but not yet accepted is neither free nor booked. If your data model has no third state, the collision is not a bug — it is the model working as designed.

5 ways 2 channels end up writing into one slot

The template row is the one that surprises people. Sessions get shortened, a provider is pulled to cover elsewhere, an urgent hold is released into the bookable pool at 08:00 — and each of those rewrites the shape of the day underneath conversations already in flight. The objects involved and the rules that govern them are set out in how a provider template encodes a clinic day; a booking channel that does not understand blocks, holds and release rules will offer times that were never bookable in the first place.

Separating what you can fix from what the scheduling system owns

This split is the whole point of the reproduction exercise, because the 2 halves have completely different economics. Caching, holds, conditional writes and idempotency on retries sit inside the software you are building, and are a week or 2 of careful work. A practice system that will happily store 2 appointments in one slot is a constraint you inherit, and the honest response is a detector rather than a promise.

1. Make every commit idempotent. A retried write after a network timeout must not create a second appointment — key it on the conversation, not on the attempt.
2. Re-validate at commit against the live template, not against the availability you cached at the start of the call.
3. Run a conflict sweep on a schedule, hourly during clinic hours, that lists any slot holding more than 1 appointment and puts it in a queue with an owner. This is the safety net for the case you cannot prevent, and it is worth building even when the constraint exists.
4. Resolve conflicts by rule, not by whoever notices first. Earliest committed booking keeps the slot; the later one is contacted with alternatives before the day arrives, never on the morning.
5. Log every offer, hold, expiry and commit with its channel. Without that, the next argument about double bookings is another round of anecdotes.

The distinction between a provisional statement and a committed one runs through clinical software generally, and the discipline is the same wherever it appears: what a system publishes provisionally and what it stands behind are different objects with different obligations, as in what a final and a preliminary report each commit to. A slot offer is provisional. An appointment is not.

What a correct hold still will not prevent

A hold makes the slot exclusive. It says nothing about whether the booking should have been made. An agent can hold, commit and confirm an appointment that is the wrong duration, with the wrong provider, for a patient the clinic cannot yet identify — and none of that shows up as a conflict. The fields that have to exist before an appointment genuinely counts as booked are set out in what a registration must carry before a first visit is real, and collecting them mid-call is precisely what stretches the hold window. Pre-filling from records the patient has already given someone else shortens that window materially, which is a concurrency benefit as much as a convenience one — the method is in pre-filling intake from records.

Nor does it cover work arriving through a queue rather than a conversation. Referrals get booked in batches by staff working a list, often against slots held back for exactly that purpose, and a batch process that reads availability once and writes 30 appointments will collide with every live call in progress — one more reason the state of that queue has to be explicit, as argued in referrals that arrive with nobody able to tell which are unbooked.

Most of this work is unglamorous plumbing between systems that were never designed to share a calendar, which is the kind of build we scope as internal tools and operations. It sits alongside the rest of front desk, intake and patient access in a healthcare operations programme, and it is worth settling before a booking agent goes anywhere near a real clinic day.

• scheduling
• booking agents
• front desk
• concurrency