Implementation
Decide what happens when the calendar goes down
Use an outage runbook that keeps requested appointments separate from confirmed bookings and reconciles uncertain actions.
Published · Collection dates are retrospective editorial dates.
The calendar fails just after a customer chooses a time. There may be no appointment, or there may be an appointment whose confirmation never reached the receptionist. Those are different situations. Treating both as “try again” can create duplicate bookings. Treating both as “all set” can create an appointment that exists only in a conversation.
Decide how your scheduling workflow handles uncertainty before customers encounter it. The goal is an honest status, a recoverable record and a person who owns the unfinished work.
Use states that describe reality
A requested appointment is an expression of intent. A submitted appointment is an attempted action. A confirmed booking has the evidence your business requires. A pending verification state covers cases where the action's outcome is uncertain.
Keep these distinctions in the records, customer messages and staff interface. A beautifully clear internal status is little use if the confirmation message still says the appointment is booked.
| State | What is known | What the customer may be told |
|---|---|---|
| Requested | Customer supplied preferences | The request has been received |
| Availability checked | A query returned availability information | The time is being checked for booking |
| Submitted | A creation attempt was made | Confirmation is pending |
| Confirmed | Required booking evidence was verified | Approved confirmation details |
| Outcome uncertain | The response did not establish success or failure | A person will verify the request |
This is a proposed model. Fit the labels to your scheduling platform and avoid states that staff cannot reliably distinguish.
An availability check is not a booking
Google's free/busy reference describes a query for calendar availability. Its event-creation guide describes creating an event. They are separate operations. Your integration should preserve that distinction rather than treating a clear calendar query as a completed appointment.
Other scheduling products may expose different operations and controls. Require the implementation team to explain what prevents conflicting actions in the specific product you use. Do not assume a general-purpose calendar knows chair assignments, technician travel time, appointment eligibility or your business's capacity rules.
In a hypothetical service business, two customers ask for the last afternoon slot. Both conversations can see the same availability before either action completes. The operating question is how the actual booking system resolves the contention, and what the unsuccessful conversation says afterward.
Write a short outage runbook
- Detect the failed or uncertain dependency and stop claiming confirmed bookings from it.
- Save the customer's request with an identifier and current action state.
- Preserve any returned external event identifier or error information.
- Assign verification to a staffed role using the approved coverage plan.
- Explain the pending status without inventing a recovery time.
- Reconcile the record after service returns, then send an appropriate update.
Do not let the fallback quietly become another unmonitored inbox. The runbook needs an owner, a backup and a visible list of pending items. Staff should be able to operate it when the project developer is unavailable.
That warning is an engineering precaution, not a statement that every scheduling API behaves identically. Ask the provider which identifiers, lookup methods and retry guarantees are supported.
Reconcile before you replay
After recovery, review uncertain actions first. Search using the supported external identifier or another documented correlation method. If the appointment exists, verify its details. If it does not, decide whether the customer's original preference is still available and appropriate before submitting again.
Do not create a substitute appointment simply to clear the queue. The customer may have made other arrangements during the outage. Your recovery process should distinguish verification from making a new commitment.
A hypothetical pending request for Tuesday morning cannot automatically become a Wednesday booking because the Tuesday slot disappeared. Record the changed availability and have the appropriate person obtain the next instruction.
Keep old appointments intact during changes
Rescheduling deserves its own failure cases. If the workflow cancels an existing appointment before the replacement is verified, an outage can leave the customer with neither. If it creates the replacement but never retires the old record, the business may reserve duplicate capacity.
Document the platform's supported change process and test interruptions at each stage. Where a safe automated sequence is unavailable, retain a human review step. A narrower capability is preferable to an unowned repair job.
Never make a customer infer booking status from the assistant's tone.
This is an original editorial principle. The wording of the customer message should follow the evidence, even when that makes the message less satisfying in the moment.
Rehearse recovery, not just failure
Before launch, simulate an unavailable calendar, a delayed response, a malformed booking and a connection that fails after submission. Then perform the reconciliation using the same staff tools available in production.
Check reminders and downstream workflows too. A pending request should not trigger a confirmed-appointment reminder. A cancelled test booking should not remain on a technician's dispatch list. Record the evidence needed to demonstrate that the entire recovery completed.
End the rehearsal with an actual person clearing the pending queue and another person checking the result. That gives the outage plan a practical test: can the business regain a trustworthy calendar without relying on the assistant to explain away uncertainty?
Sources
Explore the workflow considerations for ai scheduling booking.
Keep reading
