Service outage: what should your AI chat tell customers?

A customer cannot complete a booking and opens the chat. Following the usual instructions, the assistant recommends the very form that is currently broken. The answer may read perfectly, yet it sends the customer into another failed attempt. Good FAQs alone are not enough during an outage.

Without a verified, current source, an AI chat does not know whether a service is working. The following is a practical approach for a business or municipality that wants to communicate clearly during a problem. It does not describe automatic monitoring built into Informio.

Confirm the status before drafting the answer

Assign someone to approve the public notice. A technician may be working on the cause, but someone also needs to track what customers are being told. Google SRE likewise distinguishes incident command, technical operations and communications.

A small business may combine these roles. What matters is knowing who confirms the scope of the problem and who updates the website, chat sources and support staff. A guess in an internal conversation is not an approved public statement.

One notice should answer five questions

Prepare one approved public source and decide where customers will find its current version. Include:

• What is not working: the specific service and observable problem, not vague “technical difficulties”.
• What remains available: only options you have actually checked.
• When the status was confirmed: the date, time and time zone, so an old message does not look current.
• When the next information is due: a next-update time, not an invented repair deadline.
• What the customer can do: a verified alternative or contact, including support availability.

Atlassian's outage templates identify affected services and the next-update time. If you do not know when service will return, say so. Publish an update even if you have no new findings yet.

A hypothetical example: a broken booking form

Imagine a fictional business that has confirmed a form failure and checked that telephone bookings work. Its approved notice could read:

Illustrative message, not a real outage: On 22 October 2026 at 09:15 CEST, we confirmed that the website form cannot complete booking submissions. You can arrange a booking by calling the business during today's opening hours. We do not yet know when the form will be restored. We will publish another update today at 10:00 CEST.

The chat can briefly explain this information and link to its source. It must not add that a booking has been created, that all other services work or that the issue will be fixed by ten. The update time is not the service restoration time.

A website update does not necessarily update the chat

For an assistant using indexed sources, also check that those sources have been processed successfully. Changing a website notice does not by itself confirm that the chat is using the new information. Test both a fresh conversation and an existing one containing the earlier advice.

If the current status is unverified, the answer should acknowledge that uncertainty and direct the person to the designated official notice or support. Automatic status monitoring, expiry of notices and connections to operational systems need a separate design. Do not assume they exist simply because your website has an AI chat.

Run through five test questions before use

1. “Why is the form not working?” The answer must not invent an unconfirmed cause.
2. “Will it be fixed by ten?” It must distinguish the next message from a repair deadline.
3. “So my booking is confirmed?” It must not say yes without checking that particular booking.
4. “What should I do now?” It should offer only a verified procedure and an available contact.
5. “Does yesterday's warning still apply?” It must not present old information as current without verification.

If the website or widget itself is unavailable, the chat cannot help. Choose another available communication channel in advance and assign someone to update it. Do not promise an immediate operator connection unless you can provide one.

Verify restoration as carefully as the outage

Publish a restoration notice only after checking the relevant service. Update the assistant's sources too, confirm processing and repeat the test questions. Older notices may remain in the history, but must be clearly distinguished from the current status.

Then review where answers misled customers and which step was missing from the procedure. To prepare this communication process for your website, arrange a consultation with Informio. You can try the AI chat separately; any connection to live service status needs its own assessment.