Write down the confirmation boundary
Decide what evidence counts as a completed booking in your actual scheduling system. This might include a booking reference and a record that staff can retrieve. A proposed slot, a successful availability search or an email queued for sending is not enough on its own. The caller-facing wording should match that evidence. If the workflow only captures requests, describe it as a booking request throughout the conversation and website. This distinction prevents staff discovering that callers believe an appointment exists when their diary contains no matching entry.
Handle a slot that disappears
Another person may book a slot after it was offered and before the phone booking is saved. Treat availability as provisional until the save succeeds. If a conflict is reported, explain that the time is no longer available and fetch fresh alternatives. Do not keep repeating the same failed slot. Preserve the caller preferences already collected, including location, service and preferred day. Offer a callback request when the caller cannot consider alternatives. Avoid turning a simple conflict into a long cycle of questions they have already answered.
Treat a timeout as an unknown result
A timeout can mean the request never arrived, or that the booking was created but the response did not get back. Repeating the write immediately may create a duplicate. Ask the provider how it checks the result of an interrupted request, including whether it can find the original booking using a request identifier. This is an implementation question to prove with a test, not a feature to assume. Until the state is known, tell the caller that confirmation is pending and create a staff task to resolve it.
Capture a recovery message people can use
The recovery task needs the caller name, a verified callback number, the requested service, preferred times, location and the exact booking state. Keep technical error details available for support without making them the only information staff receive. Mark the task as awaiting confirmation so nobody mistakes it for a completed appointment. Agree a team owner and an appropriate response window. If the caller cannot wait, explain the available next step without inventing availability or promising that a requested slot will be held.
Separate booking success from notification success
A booking can exist even when its confirmation message fails. In that case, do not create another booking to trigger another message. Check the diary first, then repair the notification step. Conversely, a message saying "request received" must not be treated as proof of a saved appointment. Test both situations independently. Staff should be able to identify what was stored and what the caller was told. This separation also helps resolve later disputes about whether a person was booked, merely requested a time, or never received the details.
Rehearse recovery before accepting live bookings
Use clearly marked internal test details and exercise an unavailable calendar, an occupied slot, an interrupted save and a failed confirmation message. For each case, inspect the calendar, task queue and spoken response. Include a caller who changes their mind during recovery and another who hangs up. Remove test bookings afterwards through the normal workflow. Approve live booking only when staff can reconcile every test result. If the integration cannot demonstrate safe recovery, begin with request capture and human confirmation while the missing capability is resolved.