Draft Outage Comms and How-To Guides in Minutes

Tier: Foundation · Workflow area: Communication & leadership · ~25 minutes

This playbook covers the two highest-frequency writing tasks on any desk (UC-51, UC-52): the status update users refresh for, and the how-to guide that prevents the next hundred tickets. Both are drafting problems AI is genuinely good at — provided the facts are pinned and the send button stays human.

When to use

• Any incident touching more than a handful of usersthe first notice should go out within minutes of confirmation, and AI drafting removes the "someone is wordsmithing" delay.
• The same question arrived three times this weekthat is the how-to threshold. Guides written at the third occurrence beat guides planned for "documentation week."
• Your updates are either too scary or too soothingseverity calibration is exactly what a template-plus-prompt fixes; humans under stress default to extremes.

When NOT to use

• Security incidents with legal exposurebreach notifications have regulatory language requirements and disclosure timing rules. Legal drafts those; you supply facts.
• When you don't know what's happening yetAI will fluently pad ignorance into paragraphs. If all you know is "email is down, cause unknown," say exactly that in one sentence; do not generate speculation.
• Auto-sending anythingno workflow where model output reaches users without a named human clicking send. That rule has no exceptions in this track.

The recipe

1. 1.

   Keep a severity-calibrated prompt on file. One reusable template, filled at incident time:

   Copy

   Draft an IT outage notification.
   
   Facts (use ONLY these; do not invent scope, cause, or times):
   - Service affected: [Exchange Online mail flow]
   - Impact: [inbound external mail delayed; internal mail unaffected]
   - Started: [10:20 IST] · Status: [investigating with vendor]
   - Workaround: [none / describe]
   - Next update: [12:00 IST]
   
   Severity: [SEV-2] — tone rules:
   SEV-1: urgent, plain, no hedging, workaround first if one exists
   SEV-2: calm, factual, impact-scoped so unaffected users self-select out
   SEV-3: brief, low-alarm, one paragraph
   
   Produce 3 versions: status page (<=80 words), email (<=150 words),
   chat post (<=40 words, no greeting). State only what the facts support.
   Include the next-update time in all three.
   

   The facts block is the control surface: the model formats and calibrates; it never sources.

2. 2.

   Verify the draft against the facts block — line by line. Thirty seconds: every time, scope claim and workaround in the draft must appear in your facts. The classic AI failure is helpful invention — "we expect resolution within the hour" when you promised no such thing. Delete anything unpinned, then send. Total elapsed time should be under five minutes from facts to posted notice.

3. 3.

   Send the closing notice with the same discipline. Resolution notices earn trust when they are concrete: what broke (plainly), when it was fixed, what users should do now (re-send? nothing?), and whether a post-incident review follows. Same prompt, Status: resolved, same verification pass.

4. 4.

   For how-to guides, capture first, narrate second. Do the task once yourself and screenshot every step (or run a Scribe-class capture tool that grabs clicks and screens automatically). Screenshots are ground truth; the guide is narration around them.

5. 5.

   Generate the guide from the real steps.

   Copy

   Write a how-to guide for end users: "Set up MFA on a new phone".
   
   My actual steps, in order: [1. Open aka.ms/mfasetup  2. Sign in
   3. Choose "Add sign-in method" ... ]
   Audience: non-technical staff. Reading level: simple, no jargon.
   Format: numbered steps, one action per step, bold the exact
   button/menu names, note what the user should SEE after each step,
   and add a "If this doesn't work" section with the top 2 failure
   points and how to contact support.
   

   The "what you should see" lines are what separate a guide users finish from a guide that generates tickets; keep them.

6. 6.

   Walk the guide once as written. Follow your own guide on a clean session, doing only what the words say. Every mismatch — renamed button, missing step, wrong screenshot — gets fixed now, because a wrong guide costs more tickets than no guide.

7. 7.

   File both artifacts where reuse happens. The outage prompt and severity rules live in the team's prompt library (pb-49); the guide goes in the KB with an owner and a review date, and becomes deflection material for the bot (pb-42's KB path).

Make it yours

• Status-page shopstore the SEV-calibrated templates in Statuspage/Instatus as prefilled incident templates; the AI drafts into them, and the platform handles subscriber fan-out and the update cadence timer.
• M365 shopcheck Service Health first so your notice distinguishes "our issue" from "Microsoft's issue," and say which; users forgive vendor outages faster when you name them, with the incident ID.
• MSP / multi-client shopparameterize the prompt per client (brand voice, contacts, SLA language) and keep per-client fact blocks; never let one client's incident details leak into another's draft session.

Quality check

• Every claim traces to the facts block. The verification pass is a diff, not a vibe check. Unpinned promise found = deleted before send.
• Next-update time is always present — and honored. An update that says "12:00" and lands at 12:00 buys more trust than a fast fix communicated badly.
• Guides are walked before publishing. No guide ships that its author has not followed verbatim on a clean profile.
• Tone matches severity, checked by a second reader on SEV-1. Under real pressure, the approver role is explicit: one named person reads, edits, sends.