A Voice Agent Should Not Book the Wrong Meeting Twice

Booking sounds like an easy voice-agent task because the happy path is short. The failures are not. A caller says “next Friday” near midnight, uses a different time zone from the office, corrects their email while the agent is speaking, or pauses long enough for somebody else to take the slot. The calendar write then times out after succeeding, and an automatic retry creates the same meeting again.

Write the booking contract before the conversation. Define which services, locations, durations, buffers, attendees, and booking windows the agent may use. Decide what needs identity verification, what requires a person, and what happens when the requested time is no longer available. A prompt cannot compensate for an undefined scheduling policy.

Confirm the calendar date, local time, time zone, location or meeting mode, service, attendee name, and the destination for the confirmation. Read email addresses in chunks and ask the caller to correct them. For high-impact appointments, confirm the phone number or account using an approved verification path rather than trusting caller ID alone.

Relative phrases need an absolute interpretation: “Friday, September 4 at 2:30 p.m. Eastern.” If the caller changes one field, do not silently retain every earlier assumption. Recalculate duration, availability, buffer, and location rules, then present the updated result once.

Google Calendar lets an application provide its own event ID and notes that doing so can prevent duplicate creation when an operation succeeds in Calendar but fails before the client receives the response. Derive a stable, non-sensitive booking key for one confirmed intent, store it with the call record, and reuse it when checking an uncertain result. A retry policy without idempotency is a duplicate-booking policy.

Recheck availability immediately before the insert. Store the provider event ID, calendar ID, normalized start and end, time zone, attendee, and tool response. If conference creation is asynchronous, report it as pending until the API reports a completed state. Never turn an HTTP timeout into a cheerful spoken promise.

Run scenarios where the caller interrupts the read-back, asks for another date, disconnects after accepting, provides an invalid email, or requests two people at once. Test two agents competing for the final slot and a successful write followed by a network failure. Verify that the system produces one appointment or a clearly reviewable exception—not a guess.

Track confirmed bookings, duplicate attempts, slot conflicts, corrections, pending confirmations, cancellations, no-shows, human rescues, and complaints. Do not optimize booking count in isolation. An appointment that nobody intended to attend is not a conversion; it is future cleanup wearing a success label.