A Chat Booking Is Not Confirmed Until the Calendar Says So

A booking reply is a commit acknowledgement, not a writing task. If the calendar has not accepted the appointment, the chatbot cannot truthfully say it is booked.

The failure is easy to create. A visitor asks for Tuesday afternoon. The assistant offers a time and writes, “You are booked.” Meanwhile the calendar request times out. The customer arrives expecting a slot that the business cannot see. The words were coherent; the state was wrong.

Separate the Choice From the Commit

Conversation is useful for gathering the service, location, preferred time, and necessary contact details. It can explain available choices in plain language. But an offered time is provisional until the booking system accepts it. Availability can change between the question and the write.

Make that boundary visible. Before the write, say the time is available to request. After a successful write, return the confirmed time, time zone, and reference. If the write fails, say the booking did not complete. If the result is unknown, say it is unconfirmed while the system checks. Never use the same confirmation sentence for all three states.

Both Google Calendar and Microsoft Graph create an event through an authenticated write and return an event resource. That resource, not the assistant's prose, is the evidence of a committed appointment.

Retry the Same Intent, Not a New Booking

A timeout does not reveal whether the first write succeeded. Blindly sending another create request can produce two bookings. Give the customer intent a stable identity, check for an existing result, and let a retry continue that same attempt. Google Calendar describes caller-supplied event IDs as one way to keep a local record in sync and avoid duplicates after an ambiguous result. Stripe documents the same general principle for safe request retries with an idempotency key.

The exact mechanism depends on the booking provider. The design requirement does not: one customer request should lead to at most one committed reservation. If the provider cannot support that guarantee, reconcile the calendar before speaking as though the retry succeeded.

Keep Changes Attached to the Original Record

Booking is a lifecycle, not a single chat turn. A customer may reschedule or cancel. Those actions need to find the original reservation, check the new conditions, commit the change, and report the resulting state. A conversational “done” with no changed record leaves the operator and customer with different versions of the appointment.

This is the pattern we use in HoverBot: let chat gather and explain, but let a durable booking record decide what can be confirmed. It trades a little conversational speed for a clear answer to the question that matters: where can the business see and change this appointment?

Test the awkward paths before trusting the happy one. Make the calendar write fail. Let it succeed while the response times out. Retry the same request. Ask to reschedule a booking that no longer exists. At each point, compare the transcript with the durable record. If they disagree, the assistant must stop promising and hand the case to a person.