An AI voice agent should reschedule or cancel an appointment only after verifying the caller's authority, identifying the exact booking, confirming the requested change and receiving a verified result from the scheduling system. A spoken request, an available slot and a successful calendar update are three separate events.
The difficult case is not “book Tuesday at two.” It is “move my appointment, unless that means I lose the appointment I already have.” Design the integration to preserve a recoverable state throughout that change.
Define which changes the agent may make
Write a policy for supported appointment types, locations, staff members, notice periods and exceptions. Let the scheduling service enforce those rules. A prompt can explain them to the caller, but should not be the only control preventing an invalid change.
Use the business-approved verification method before disclosing private appointment details. Caller ID alone should not automatically establish authority. If the caller acts for another person, use an approved representative workflow or hand off.
Retrieve the booking before discussing a replacement
Match the request to a stable appointment identifier. Ask a clarifying question if several records qualify. Avoid reading a list of private appointments to an unverified caller.
Retrieve the current booking version, status, time zone and change eligibility. Keep the scheduling system as the authority for availability. An earlier transcript or a cached calendar result may no longer describe the current booking.
| Situation | Permitted next step | What the agent should avoid |
|---|---|---|
| One verified eligible booking | Check replacement options | Assuming a new slot is reserved |
| Several possible bookings | Clarify within the verification policy | Changing the first matching record |
| Booking changed by staff | Refresh and reconfirm | Overwriting the staff change |
| Write timed out | Reconcile the actual record | Claiming success or retrying blindly |
| Cancellation exception | Route to authorized staff | Inventing a fee waiver |
Use explicit confirmation and concurrency control
- Offer a valid replacement. Include the date, local time, time zone, location and relevant service details.
- Explain the specific action. Distinguish moving an appointment from adding another one. Disclose only verified policy consequences.
- Obtain affirmative confirmation. An interrupted “yes, but…” needs clarification before execution.
- Validate the current version and slot. Execute through a controlled server-side operation. If the record changed, refresh and ask again where the change affects the decision.
- Verify the final state. Read or otherwise confirm the committed result before announcing completion.
For a concrete implementation pattern, Google Calendar documents ETags and If-Match for conditional updates and deletions. A mismatched version returns a precondition failure. This protects against overwriting a changed event; it does not by itself prevent two different events from occupying the same slot. Slot capacity needs its own scheduling control.
Preserve the original when a change requires multiple writes
Prefer a scheduling platform's supported reschedule operation when its semantics meet your requirements. If changing an appointment requires separate creation and cancellation operations, document the intermediate states and compensating actions.
Do not automatically delete the original booking before securing the replacement. Equally, do not treat a provisional replacement as final if cancelling the original later fails. Hold, commit and compensation behavior depends on the scheduling API; validate it in a test environment.
Illustrative example: a caller wants to move a Thursday appointment to Friday. The server reserves an eligible Friday slot, but the operation returns an uncertain result. The agent says the change is still being checked. A reconciliation process discovers that Friday was committed and Thursday released, then records that result. It does not create a second Friday appointment.
Make cancellation a separate action
Confirm the exact appointment and that the caller wants to cancel it. For recurring bookings, distinguish one occurrence from the whole series. Preserve the requested scope in the execution record.
If a charge or refund depends on an exception, use staff review. The agent should not turn an estimated policy consequence into a confirmed payment outcome.
Test what happens after the caller disconnects
Include hang-up before confirmation, hang-up during a write, duplicate requests, staff edits, stale availability, repeated calendar events and a failed notification. The record should distinguish appointment status from notification status: a failed text message does not necessarily mean a failed reschedule.
Measure verified correct changes divided by all attempted changes, and review unresolved outcomes separately. Do not count the agent saying “done” as evidence.
Use the broader AI receptionist implementation guide for phone routing and initial setup. For a rescheduling pilot, begin with one appointment type and prove its cancellation, concurrency and recovery paths before adding more.
