An AI receptionist tells a caller, “You're booked for Tuesday.” The caller hangs up. Dispatch opens the calendar and cannot find the appointment.
That is an example failure to test before launch. A convincing conversation can still leave the business without a usable booking.
The question I would ask during a buying demo is specific: what evidence does the agent need before it is allowed to say “confirmed”?
A booking click taught me to check the whole path
While checking the booking flow on my own portfolio, an embedded calendar failed to complete a test submission. The standalone calendar accepted a test booking. I verified the confirmation email, cancelled the appointment, and changed the website to use the hosted booking page.
That test established a working alternative. It did not establish the precise cause of the embedded failure, or prove that every visitor would have the same experience.
There was a separate measurement gap. A click on my booking button told me somebody opened the calendar. It could not tell me whether they finished booking. I connected signed Cal.com webhooks to PostHog, verified a confirmed booking and its cancellation, and marked the verification events as tests.
This was a test of my own website, not an HVAC customer result. The lesson carries over to voice agents: check the record produced by the conversation before treating the outcome as complete.
Give the agent distinct outcomes it can explain
For a service business, I would agree on these states before choosing the agent's confirmation wording:
| Scheduling state | What the caller can reasonably be told | | --- | --- | | Preferred time captured | “I've noted Tuesday morning as your preference.” | | Request awaiting approval | “Your request is pending. The team still needs to confirm the appointment.” | | Booking accepted by the scheduling system | “Your appointment is confirmed for Tuesday at 10.” | | Result unknown after a timeout | “I couldn't verify the booking. Let me check before we try again.” |
These are example phrases. The wording needs to match the business's actual scheduling and callback process. A callback promise is appropriate only when somebody owns that task.
Cal.com's documentation makes a similar distinction in its event model: a booking request can be pending, while a created booking can have an accepted status. My website's receiver checks the event type and accepted status before recording a confirmed booking. Cal.com webhook documentation
A timeout needs a check before another booking attempt
Consider an illustrative sequence:
- The voice agent asks the scheduling system to create an appointment.
- The scheduling system creates it.
- The response fails to reach the agent before its timeout.
The agent has an uncertain result. Repeating the creation request immediately could produce another appointment if the integration has no protection against duplicates.
I would want the integration to look up the original request or reuse an idempotency key where the provider supports one. The exact recovery depends on the scheduling API. If the state cannot be resolved, the agent should explain that uncertainty and create an actionable handoff through a verified fallback.
In a LiveKit agent, a tool can return information or a controlled error for the conversation to handle. The tool's description and error response should give the agent a truthful next step. That still needs testing against the real booking integration. LiveKit tool-loop guidance
Test the calendar and the caller's understanding together
Here is the focused test set I would bring to a pilot review:
- Normal booking: Does the appointment exist with the agreed date, time, and caller details when the agent confirms it?
- Delayed response: Does the agent check the outcome before attempting another booking?
- Approval required: Does the caller hear that their request is pending?
- Changed details: If the caller corrects the address, does dispatch receive the corrected address?
- Cancellation: Does the cancelled appointment disappear from the team's active workload, and is cancellation recorded separately in reporting?
Use fictional caller details. Keep the appointment reference and inspect the scheduling record after each test. Listen to what the caller was told as well: the database can be correct while the spoken promise is misleading.
For the timeout case, simulate the failure in a test environment. Deliberately breaking a live dispatch integration is not necessary to evaluate the behavior.
Measure confirmed bookings separately from requests
A useful pilot report distinguishes requests, accepted bookings, cancellations, and unresolved handoffs. Retried event deliveries should not inflate those totals. My webhook receiver gives repeated deliveries of the same booking event a stable event ID for PostHog deduplication.
Even a verified booking count is not recovered revenue. That requires connecting appointments to completed jobs and understanding which customers would have reached the business anyway.
If you are evaluating an AI receptionist, ask the vendor to show you the scheduling record after a difficult call. Then compare it with what the caller heard.
For a broader test set, use my HVAC voice-agent pilot checklist. If you want to scope after-hours call coverage around your own dispatch process, start with a missed-call audit.