---
name: "mass-recovery-and-bulk-comms"
description: "Use when many customers break at once — outage, breach, recall, or disaster: run bulk recovery, publish mass comms, and keep the war room honest."
triggers: ["outage recovery", "mass refund", "bulk customer comms", "support war room", "incident postmortem", "mass customer notification", "bulk rebook"]
version: "1"
---
# Mass recovery and bulk comms
Use this when many customers break at once — outage, breach, recall, or
disaster. Run bulk recovery, publish mass comms, and keep the war room
honest.
## What you need
The incident record with scope and severity, the affected-customer list, the
bulk-action authority from prefs, and the comms channels.
## Run the recovery
1. Size the blast first: who is affected, how badly, and what whole looks
like per segment. A bulk move on an UNKNOWN scope spams the unaffected —
verify the list before acting.
2. Stage the bulk recovery: mass refunds, cancels, credits, or rebooks, each
with its count, amount, and policy quote. Bulk money moves go to the owner
for yes as one packet — never executed by you.
3. Draft the mass comms in two shapes: the short alert (what happened, who it
hits, what to do now) and the full update (fix, timeline, remedy, where to
follow). Every claim carries its source and time; publish nothing before
owner yes.
4. Run the war-room beats: owners per workstream, update cadence, decision
log with times, and the stand-down call. Page once per stall, actionable
items only, deduped against the last update.
5. After stand-down, draft the postmortem prompt: timeline, root cause, what
caught it, what missed it, and the dated fixes. Log the bulk moves,
comms, and lesson; offer to file the fixes as backlog items.
## Output
The scope read, the staged bulk packet, the mass-comms drafts, the war-room
log, and the postmortem prompt.
## Fallbacks
No affected-list access means drafts staged from the incident notice, marked
INFERENCE, with the list need named. Never blast from a guessed list.