Drafting the Message Sent When an AI Feature Breaks

This is the core script. Fill the brackets from the status page, delete anything you cannot source, and keep it short enough to read on a phone.

Subject: [Feature] issue: we are aware and investigating

Hi [name],

Thank you for flagging this. We are aware of an issue affecting
[feature, in the customer's words], and our team is investigating.

What this means for you right now:
[one sentence on impact, copied from the status page]

For updates, please check our status page at [link]. We will post
the next update there [cadence from the page, e.g. within 30 minutes].
We will share more information there as soon as it is available.

If the status page has an "Identified" update, say so and stop there.
If it has an ETA, quote it exactly and attribute it. If it does not,
do not invent one.

Thanks for your patience,
[name], [team]

Three properties make this template safe. It names the feature rather than the model or the vendor, so it survives re-architecture. It routes the customer to a page they can subscribe to, which is the mechanism Atlassian recommends for pushing updates without pulling engineers away from the fix (Atlassian). And it gives a next-update promise only in the form the page already committed to, which is the same cadence discipline incident.io recommends: a rigid update cadence, held even when there is no news (incident.io on communication practices).

For AI features specifically, add one line to the internal notes, not the customer reply: whether the failure is behavioral (wrong or refused output) or availability (no response at all). Behavioral failures generate far more tickets per affected user, because every bad output looks like a separate bug.

The quickest way to train a support team is a two-column contrast. Use it as a checklist in the macro and in the onboarding doc.

The right-hand column is not about politeness. Each entry creates a commitment that someone else has to keep, in a situation where nobody yet knows the shape of the fix. The open status page guide makes the ETA case directly: give a conservative estimate or no estimate rather than one you cannot meet (openstatus). Webalert's template library states the same rule from the other side: do not wait for root cause before acknowledging known user impact, but do state the affected feature, current phase, confirmed impact, timestamp and next-update time (webalert on status update templates).

Two of those prohibitions deserve their own paragraph.

Do not promise a time. An agent who says "about 20 minutes" has converted a support reply into an SLA. If the fix takes three hours, the customer's next message is about the broken promise, not the broken feature, and the agent has handed the incident commander a second problem.

Do not name a cause, especially a vendor. "The model provider is having an outage" is tempting because it moves blame off your team. It also publishes an unverified claim about a third party, and if the real cause turns out to be your retry logic, you have made a false statement to every customer who got that reply. NIST's containment and eradication phases exist precisely because many parts of an incident are only understood once responders are in the middle of it (Cynet).

Suppose an AI document-summarization feature starts returning empty summaries for roughly one in five uploads. The status page reads:

Investigating: Some users may receive empty summaries for uploaded documents. Our team is investigating. Next update within 30 minutes.

Here is how three different customers should be answered from that single page, without any of the three replies inventing a fact.

The second row is where AI incidents differ from plain outages. Customers cannot see a model. They can only observe that an output was wrong, empty or refused, and they extrapolate about their data. If the status page does not address data handling, the correct support answer is that you do not have confirmed information yet and the page will carry it, not a comforting guess.

The third row is where agents most often break script. The instinct is to soften a hard deadline with a hopeful time. Instead, hand the customer the decision: here is what we know, here is when the next update lands, here is what you can do in the meantime. That is the same structure Atlassian recommends across channels, where each audience gets the message it needs on the channel it uses, rather than one blended message (Atlassian).

Anger during an AI incident usually has one of three sources: lost work, a wrong output that reached a customer of theirs, or a previous promise that was not kept. The reply has to acknowledge the first, avoid speculating on the second, and own the third.

Language matters more than structure here. Guidance on customer service phrasing recommends specific ownership over stock apologies, and flags phrases like "I apologize for any inconvenience" as empty because they do not name what is being apologized for (Gorgias on phrases to use and avoid). So replace "We apologize for any inconvenience" with "We are sorry the summaries came back empty; that is not the behavior you should expect from this feature."

The most useful de-escalation move in an incident is to answer the question the customer did not ask: what happens next, and who decides. A reply that says "the next update will be posted on the status page at [time]" gives an angry customer something concrete to check and a reason to stop escalating to an agent who has no more information than the page does.

If the customer is angry about a commitment a previous agent made, do not repeat it and do not deny it. Say that you are sorry the earlier message set an expectation the team could not hold, and point to the status page for the current state. Then log it, because repeated broken promises are a script problem that the post-incident review should fix, which is what the NIST lifecycle's feedback loop from recovery back into detection and analysis is for (Cynet).

For escalations that are truly account-level, the reply should route to the person who can actually make a decision, and say so in one sentence. Vague offers to "escalate internally" read as a brush-off.

A single static template will be wrong within an hour, because status pages move through phases. The open status page guidance models a typical lifecycle of investigating, identified, monitoring and resolved, with plain-language examples for each (openstatus). The support macro needs one block per phase, and the agent picks the block that matches the page at the moment of sending.

PHASE: Investigating
We are aware of an issue affecting [feature] and are investigating.
Current status and next update: [status page link]

PHASE: Identified
We have identified what is causing the issue with [feature] and are
working on a fix. Details and next update: [status page link]

PHASE: Monitoring
A fix has been applied to [feature] and we are watching to confirm it
holds. If you still see the issue, reply here. Status: [status page link]

PHASE: Resolved
The issue affecting [feature] is resolved. A summary will be posted at
[status page link]. Thank you for your patience.

Four practices keep this from rotting.

Name one owner for the macro. During the incident, the incident commander or a communications lead owns both the status page and the support macro, and updates them in the same action. If two people update them separately, they will diverge, and the first customer to notice the divergence will say so publicly.

Run the broken-AI scenario in a tabletop exercise. Discussion-based exercises are designed to test a response plan in a low-stress setting, and they surface gaps in communication and unclear roles rather than technical faults (Bitsight on tabletop exercises). CISA publishes customizable exercise packages with scenarios, objectives and discussion questions that teams can adapt without building an exercise from scratch (CISA tabletop exercise packages). A 60 to 90 minute session with support, engineering and communications in one room, working from a page that changes three times, will find more script defects than any review.

Put the script in the incident checklist. CISA's incident response playbook includes an incident response checklist with steps, actions taken and date completed, and it is written so that organizations beyond federal agencies can use it to standardize their own practices (CISA playbooks, the playbook PDF). If "support macro updated to match status page" is not a line item with a name against it, it does not happen.

Review the replies, not just the outage. After resolution, sample the replies sent during the incident and check them against the page as it stood at that moment. Any reply that contained a fact the page did not contain is a training example, and any reply that contained a time the page did not contain is a defect in the macro.

The distinction between an incident response plan and a playbook is useful here. A plan covers how the organization responds to an incident, while playbooks are scenario-specific procedures, and the plan should cover every phase of the lifecycle including preparation and post-incident activity (Fortinet on plans, playbooks and policy). The support script is a tiny playbook, and it deserves the same treatment as the bigger ones: an owner, a review cycle and a rehearsal.

If your team runs AI features across several model providers and the incident work keeps landing on the same two people, a shared credit pool and a private skill library for the support and engineering group can cut the coordination overhead; Quanta for Teams is built for that arrangement (https://quantaintelligence.ai/for-teams). When the harder question is which of your AI workflows need this kind of script at all, a short working session tends to settle it faster than a document: Quanta Consulting runs a free 30-minute discovery call (https://quantaintelligence.ai/calendar).