During an outage, silence is the second failure. But the customer update is its own craft: say what's affected without guessing at causes, commit to a next-update time you can keep, and never promise a fix-by you don't control. This writes the post for the stage you're in — the messy middle included — so customers feel informed, not managed.
What This Skill Produces
- The update, in the tense of the current stage (investigating / identified / monitoring / resolved)
- The impact line — who and what is affected, in the customer's terms
- The workaround — if one exists, stated plainly
- The next-update commitment — a specific time, always
- Channel variants — a terse status-page version and a fuller email if needed
Required Inputs
Ask for these if not provided:
- Stage — investigating, identified, monitoring, or resolved
- Impact — which product/region/customers, and what they can't do right now
- What's known — only what you're confident of; unknowns stay unknown in the post
- Workaround — any, or none
- Audience — all customers, affected only, or enterprise accounts (tone shifts)
Framework: Honest Status Comms
- Match the tense to the stage. "We're investigating" ≠ "we've identified" ≠ "we're monitoring the fix." Don't skip ahead.
- Impact before cause. Customers care what's broken for them; causes come in the postmortem, not mid-incident.
- Commit to the next update, not the fix. "Next update by 15:00 UTC" is a promise you can keep; "fixed within the hour" often isn't.
- No speculation. If you don't know the cause, say you're investigating — a wrong guess published is worse than an honest unknown.
- Own it plainly. Brief, human, no corporate throat-clearing; apologise once, then inform.
Output Format
Status-page post
[Investigating/Identified/Monitoring/Resolved] — [title] · [timestamp] [Impact: who/what]. [What we're doing]. [Workaround, if any]. Next update by [time].
Email (if broader comms needed)
- Subject: [clear, non-alarmist]
- Body: impact → status → workaround → next update → apology
- Sign-off
Update ladder (for the incident's life)
- The follow-on posts you'll publish as the stage changes, pre-drafted
Quality Checks
- The tense matches the actual stage — no claiming a fix that isn't confirmed
- Impact is stated in customer terms, up top
- A specific next-update time is given
- No cause is speculated when it isn't known
- No fix-by time is promised that depends on an unknown
- Tone is human and brief — one apology, no jargon
Anti-Patterns
- "Some users may be experiencing issues" when it's a full outage — minimising erodes trust faster than the outage.
- Promising a resolution time you can't control.
- Publishing a guessed cause that turns out wrong.
- No next-update time — leaves customers refreshing in the dark.
- Skipping stages — jumping to "resolved" before monitoring confirms it.
Example Trigger Phrases
- "Write a status page update — we're investigating an outage."
- "Draft customer comms for the API downtime, identified stage."
- "Post an incident notice for enterprise accounts."
- "We've deployed a fix and are monitoring — write the update."