Handle a customer on fire with a runbook, not a scramble.
Triage severity, name owners and comms cadence, draft the customer message, and set the post-mortem.
Inside: The severity triage, the owners and cadence, and the customer message.
Install it in one line, or paste it in.
~/.claude/skills/ and runs automatically when it is relevant.Connect your context. Set it to your motion.
pulls the account value, the renewal date, and the owner, so the severity reflects the stakes.
reads what was already promised and when the customer last heard from you.
adds the ticket history and whether this issue is a repeat.
This was built for a B2B SaaS org with a tiered severity model. Set these to your stack:
Run any severity model you like. The skill grades impact against blast radius, so point it at your definitions, not anyone else's.
| Set this | What it is | Default / Example |
|---|---|---|
| CRM | your CRM connector | your CRM of choice |
| SEVERITY_MODEL | how you grade an incident | Sev1 / Sev2 / Sev3 |
| OWNERS | the roles that get pulled in | CSMSupportEngExec sponsor |
| CADENCE | how often you update per severity | Sev1 hourlySev2 dailySev3 on change |
| ACCOUNT_VALUE field | where the stakes live | ARRrenewal datestrategic flag |
| COMMS_CHANNEL | where updates go | the customer thread + an internal channel |
| POSTMORTEM_SLA | when the review must happen | within 5 business days of resolution |
Everything the skill does, in full.
Takes a live customer escalation and turns panic into a sequence. It grades how bad this actually is, assigns the internal owners, sets how often everyone hears an update, drafts the message the customer receives, and schedules the post-mortem that prevents the same fire twice. A calm customer is not a lucky customer. It is a managed one.
- 1Severity triage
Grade the escalation on two axes: how much is broken and how many it hits. A full outage on a top account is not the same as a cosmetic bug for one user. Assign a severity and state the reason in one line. The severity sets the cadence and the owners. Everything downstream follows from this call.
- 2Owners and RACI
Name the people, not the departments. Who drives the fix, who talks to the customer, who decides, who just needs to know. One accountable owner per escalation. A fire with two owners has none.
- 3Comms cadence
Set the heartbeat. How often the customer hears from you and how often the internal room syncs, both keyed to severity. Silence is what turns a bug into a churn risk. An update that says "still working it, next update at 3pm" beats a fix delivered in silence.
- 4Customer-facing message
Draft what the customer actually reads. Acknowledge, own it without over-promising, state what you know, state the next update time. No blame, no jargon, no false certainty. Give them the next checkpoint, not a guess at the finish.
- 5Post-mortem that prevents a repeat
Schedule the review before the fire is even out. Capture the root cause, the timeline, what the customer experienced, and the one change that stops a recurrence. An escalation you do not learn from is one you have agreed to have again.
- No severity grade without the one-line reason behind it.
- Exactly one accountable owner. Named, not a team.
- The customer message states a specific next-update time, never "soon."
- Every resolved escalation has a scheduled post-mortem before it closes.
- No blame language in anything the customer sees.
ESCALATION RUNBOOK Severity: SEV1 (core workflow down, top-20 account, renewal in 60 days) Owners Drive fix: Eng on-call Customer comms: the CSM Decision: Support lead Informed: Exec sponsor Cadence: customer update every hour, internal sync every 30 min Customer message (draft): "We are aware the X workflow is failing for your team and we have engineers on it now. This is our top priority. Next update by 2:00pm your time, whether or not it is resolved by then." Post-mortem: scheduled within 5 business days. Owner: the CSM. Prevent-a-repeat: add a monitor on the workflow that failed silently.
The cadences (hourly, daily) and the post-mortem SLA (5 days) are defaults, not laws. They suited a mid-market SaaS support model. If your customers expect tighter or looser contact, change them. The logic does not change. The thresholds are yours.
Where an operator takes this next.
The runbook works from what you paste in the moment. Here is the version that catches the fire before you open a laptop.
A fire you learn from is the only kind worth having.
Wire a scheduled Claude task to a PagerDuty or Slack alert so severity, owners, and the first customer message draft exist before anyone joins the call.
Connect Salesforce so every escalation opens with real ARR and renewal date, not a guess at how much this account matters.
Have the post-mortem write itself into a shared doc tagged to the account, so the next escalation on the same account starts with the last one's lesson already loaded.
One skill is the on-ramp.
A single skill does one job. Chained into a playbook, or run as a full build, it becomes a system. Here is where this one plugs in.