When the AI assistant is down: designing what answers instead

What answers while the assistant is down decides whether the company looks resilient or absent, and that answer should be a designed path, not improvisation.

Every assistant that answers customers will have quiet hours. The provider has a bad afternoon. A key rotates and the old one stops working. An update to the flow breaks a step nobody touched. The customer on the other end of the conversation knows none of this and does not care to learn it: from where they sit, the company simply stopped speaking.

What happens in that window is not a technical footnote; it is the moment the company's character becomes visible. An assistant that answers well most days has quietly promised reliability, and the outage is when the promise is either kept or read aloud as empty. The same downtime can make a company look resilient or look absent, and the difference is rarely the severity of the fault. It is what answered while the fault was live.

The improvised versions are recognizable. The assistant goes silent and the conversation sits unanswered. Or it responds with an avalanche of template apologies, variations of the same nothing, and the customer learns the company's voice is a recording. Or the failure is announced in internal jargon that reads like the company complaining about its own plumbing in front of the people who trusted it.

The designed alternative is plain: a human receives the conversation with its history intact and speaks in the company's voice. One person, one message, no cascade. And because we believe an assistant should say it is an assistant, the handover needs no theater: a person can simply say the assistant is down and they have taken over, which is both honest and, in practice, the most reassuring sentence available in that moment.

Designing the path before it is needed is the whole work. Decide who picks up, make sure the conversation history travels with the handover so the customer never repeats themselves, agree on what the first message says, and rehearse it once so the first live run is not the rehearsal. A silent failure the customer discovers on their own beats a loud failure the customer must read a paragraph about.

We run our own funnel on an assistant we built ourselves, so this page is written from inside the problem, and the fallback is part of the design rather than a reaction to an incident. Provider status pages, integration details, and platform specifics belong to each provider's documentation, and we route them there. Guidance, not guarantees: systems fail, and what remains under your control is what answers when they do.