The fallback decides, not the normal case

From the engine room – numbers, decisions and lessons from running support.

In every demo the bot runs the normal case: intent recognized, data fetched, answer delivered. Everyone can do that by now. What decides whether it gets accepted in production is the other moment: the one where something breaks. How gracefully a system fails isn’t a footnote in the design. It’s the actual design task.

The ground rule: plan B or escalation with context

A fallback isn’t a polite error message. The rule we build by: every technical failure gets one of two answers: a plan B, or an escalation to a human, with context.

And “every” means every: the API that doesn’t answer, the system in a maintenance window, the response that comes back looking different than expected. Covering the likely cases isn’t enough. In production the unlikely ones show up too, guaranteed.

A plan B is a second route to the same result. Where there isn’t one, a human takes over, with the history so far and everything the bot already checked, so the customer never explains anything twice. The opposite, the infinite loop of “Sorry, I didn’t quite get that,” is the fastest way to burn trust in the whole channel.

The forgotten safety net 1: the channel switch

The most common fallback shows up in no flow diagram: the customer gives up on the channel and picks up the phone. Once the bot runs on more than one channel, that raises an architecture question: how does the Voice-Bot know something was already discussed in chat? If every channel starts from zero, the customer tells their story a third time, and the channel switch, which was supposed to be their last resort, makes the experience worse.

The pattern that fixes it: park the context where every channel can find it, on the customer profile, for example as a User Field. On the call, the Voice-Bot checks whether a chat context exists and picks up from there. A memory that spans channels, for us the next stage of the build.

The forgotten safety net 2: statements that can’t be left sitting

Some lines in a chat aren’t requests, they’re signals: “I can’t pay my bills.” In a regulated environment, a statement like that can’t just vanish into the transcript, not even when the customer writes nothing after it. Especially not then.

Our solution: if a chat sits 15 minutes with no activity from the customer, that automatically triggers a use case in AI Agents Advanced, which we trained against our own criteria to spot critical statements in the chat transcript. On a hit, it fires a notification to our agents. A human takes a look, even when nobody is asking anymore.

In the note on resolution rate, silence was a success signal: no further contact, case closed. Here the same silence is an alarm. What silence means depends on the case. Making exactly those distinctions is fallback design.

The four questions for any bot design

1. Does every technical failure have a plan B or an escalation, not just the likely ones?
2. Does the context come along at handover, or does the customer start over?
3. Does the context survive a channel switch?
4. Is there a net for the statements that can’t be left sitting after the conversation ends?

The normal case wins the demo. The fallback wins in production.