Customer Incident Update

---
name: customer-incident-update
description: "Write the customer-facing incident update during an outage — status-page post or email — that's honest about impact without over-promising. Use when asked to write a status page update, draft customer comms for an outage, post an incident notice, or tell customers about downtime. Produces the update in the right tense for the incident stage (investigating / identified / monitoring / resolved), with impact scope, any workaround, and a concrete next-update time. Distinct from incident-postmortem (the internal retro)."
---

# Customer Incident Update

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

1. **Match the tense to the stage.** "We're investigating" ≠ "we've identified" ≠ "we're monitoring the fix." Don't skip ahead.
2. **Impact before cause.** Customers care what's broken for them; causes come in the postmortem, not mid-incident.
3. **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.
4. **No speculation.** If you don't know the cause, say you're investigating — a wrong guess published is worse than an honest unknown.
5. **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."