Skip to main content
ClaudeWave
Skill1.1k repo starsupdated 3d ago

escalation-management

Handles customer situations that have exceeded normal support — severity assessment, incident communication, executive escalation, and recovering a relationship after a failure. Use this when a customer issue is escalating or has gone to leadership, during a customer-affecting outage, when a major account is at risk, when a relationship needs repairing after a failure, or to design the escalation path itself.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/cbrock84/headcount /tmp/escalation-management && cp -r /tmp/escalation-management/plugins/customer-experience/skills/escalation-management ~/.claude/skills/escalation-management
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# Escalation management

An escalation is a signal that the normal path failed. Handling it well matters; the more useful
question afterward is why it was needed.

## Assess severity from the customer's position

Severity is what it costs *them*, not how alarming it looks internally. A cosmetic bug blocking a
regulated filing is severe. A total outage of a feature nobody uses is not.

Ask: what can they not do, how many people, is there a workaround, and is there a deadline attached.
That last one converts a medium into a critical more often than anything technical.

## Running one

**Own it visibly.** One named person, introduced to the customer, who does not disappear. Escalations
get worse when ownership is ambiguous — the customer starts re-explaining, which is its own insult.

**Communicate on a stated cadence**, and hold it even when there is nothing new. "No update yet, next
update at three" preserves trust; silence destroys it faster than bad news does. Customers escalate
again because they heard nothing, far more often than because of the underlying issue.

**Separate acknowledgment from explanation.** Acknowledge the impact immediately, in their terms.
Explanation comes when you actually know. Leading with a cause you have not confirmed means
retracting it later, and the retraction is what they remember.

**Do not over-promise to end the conversation.** Every commitment made under pressure to a
frustrated customer is a commitment someone has to keep, and failing a recovery promise ends the
relationship.

## Executive escalation

When a customer reaches your leadership, the relationship is already damaged — the escalation is
the symptom.

Brief the executive properly before the call: what happened, what we have done, what we are
committing to, and what not to promise. An executive walking in uninformed makes commitments the
delivering team learns about afterward.

## Recovery

Recovery is not an apology. It is: acknowledge specifically what failed, say what changed so it
cannot recur, and demonstrate it over time. Credits and discounts are compensation, not recovery —
they close the ledger without addressing the trust.

The strongest recovery move is showing them the fix shipped.

## Afterward

Every escalation gets a short review: what made the normal path fail, was severity assessed
correctly, did we communicate on time, and what would have prevented it.

Escalation volume is a health metric for the whole function. Rising escalations mean the normal path
is failing more often, and that is the thing to fix.

## Never

- Escalate without naming an owner. An escalation with no name on it is a broadcast.
- Commit to a fix date on the customer's call before engineering has said one exists.
- Let the executive sponsor become the case owner. Sponsors unblock; they do not run the case.
- Close on the technical fix. It closes when the customer says it is closed.