Draft Incident Comms in Minutes — and Keep a Human on Send

Workflow area: Leadership Ops · Tier: Foundation · Hands-on time: ~25 minutes

Incident communication fails in predictable ways: updates written by an engineer mid-debug read as jargon to customers; exec summaries either overpromise ("resolved") or say nothing; and the gap between updates grows exactly when anxiety peaks. AI drafting solves the speed and translation problem — one set of timeline facts becomes three audience-correct drafts in two minutes. It also introduces a new failure: a fluent draft containing a claim the timeline does not support, sent because it sounded right at 2am. The human-send gate is not a formality; it is the design.

When to use — and when not to

• Use it for every incident with an external or exec audienceSEV1s and SEV2s where status pages, customer emails, and leadership updates all need feeding on different clocks.
• Use it for the update cadence, not just the first messagethe third update at hour four is where tired humans go quiet; drafting cost should never be the reason silence grows.
• Use it for the all-clear and the customer postmortem summarythe most-read messages of the incident, and the ones most worth three careful drafts.
• Skip it for legally sensitive incidents until counsel is in the loopsecurity breaches, data exposure, and anything with regulatory notification duties (72-hour clocks, contractual SLAs) get comms drafted under legal guidance; AI can help format, but the claims list comes from counsel.
• Skip pasting anything secret into unapproved toolsincident channels contain customer names, architecture details, and sometimes credentials in stack traces; approved tenant only, and scrub before pasting.
• Never automate the sendno pipeline where a model posts to the status page unreviewed, ever; that is how a hallucinated "fully resolved" reaches ten thousand customers.

The recipe

1. 1.

   Maintain one timeline of facts as the incident runs. A pinned message or incident-tool timeline: timestamped, declarative, boring. "14:32 elevated 5xx on checkout, ~18% of requests. 14:41 rolled back deploy 891. 14:55 error rate declining." This is the single source every draft derives from — if it is not on the timeline, it does not go in a message.

2. 2.

   Generate the audience set from the timeline.

   Copy

   Draft incident communications from these timeline facts. Use
   ONLY these facts — no speculation about cause, no promises
   about resolution time unless a fact states one.
   
   TIMELINE:
   [PASTE TIMELINE]
   Incident status: [investigating / identified / mitigating /
   resolved]. Customer impact in plain terms: [ONE LINE].
   
   Produce three drafts:
   1. STATUS PAGE (max 80 words): plain language, no internal
      system names, what users experience, what we're doing, when
      the next update comes.
   2. EXEC BRIEF (max 120 words): impact in business terms
      (who/what/how long), current status, what's being done, what
      help if any is needed. No jargon, no hedging fog.
   3. CUSTOMER EMAIL (for affected accounts): empathetic, specific
      about their impact, honest about what we don't know yet.
   
   For each draft, append CLAIMS: every factual assertion made,
   with the timeline line it derives from. If any claim lacks a
   source line, mark it [UNSUPPORTED] instead of removing it
   silently.
   

3. 3.

   Run the claims check — this is the gate. Good output looks like:

   Copy

   STATUS PAGE: "Some customers are seeing errors at checkout. We
   have identified a recent change as the likely cause and rolled
   it back; error rates are improving. Next update by 15:30 IST."
   
   CLAIMS:
   - "seeing errors at checkout" ← 14:32 line
   - "rolled it back" ← 14:41 line
   - "error rates improving" ← 14:55 line
   - "likely cause" ← [UNSUPPORTED — timeline shows correlation,
     not confirmed causation]
   

   Every [UNSUPPORTED] gets resolved by you: soften the claim, confirm the fact, or cut the line. The words "resolved," "fixed," "no data was affected," and any timestamp promise get individually verified — these are the four claims that generate the retraction.

4. 4.

   A named human sends, every time. The incident commander or comms lead reads the final text, owns it, and posts it. Log who sent what where — during a messy incident, "did the customer email go out?" needs an answer.

5. 5.

   Keep the update loop alive. Each new timeline fact → re-run step 2 with the updated timeline → claims check → send. Committing to "next update by HH:MM" in every message — and hitting it even when the update is "still investigating" — is worth more trust than any elegant prose.

Make it yours

• Small team, no comms function: pre-build the prompt with your status-page voice and product terms in a saved template; at 2am you want one paste, not prompt engineering. Add your two or three standard customer-impact phrasings so drafts start consistent.
• Enterprise with a comms/legal review chain: the AI draft enters the existing review chain as a draft, replacing the blank page, not the reviewers. Encode your notification-clock rules ("data exposure → legal within 30 min, before any external comms") in the template header so the drafter is reminded every time.
• Services company or GCC: add a fourth audience — the client's engineering leadership — with its own draft: more technical than the status page, contractually careful, aligned with your MSA's incident-notification terms (see pb-33 for the approval workflow those terms come from).

Quality check

• Every claim traces to a timeline linethe CLAIMS list is the artifact; a draft without one does not get sent.
• No unearned certainty survived"identified the cause" vs "identified a likely cause" is the difference between an update and a future correction; models default to the confident version.
• Impact language matches reality"some customers" when it is 60% of traffic will be quoted back to you; verify percentages before they become adjectives.
• The next-update promise is one you will keepa missed update time is a broken promise measured in refreshes.
• The send log has a name in itevery external message attributable to a human who read it end to end.