Hardening an AI Voice Booking Workflow Against Call Failures

Failure mode 01 Notifications hinged on caller ID

The system decided whether to notify staff about a booking based on the caller's phone number. That meant the notification logic was tied to identifying the caller correctly — something the AI voice layer was not guaranteed to do. If the caller ID was unavailable, unrecognized, or mapped to the wrong contact, the notification was skipped even when the booking itself had succeeded. The booking existed, but nobody was told. In a business where staff follow up on incoming bookings, an undelivered notification was effectively a lost lead.

Failure mode 02 Bookings lost to early hang-ups

The AI voice agent could hang up on a call if a caller greeted it incorrectly or if the conversation wandered from the expected script. When that happened, the caller's intent — including the desire to book — was discarded along with the call. There was no fallback. A caller who said something unexpected was simply dropped, and the system had no mechanism to recover the interaction or route it to a human. From the business's perspective, the call never happened. From the caller's perspective, the business had hung up on them.

Failure mode 03 No written go-live gate

The AI's behavior — including how it handled greetings, questions, and booking details — lived in the voice agent's configuration. There was no documented, testable specification of what the AI was supposed to do before it was allowed to handle live calls. Changes to the agent's behavior were not validated against a written standard. The business could not easily verify that a new version of the prompt or conversation flow still met the requirements for capturing a booking correctly.

Failure mode 04 CRM state drifted from call reality

Bookings were written to the CRM through a series of steps that could fail partway. A call could succeed, the notification could fire, and the CRM write could still fail — or the CRM could be updated when the call had not actually produced a confirmed booking. The workflow had no strong link between what actually happened on the call and what was recorded in the CRM. When things went wrong, the CRM could hold records that did not match the call transcript, and there was no straightforward way to see which records were trustworthy.

Decision 01 Separate the transcript from the trigger

One of the most important changes was separating the AI voice agent from the decision logic. Previously, the AI call itself carried too much responsibility: the transcript event was both the record of the call and the trigger for notifications and CRM writes. Octacer moved the decision logic out of the AI call flow and into the orchestration layer. The AI's job became to conduct the conversation and produce a structured transcript. The workflow's job became to interpret that transcript, decide what had happened, and act accordingly. This meant the AI could make conversational mistakes without automatically breaking the downstream systems.

“The AI narrates; the workflow decides.”

Decision 02 Hardened notifications with retry and evidence

The notification path was rebuilt so that an undelivered notification did not mean a lost booking. Instead of a single attempt, the workflow now retries delivery and confirms success before moving on. If a notification cannot be delivered after retries, the workflow marks the booking as requiring manual follow-up rather than silently dropping it. The system keeps evidence of whether each notification was delivered, so staff can see at a glance which bookings need attention.

“A clean retry beats a broken promise.”

Decision 03 Introduced a written go-live gate

Octacer introduced a documented specification of the AI's expected behavior, tied to the conversation flow, before the agent is allowed to handle live calls. The specification defines what counts as a successful booking call, what the AI must capture, and how it should handle common edge cases. This go-live gate gives the business a way to validate changes to the AI voice agent before exposing them to real callers. It also means the workflow expectations are written down — the AI layer, the notification logic, and the CRM write all operate against the same defined standard.

“Never go live without a testable standard.”

Decision 04 Made the CRM write conditional on confirmed intent

The CRM write was changed so that a booking is only recorded when the workflow can confirm — from the structured call outcome — that the caller actually intended to book. Conversational ambiguity no longer results in a phantom CRM record. The workflow now distinguishes between states: a completed booking, a call that did not produce a booking, and a call that needs manual review. Each state has a defined path, and only the first one writes to the CRM automatically.

“Only write what the call actually produced.”