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
- 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.
- 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.
- 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.
- 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.
- 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.