You need a fallback for each failure layer, not a single generic outage statement. Test what happens when the agent is unavailable, when calls cannot reach it and when it can speak but cannot complete the task.
Twilio documents fallback webhooks and recommends separating fallback infrastructure from the primary failure domain. Its guidance also distinguishes application, network and telephony components. (twilio.com)
Our recommended outage matrix is:
| Failure | Required operating response |
|---|---|
| Voice-agent service unavailable | Route to the approved human service or explicit alternative. |
| Scheduling system unavailable | Stop confirming bookings; create controlled follow-up if possible. |
| Write result uncertain | Reconcile before attempting another write. |
| Human destination unavailable | Invoke the no-answer procedure without a transfer loop. |
| Capacity limit reached | Apply a documented overflow or rejection policy. |
| Billing balance exhausted | Alert an owner and preserve an alternative route. |
Billing is an operational dependency too. Vapi’s documentation says that a subscription with no credits and no automatic reload cannot start new calls or other billable usage until funded. (docs.vapi.ai)
Test failure deliberately in a controlled environment. Record how to disable the agent, who is authorised to do so and how quickly the original call route can be restored.