The caller chooses a time. Your AI receptionist repeats the details and says the appointment is confirmed. The call ends. Later, your team opens the calendar and finds nothing.
The caller now has a promise your business cannot see.
If a Retell or Vapi booking integration is not working, the recording alone will not tell you what happened. The agent may have understood the request perfectly while the action failed somewhere between its tool call and your scheduling system.
I would start with one failed call and follow the booking all the way through. What did the caller request? What did the tool send? What did the calendar actually save? What result did the assistant receive before it said “confirmed”?
Those four questions turn a vague complaint about the agent into an integration problem you can investigate.
Find the first missing piece
A booking workflow has several separate steps:
- The caller chooses a service, location and time.
- The system checks the relevant availability.
- The assistant asks a tool to create the appointment.
- The scheduling system processes that request.
- The tool returns the outcome to the assistant.
- The assistant explains that outcome to the caller.
The evidence for each step is different. A transcript proves what was said. A tool log shows what was requested. A saved appointment shows what changed in the scheduling system.
Start with the calendar your staff actually use. Search for the appointment, including nearby dates and times. Check the calendar account and location. An event saved in a test calendar or shifted by a time-zone conversion can look like a missing booking.
Then work backwards. If there is no appointment, look for the creation request. If there was no creation request, look for the tool call. If the tool ran, inspect its downstream response and what it returned to the assistant.
| What you observe | Where I would look first |
|---|---|
| The agent confirms a booking, but no booking tool ran | Conversation instructions and the path to the tool |
| The tool ran, but the calendar received no creation request | Workflow branches, field mappings and early responses |
| An event exists in the wrong calendar or at the wrong time | Calendar identity, date parsing and time-zone handling |
| The calendar rejected the request, but the agent said “confirmed” | Error handling and the result returned to the assistant |
| A workflow is green, but the appointment is missing | Whether that status means receipt, queueing or completed creation |
| One request produces two appointments | Retries, repeated tool calls and duplicate protection |
You do not need to replace the entire agent to investigate these failures. You need to locate the first point where the evidence stops matching the promised outcome.
A green webhook can hide an unfinished booking
Consider this illustrative failure sequence:
The caller asks for Tuesday at 3 p.m. The assistant calls a booking tool. An automation receives the request and immediately responds with “success.” A later step attempts to create the appointment, but its calendar connection has lost write access. The caller has already heard a confirmation.
Everything before the calendar write worked. The response arrived too early to describe the actual outcome.
For a confirmed booking, I would design the tool around the completed action: the correct scheduling system has accepted the appointment, and the integration has recorded its identifier and relevant details. If the workflow is still waiting for another step, the result should say that the request is pending.
This distinction matters in Vapi. An asynchronous Function tool gives the assistant an immediate success result and does not use the eventual webhook response as the tool result. A synchronous Function tool waits for the response. For a booking that needs an immediate confirmation, that execution choice needs to match the business workflow.
Retell custom functions let the agent call your endpoint and use its response during the conversation. The endpoint and the conversation instructions still need to communicate the business outcome clearly.
A useful response separates at least three outcomes:
- Confirmed: the appointment exists, with a reference and the saved date, time and location.
- Not booked: the action failed or the requested slot could not be reserved; offer a next step.
- Pending verification: the final outcome is unknown; avoid another blind write or a definite confirmation.
The exact response format depends on the tool you use. Your integration must translate these business outcomes into the provider’s expected format. Changing a field in the backend is only part of the repair; the assistant also needs to react to it correctly.
Treat the chosen time as a business rule
“Three o’clock next Tuesday” needs context. Which location? Which time zone? Which Tuesday, based on the date of the call? How long is the appointment, and which member of staff can take it?
I would resolve those details before submitting the write. For a business with several locations, derive the scheduling context from trusted configuration and confirm the local appointment time with the caller.
Google Calendar’s event creation API requires start and end values. Its date-time fields need an offset unless a time zone is explicitly supplied. That is a concrete reason to inspect the submitted values instead of relying on how the transcript describes the time.
Availability also changes. A slot can be free when the assistant offers it and occupied before the caller agrees. The booking operation needs a conflict policy and an appropriate reservation mechanism for your scheduling system. A plain calendar event write should not be assumed to prevent overlapping appointments.
When a conflict occurs, the agent should explain that the slot is no longer available and offer fresh options. The test is whether the intended appointment can be accepted under your scheduling rules.
Handle the uncomfortable case: the request timed out
A timeout leaves a question: did the calendar save the appointment before the connection failed?
Retrying immediately can create a second booking. Declaring failure can also be wrong if the first appointment already exists.
I would give each logical booking request a durable reference, record its progress and reconcile uncertain outcomes before issuing another write. The duplicate-protection mechanism depends on the scheduling API and your backend, but it should survive a repeated request for the same action.
A changed appointment is a new decision. If the caller switches from Tuesday to Wednesday, the system needs to understand whether it is replacing an existing reservation or making the first successful booking. Reusing a reference without tracking that change can hide another error.
The caller needs an honest, useful response while the outcome is being checked. For example:
“I’m checking whether that appointment went through. If I can’t confirm it, I can send the request to the team for follow-up.”
That wording is an example of a fallback, not a transcript from a client incident. It should only be used when the promised follow-up path exists. A callback request needs its own saved record and a destination your staff can review.
Test the repair against the calls that can hurt the business
A single successful test call is a starting point. Before accepting the repair, I would agree on a small set of scenarios and check both the conversation and the resulting records.
| Test scenario | What should be verified |
|---|---|
| A valid booking | One appointment in the correct calendar, with the requested details |
| The slot becomes occupied | No false confirmation; fresh alternatives are offered |
| The calendar rejects the write | No confirmed-booking claim; a working recovery path is offered |
| The write completes but the response is lost | The outcome is reconciled without an unintended second appointment |
| The same action is requested twice | Duplicate protection works for that logical booking |
| The caller changes the date | The final saved appointment matches the change, with no abandoned duplicate |
| The requested time crosses a daylight-saving change | The saved time and the spoken local time agree |
| The caller asks for a person | Transfer or callback handling preserves the details staff need |
Keep enough evidence to follow the transaction: the call reference, tool request, downstream response, appointment reference and the result returned to the assistant. Remove credentials and unnecessary caller data from any diagnostic material you share.
This gives your team a way to verify the fix and investigate the next failure without replaying every call from scratch.
Bring the failed workflow, and we can scope the repair
I develop voice AI integrations and the software around them: business APIs, backend rules, operator interfaces and SaaS workflows. My work includes Slivo’s Retell and WooCommerce integration and 24PetLine’s voice reception and call-management product.
If your assistant sounds convincing but bookings, CRM updates or staff handoffs fail, bring the current setup and one representative example. The useful starting point is the expected result, the relevant tool or automation and the point where the actual outcome differs.
You can explore my Retell AI development and integration service or Vapi AI development service, then send your project brief.
We can define a focused repair around the failing path and agree on the evidence that will show it works.