An AI agent fallback plan decides what your customers see on the day your model provider goes down, and that day is coming. The bot doesn’t run on your servers. It runs on someone else’s model, through someone else’s API, and when that API fails, every contact your AI was handling lands on your human team at once. If you haven’t worked out how many contacts that is, you’re running a queue with a hidden cliff in it.
This is the oldest problem in support wearing new clothes. In 2008, it was a vendor outage that broke the SLA chain for BlackBerry users and the help desks behind them. In 2026 it’s the model behind the chat window. The vendor is different. The arithmetic and the conversation with your customer are almost exactly the same.
What happens when the model provider has a bad day?
Look at June 10 last year. OpenAI’s status page for that incident logs elevated error rates opening at 2:36am and resolving at 6pm the same day, more than 15 hours end to end. The affected components list includes the APIs that customer-facing products are built on: Chat Completions, Responses and Realtime among them. It was marked a partial outage, not a total one. For a support bot, partial is often worse, because some conversations work and some fail halfway through.
I’m not singling OpenAI out. Every model provider has had incidents, and so has every cloud they run on. The point is that a 15-hour window of elevated errors is now a documented, ordinary event in the AI supply chain, and it’s easy to write a support plan that treats it as if it can’t happen. A plan that assumes the bot is always there is a plan with no answer for the busiest afternoon of the quarter.
How many contacts land on your team when the AI agent goes down?
Work it out before it happens. Build a workbook called “AI fallback” with one sheet. Column A holds labels and column B holds values, one per row, so anyone can read it top to bottom. Every number below is a made-up example. Swap in your own.
In B2, put your daily contact volume: 1,200. In B3, put the share your AI agent resolves without a human, as a decimal: 0.45 for 45%. In B4, type =B2*B3. That multiplies the volume by the share, so 1,200 x 0.45 = 540 contacts a day that never reach a person. In B5, put the share of the day’s volume that arrives during a typical outage window. If a six-hour outage covers your busiest hours, half the day’s contacts might arrive inside it, so B5 is 0.5. In B6, type =B4*B5: 540 x 0.5 = 270 contacts that would have gone to the bot and now come to your team.
Now turn contacts into work. In B7, put your average handle time in minutes: 7. In B8, type =B6*B7/60. That multiplies the contacts by the minutes each takes and divides by 60 to get hours: 270 x 7 = 1,890 minutes, and 1,890 / 60 = 31.5 hours of extra work. In B9, put the outage window in hours: 6. In B10, type =ROUNDUP(B8/B9,0). B8/B9 is 31.5 / 6 = 5.25 people working flat out for the whole window, and ROUNDUP with 0 rounds that up to the next whole number, 6, because you can’t schedule a quarter of a person.
That 6 is the floor, not the answer. It assumes your people do nothing but these contacts, with no breaks and no waiting time between calls. Put the 270 contacts through an Erlang C calculator with your real service level target and the number goes up. Even the floor tells you something useful, though. If your normal shift has no slack of six people anywhere, an outage at the wrong time will break your service level, whatever the bot vendor’s SLA says.
Gartner’s view, for what it’s worth, is that none of the Fortune 500 will have fully eliminated human customer service by 2028. I’d add a practical reason to theirs. You need the humans for the day the model isn’t there.
What should the bot do when its model stops answering?
Fail out loud, and fail towards a human. The worst version of an AI outage is a chat window that keeps saying “thinking” until the customer gives up. The second worst is a bot that answers half a question and then goes quiet. Both look like your company ignoring someone, and the customer won’t know or care that the cause was three suppliers away.
Ask your vendor, or your own engineers, three plain questions. How quickly does the bot detect that the model is failing? What does the customer see when it does? Where does the conversation go next? The good answer is a timeout measured in seconds, a short message saying the assistant isn’t available, and a handover to a human queue, a callback request or a contact form, with whatever the customer already typed attached.
That last part matters more than it sounds. When I looked at what reaches your humans when AI agents sit in front, the handover was where most of the customer’s patience got spent. An outage is the same handover at scale. If the customer has to repeat themselves to a person after the bot failed, you’ve charged them twice for one problem.
Some teams also keep a simpler second path: a rules-based menu, a set of top-ten answers or a different model provider behind a switch. None of these needs to be as good as the main bot. It needs to be available when the main bot isn’t, and someone on your team needs to know where the switch is.
What does the AI vendor’s SLA actually promise you?
Usually less than your customer SLA assumes. Read the contract for the AI product, and then read the terms for the model it runs on, if the vendor uses a third-party model. You’re looking for three things: the availability number, what counts as “unavailable,” and what happens if they miss it. A “partial outage” with elevated errors may not count as downtime at all.
Then put the AI vendor in your dependency list next to every other supplier. If the bot is part of how you meet your first-response promise, its failure is a failure of that promise. I’ve argued for years that you shouldn’t sell a commitment that your suppliers can’t back. An AI agent is a supplier. It just happens to talk to your customers directly.
I thought the risk with AI agents was bad answers. Bad answers are a risk. No answers at all, for fifteen hours, is the one most plans forget, and it’s the easier one to plan for.
Who on the team runs the fallback?
Name one person per shift. Their job, when the model fails, is to switch the bot to its fallback mode, post the customer message, and pull people off other work into the queue. They don’t need to understand the model. They need to know the three steps, and they need the access to do them without waiting for engineering.
Write the steps down and keep them short enough to fit on one screen. Then test them. Pick a quiet hour, switch the bot off on purpose for 15 minutes, and watch what happens to the queue, the handover and the customer message. You’ll learn more from that test than from any vendor slide about uptime. Show me a team that has switched its own bot off on purpose and I’ll show you a team that won’t panic when someone else switches it off for them.
After any real outage, review it the same way you’d review any other vendor failure. When did we know? How long until customers were told? How many contacts reached people, and did the handover keep their history? Then update the AI fallback sheet with the real numbers instead of the estimates.
What would I do this month?
Build the sheet with your own volume, resolution rate and handle time, and find your floor number. Compare it with the slack in your busiest shift. If the slack is smaller, you’ve found the gap, and you can decide whether to close it with people, with a better fallback path or with a different promise to customers.
Then run the 15-minute switch-off test. It costs one quiet hour and a little nerve.
The model will go down one day. Your customers will judge you on what happens in the next five minutes, not on whose fault it was.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
