A caller answers a question, waits, and hears nothing. The AI voice agent has not misunderstood the request. It has stopped responding. That distinction matters because another prompt will not fix a broken connection.
Configure the failure path before launch. Decide what the caller should hear, select a Dynamics 365 fallback that can actually reach help, rehearse the failure, and keep evidence that a person or an honest ending followed. Silence is not a fallback.
Microsoft Update 26092 says Dynamics 365 Contact Center now has more resilient messaging and routing continuity when an AI agent becomes unresponsive. That is useful protection, but an operator still has to choose the customer promise and prove the configured destination works.
Treat silence as a service incident
An intent fallback happens when the agent cannot understand what the caller wants. A runtime failure is different. The caller may have already shared a name, order number, or reason for calling when the agent becomes unavailable because of a system or network problem.
- 1Define the promiseDecide what the customer will hear and what help is genuinely available.
- 2Match action to riskChoose escalation, external transfer, wait music, or a clear ending deliberately.
- 3Verify the destinationConfirm the number, queue, staffing, and permissions before relying on it.
- 4Rehearse the failureMake the AI agent unavailable in a controlled test and follow the customer path.
- 5Monitor recoveryReview fallback calls, failed destinations, ownership, and the final outcome.
Do not make the caller diagnose that difference. Give them a short, truthful message and a next step. Internally, preserve the point of failure, the route attempted, and whether anyone accepted the call. The receiving person should see the available context in a shared team inbox instead of asking the customer to reconstruct the entire exchange.
The severity depends on the job. A silent call about store hours is inconvenient. A silent call during account access, payment help, or a time-sensitive service request needs a faster human path. Set the fallback according to the consequence of delay, not according to the easiest menu choice.
Choose the promise before the setting
Microsoft's IVR fallback configuration guide documents four actions for cases where the customer cannot reach the IVR agent or a system or network failure occurs. Each action makes a different promise.
| Built-in action | Use it when | Check before launch | Evidence to retain |
|---|---|---|---|
| Prompt and hang up | No responsible live destination exists and ending is safer than more waiting | The message explains that the call is ending and gives a realistic next step | Prompt played, call ended, follow-up owner if needed |
| Prompt and transfer to external number | A separate staffed service can accept the call | The approved E.164 number answers during the promised hours | Transfer attempt, answer result, destination owner |
| Prompt and escalate | An internal representative path is available | Routing, capacity, and permissions allow the handoff | Escalation event, accepting owner, final state |
| Wait music and escalate | A short staffed wait is acceptable | Music begins, the queue can answer, and long waits have an owner | Wait start, acceptance time, abandonment or recovery |
Do not hide uncertainty behind cheerful wording. If support will review the request tomorrow, say so. If no employee can take the call, a clean ending with a clear alternative may be kinder than indefinite music.
A good AI operating model gives automation limited authority and makes the human boundary visible. The fallback is that boundary under failure.
Prove the destination can answer
A configured transfer is not the same as a successful recovery. Check the external number in E.164 format when that option is used. Confirm that the internal queue is open, at least one appropriate representative can receive the work, and the caller is not sent into another automated dead end.
Then write one owner beside each dependency. Telephony may belong to an administrator, staffing to a supervisor, and the customer message to a service owner. A controlled automation workflow works better when those responsibilities are explicit.
Run the first test with synthetic customer details. Start a real test call, move through several normal turns, then make the AI agent unavailable in the controlled way your environment supports. Listen as the customer would. Did the recovery prompt play once? Did the route match the chosen action? Did the destination answer? Was the prior context available, or did the representative know only that a call arrived?
Repeat the rehearsal outside staffed hours. Also test an unavailable external number, a full or closed queue, and a caller who disconnects during the prompt. Those cases show whether the fallback itself can fail safely.
Keep a compact failure record
For every rehearsal, record the test time, channel, AI agent version, last successful turn, failure point, message played, fallback action, destination, acceptance result, final owner, and repair decision. Keep personal or payment data out of the test. Access to failure evidence and routing settings should follow your security controls.
Microsoft says the out-of-the-box Fallback calls metric is available in the Omnichannel historical bot dashboard and real-time analytics report. Use the metric as a signal, not a verdict. A higher count might reveal an outage, a bad dependency, or simply more traffic. Sample the underlying conversations and separate customer hang-ups from confirmed system failures.
The named recovery owner should review failed destinations, repeated failure points, and calls that ended without an accepted next step. They should be able to pause a risky route, move work manually, and trigger a retest after the repair. Support operations need that live ownership while the customer record keeps durable context.
DripTell can keep cross-channel ownership, notes, and follow-up visible after a handoff. It cannot make an unstaffed destination answer. The promise still has to match real coverage.
Frequently Asked Questions
What should a caller hear when the AI agent fails
Use a short message that says the automated service cannot continue and states the real next step. Do not imply that a person is joining unless the configured route can reach one.
Which fallback action is safest
There is no universal winner. Escalation is appropriate when a staffed internal route exists. External transfer needs a verified E.164 destination. Hang-up can be honest when no live path exists. Wait music works only when the queue can answer within an acceptable time.
How do we test an unresponsive agent
Use synthetic details, complete a few normal turns, trigger a controlled agent failure, and observe the prompt, route, destination, context, owner, and final state. Repeat with the destination unavailable.
Where can we monitor failures
Microsoft documents a Fallback calls metric in historical and real-time Omnichannel bot reporting. Pair that count with conversation evidence and a named review owner.
Want help applying this guide?Ask the DripTell team
From reading to action
Want help applying this to your business?
Share your details. We will read the article you are on and start with a useful answer for your team.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy
