📣 Drafting Customer Incident Updates With AI: Honest and Fast

The hardest sentence to write during an outage is the first public one. You’re three minutes into a Sev1, you don’t fully understand the problem, your customers are starting to notice, and now you also have to be a calm, articulate writer. So the update either goes out late, or it goes out clumsy — and clumsy public updates create their own incidents.

I’ve come to lean on AI heavily for this, but in a very specific way: it drafts the words, it never decides the message. Let me explain where that line sits, because getting it wrong here is how you end up apologizing for your apology.

Why comms is where AI earns its keep

During an incident, the people who can write a good customer update are usually the same people you need debugging. Pulling your sharpest engineer off the logs to wordsmith a status post is a bad trade. AI breaks that trade: the incident commander or comms lead supplies the facts and the stance, and the model supplies fluent, on-brand prose in seconds.

The key insight is that customer comms is mostly a formatting and tone problem, not a judgment problem — as long as a human owns the facts going in. “We’re investigating elevated error rates on checkout, no data is at risk, next update in 30 minutes” is a human decision. Turning that into three platform-appropriate variants (status page, in-app banner, X post) is a formatting task, and that’s the model’s job.

The input is a fact sheet, never a free-for-all

I never ask AI to “write an update about the outage.” That invites it to fill gaps with guesses, and guesses in customer comms are how you promise a fix ETA you can’t hit. Instead I give it a tight, human-authored fact sheet:

• What customers are experiencing (symptom, not cause).
• What’s confirmed vs. still under investigation.
• What we are explicitly not claiming yet.
• Affected scope (which features, which regions).
• Next update time.
• Tone: calm, accountable, no jargon.

Then: “Draft a status-page update from only these facts. Do not state a root cause. Do not give a resolution ETA. Do not speculate about scope beyond what’s listed.”

Pro Tip: Put your “do not say” rules in the prompt explicitly — no root cause, no ETA, no blaming a vendor by name. Models default to sounding reassuring and complete, which during an active incident means inventing certainty you don’t have. The negative constraints matter more than the positive instructions.

Drafting for the update cadence

The trap in incident comms isn’t the first post — it’s the silence after it. Customers tolerate “we’re still working on it” far better than nothing. AI makes a regular cadence sustainable because the marginal cost of each update drops to near zero.

I keep the running fact sheet open and, every time the situation changes materially, I update three or four bullet points and regenerate. The model handles the “we have an update” framing, carries forward what’s still unresolved, and keeps the tone consistent across a six-hour incident even as the humans writing the inputs rotate through shifts. Consistency across a long incident is genuinely hard for tired humans and trivial for a model working from a maintained fact sheet.

Three audiences, one source of truth

The same incident usually needs different registers: a terse status-page line, a slightly warmer in-app message, and a factual internal note for support agents fielding tickets. Generating all three from one fact sheet keeps them from drifting out of sync — the classic failure where your status page says “resolved” while support is still telling customers it’s ongoing.

This is also where it connects to your broader comms practice. The discipline of a maintained fact sheet and a fixed cadence is what makes the status page communication approach work; AI just removes the writing friction that makes teams skip updates.

The human owns send

Here’s the bright line: a person reads every word before it’s published, and a person clicks send. The model never has publish access to a status page, a social account, or a customer email. Not because it would necessarily get it wrong, but because public communication during an incident is a trust transaction with your customers, and trust transactions need a human accountable for them.

When I review a draft, I’m checking for three things: Did it stay inside the facts I gave it? Did it sneak in reassurance I can’t back up (“we expect full resolution shortly”)? Does the tone match the severity — not so breezy it feels dismissive, not so grave it causes panic? Those are judgment calls, and judgment is mine.

Closing the loop

After resolution, the same approach drafts your “all clear” and feeds naturally into the postmortem comms. The free AI Incident Response Assistant is set up for exactly this draft-and-review rhythm, and a general tool like ChatGPT or Claude works fine if you bring your own fact sheet and constraints.

Customers don’t expect you to never break. They expect you to tell them the truth, quickly and clearly, while you fix it. AI lets you do the “quickly and clearly” part without pulling your best people off the fix — as long as the truth, and the send button, stay firmly in human hands. For reusable comms templates, the prompt library and prompt packs are worth a look.