Sooner or later the AI service your team relies on will be unavailable. It may be your vendor's outage, an expired payment method, a broken integration or a change you made yourself. The technical cause matters to the people fixing it. For you, as the person responsible for operations, the question is different: what do we tell people, who does the work in the meantime, and what comes first?
This article is about that second question. It does not cover stopping an agent that misbehaves; that is the subject of kill switches and incident response. Nor does it cover a longer-term change of vendor, model or price, which we discuss in a plan B for vendor changes. Here the agent is simply not available for a few hours or a few days, and the business has to keep its word.
Why the promise is the real problem
When an agent answers customers in seconds, the customer's expectation quietly becomes "seconds". The team's expectation changes too: nobody keeps the knowledge in their heads any more, and the volume that one agent absorbed would take several people.
So in an outage two gaps appear at once. The capacity gap is obvious: fewer answers per hour. The expectation gap is less visible and more damaging: customers still expect speed, and your staff do not know what they are allowed to say. Fixing the capacity is a matter of people and tools. Fixing the expectation is a matter of a clear, honest promise made early.
The rule we recommend: promise what the manual mode can deliver on a bad day, not on a good one. A slower answer that arrives on time is better than a fast answer that is missed.
Write the manual mode before you need it
For every process the agent handles, write a half-page manual mode. It should answer five questions.
- Who takes over? Name a role and a deputy, not a team. "Support" is not an answer; "the shift lead, and the account manager on call" is.
- With what? The tools, templates and access the person needs. If the agent was the only one with access to a system, the manual mode must say how a human gets the same view - within the limits of least-privilege access, not around them.
- What do they need to know? The answers the agent gave from memory or from documents. Point to the same sources. If those sources are unclear, the outage will show it; see preparing company documents.
- What is paused? Some work is not worth doing by hand. Name it openly: marketing replies, internal summaries, low-value lookups. Pausing on purpose is a decision; pausing by accident is a failure.
- What is the new response time? One number per type of case, agreed with the person who must deliver it.
Keep the document short enough to be read during the incident. One page per process, one index page on top, stored somewhere that does not depend on the service that is down. That last point sounds obvious and is forgotten surprisingly often.
If you already have clear rules for when the agent passes a case to a person, the manual mode is partly written: every handoff path in the human handoff rules is a path people already know how to follow.
Decide the order of cases
During an outage the temptation is to answer in the order messages arrive. It feels fair and it is usually wrong. Agree a simple priority order in advance, based on consequence and deadline.
- Urgent: harm or a hard deadline. A customer who cannot access something they paid for, a delivery that leaves today, a legal or contractual deadline, anything involving safety or money in motion. These go to a named person at once.
- Same day: a promise is at stake. Confirmations, scheduled changes, answers someone is waiting on to make a decision.
- Next working day: routine. Product information, status questions that have a self-service answer, general enquiries.
- Paused or bulk-answered. Questions that one message to everyone can address.
Two practical notes. First, the agent's own classification is not available, so someone must triage by hand; give them a one-line test for each level, not a long policy. Second, check whether a few customers are more exposed than others, for instance those with a contract that names a response time. The vendor contract article explains what your own supplier owes you; do not forget the mirror image, what you owe your customers.
What to say, and when
Silence is the most expensive choice. People can accept a delay if they know about it and know when they will hear more. Aim for three messages.
To the team, within the first half hour. Short and operational: the service is down, the manual mode is on, here is who does what, next update at a stated time. Without this, people either wait for instructions or start improvising their own versions of the process.
To customers, as soon as they are affected. A banner, an automatic reply on the channel, or a short message on the support page. Say what is happening, what the customer can expect, and how to reach a person for something urgent. Avoid technical detail and avoid blaming the vendor; the customer deals with you. If your agent presents itself to customers as an assistant, the principles in telling customers about the agent and offering a human alternative apply directly.
To individual customers with a deadline at risk. A personal message, ideally before they ask. This takes a few minutes per customer and often decides whether the relationship survives the day.
A template helps, because nobody writes well under pressure. For example:
We are currently handling requests without our automated assistant, so replies may take up to four working hours instead of a few minutes. If your request is urgent, call us on the number below and mention this message. We will update this notice by 14:00.
Do not promise a restoration time you do not control. Promise the next update time instead; that you do control.
Keep the promise small
It is common to over-compensate in the first hour: "we are on it, answers within the hour". If the queue is long, that promise breaks by lunchtime and you have two problems instead of one.
Before you publish a response time, do a quick calculation. How many cases normally arrive in an hour? How many can the available people handle by hand? If the first number is twice the second, the honest promise is longer than your instinct says, or the paused list needs to be longer. It is better to announce a longer time and beat it.
Protect your people
Rotate the people on the phones, make clear who decides exceptions, and say openly that the manual mode is slower and nobody is expected to match the agent's speed. People who feel the agent was used as a stick during the outage will not trust it when it returns; see explaining the agent to employees.
Planning the return
Switching the agent back on is a second incident if it is done carelessly. The queue that built up contains duplicates, half-finished conversations and cases a human has already answered. If the agent picks all of this up at once, customers receive two replies or a contradictory one.
A sensible return has four steps.
- Confirm the service is stable. Wait for a period you set in advance, not for the first successful test.
- Close the manual cases first. Mark which cases a person handled, so the agent does not answer them again.
- Re-enable gradually. Start with low-risk categories, watch the output for an hour or two, then widen. This is the same logic as in a staged rollout with a rollback criterion.
- Tell people it is over. Customers who were told about the delay should hear that normal service resumed; the team should know the manual mode is off.
Learn from it afterwards
Within a week, hold a short review. Count the cases that came in, how many were handled by hand, how long the real response took against the promise, and which customers complained. Note which parts of the manual mode worked and which were missing. Update the one-page documents, then check whether the outage showed that the business depends on the agent more than you thought, which is a useful input for the next monthly review.
A one-hour drill
You do not need a major exercise. Once, before a real outage, gather the people named in the manual mode and run this.
- Announce a pretend outage of two hours at a busy time.
- Ask the named people to open their one-page procedures and find what they need within ten minutes.
- Give them five realistic cases of different priority and ask them to place each in the order of work and say what they would tell the customer.
- Write down every point where somebody asked "who decides?" or "where do I find it?".
You will probably find that a login does not work for the deputy, that the notice template lives on the system that is down, and that nobody knows who writes to customers. All three are easy to fix on a quiet Tuesday and painful to fix during a real outage.
Where to start
Pick the one process where an hour of downtime would hurt most. Write its manual mode on one page, name the person and deputy, and agree a response time you could meet on a bad day. Draft the customer notice and store it outside the service. Then schedule the drill. That is a morning of work, and it turns an outage from an improvisation into a procedure.
