home / skills / anthropics / knowledge-work-plugins / escalation

This skill helps you structure escalation briefs and guide cross-team action with full context, reproduction steps, and business impact for rapid resolution.

npx playbooks add skill anthropics/knowledge-work-plugins --skill escalation

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
8.1 KB
---
name: escalation
description: Structure and package support escalations for engineering, product, or leadership with full context, reproduction steps, and business impact. Use when an issue needs to go beyond support, when writing an escalation brief, or when assessing whether an issue warrants escalation.
---

# Escalation Skill

You are an expert at determining when and how to escalate support issues. You structure escalation briefs that give receiving teams everything they need to act quickly, and you follow escalation through to resolution.

## When to Escalate vs. Handle in Support

### Handle in Support When:
- The issue has a documented solution or known workaround
- It's a configuration or setup issue you can resolve
- The customer needs guidance or training, not a fix
- The issue is a known limitation with a documented alternative
- Previous similar tickets were resolved at the support level

### Escalate When:
- **Technical**: Bug confirmed and needs a code fix, infrastructure investigation needed, data corruption or loss
- **Complexity**: Issue is beyond support's ability to diagnose, requires access support doesn't have, involves custom implementation
- **Impact**: Multiple customers affected, production system down, data integrity at risk, security concern
- **Business**: High-value customer at risk, SLA breach imminent or occurred, customer requesting executive involvement
- **Time**: Issue has been open beyond SLA, customer has been waiting unreasonably long, normal support channels aren't progressing
- **Pattern**: Same issue reported by 3+ customers, recurring issue that was supposedly fixed, increasing severity over time

## Escalation Tiers

### L1 → L2 (Support Escalation)
**From:** Frontline support
**To:** Senior support / technical support specialists
**When:** Issue requires deeper investigation, specialized product knowledge, or advanced troubleshooting
**What to include:** Ticket summary, steps already tried, customer context

### L2 → Engineering
**From:** Senior support
**To:** Engineering team (relevant product area)
**When:** Confirmed bug, infrastructure issue, needs code change, requires system-level investigation
**What to include:** Full reproduction steps, environment details, logs or error messages, business impact, customer timeline

### L2 → Product
**From:** Senior support
**To:** Product management
**When:** Feature gap causing customer pain, design decision needed, workflow doesn't match customer expectations, competing customer needs require prioritization
**What to include:** Customer use case, business impact, frequency of request, competitive pressure (if known)

### Any → Security
**From:** Any support tier
**To:** Security team
**When:** Potential data exposure, unauthorized access, vulnerability report, compliance concern
**What to include:** What was observed, who/what is potentially affected, immediate containment steps taken, urgency assessment
**Note:** Security escalations bypass normal tier progression — escalate immediately regardless of your level

### Any → Leadership
**From:** Any tier (usually L2 or manager)
**To:** Support leadership, executive team
**When:** High-revenue customer threatening churn, SLA breach on critical account, cross-functional decision needed, exception to policy required, PR or legal risk
**What to include:** Full business context, revenue at risk, what's been tried, specific decision or action needed, deadline

## Structured Escalation Format

Every escalation should follow this structure:

```
ESCALATION: [One-line summary]
Severity: [Critical / High / Medium]
Target: [Engineering / Product / Security / Leadership]

IMPACT
- Customers affected: [Number and names if relevant]
- Workflow impact: [What's broken for them]
- Revenue at risk: [If applicable]
- SLA status: [Within SLA / At risk / Breached]

ISSUE DESCRIPTION
[3-5 sentences: what's happening, when it started,
how it manifests, scope of impact]

REPRODUCTION STEPS (for bugs)
1. [Step]
2. [Step]
3. [Step]
Expected: [X]
Actual: [Y]
Environment: [Details]

WHAT'S BEEN TRIED
1. [Action] → [Result]
2. [Action] → [Result]
3. [Action] → [Result]

CUSTOMER COMMUNICATION
- Last update: [Date — what was said]
- Customer expectation: [What they expect and by when]
- Escalation risk: [Will they escalate further?]

WHAT'S NEEDED
- [Specific ask: investigate, fix, decide, approve]
- Deadline: [Date/time]

SUPPORTING CONTEXT
- [Ticket links]
- [Internal threads]
- [Logs or screenshots]
```

## Business Impact Assessment

When escalating, quantify impact where possible:

### Impact Dimensions

| Dimension | Questions to Answer |
|-----------|-------------------|
| **Breadth** | How many customers/users are affected? Is it growing? |
| **Depth** | How severely are they impacted? Blocked vs. inconvenienced? |
| **Duration** | How long has this been going on? How long until it's critical? |
| **Revenue** | What's the ARR at risk? Are there pending deals affected? |
| **Reputation** | Could this become public? Is it a reference customer? |
| **Contractual** | Are SLAs being breached? Are there contractual obligations? |

### Severity Shorthand

- **Critical**: Production down, data at risk, security breach, or multiple high-value customers affected. Needs immediate attention.
- **High**: Major functionality broken, key customer blocked, SLA at risk. Needs same-day attention.
- **Medium**: Significant issue with workaround, important but not urgent business impact. Needs attention this week.

## Writing Reproduction Steps

Good reproduction steps are the single most valuable thing in a bug escalation. Follow these practices:

1. **Start from a clean state**: Describe the starting point (account type, configuration, permissions)
2. **Be specific**: "Click the Export button in the top-right of the Dashboard page" not "try to export"
3. **Include exact values**: Use specific inputs, dates, IDs — not "enter some data"
4. **Note the environment**: Browser, OS, account type, feature flags, plan level
5. **Capture the frequency**: Always reproducible? Intermittent? Only under certain conditions?
6. **Include evidence**: Screenshots, error messages (exact text), network logs, console output
7. **Note what you've ruled out**: "Tested in Chrome and Firefox — same behavior" "Not account-specific — reproduced on test account"

## Follow-up Cadence After Escalation

Don't escalate and forget. Maintain ownership of the customer relationship.

| Severity | Internal Follow-up | Customer Update |
|----------|-------------------|-----------------|
| **Critical** | Every 2 hours | Every 2-4 hours (or per SLA) |
| **High** | Every 4 hours | Every 4-8 hours |
| **Medium** | Daily | Every 1-2 business days |

### Follow-up Actions
- Check with the receiving team for progress
- Update the customer even if there's no new information ("We're still investigating — here's what we know so far")
- Adjust severity if the situation changes (better or worse)
- Document all updates in the ticket for audit trail
- Close the loop when resolved: confirm with customer, update internal tracking, capture learnings

## De-escalation

Not every escalation stays escalated. De-escalate when:
- Root cause is found and it's a support-resolvable issue
- A workaround is found that unblocks the customer
- The issue resolves itself (but still document root cause)
- New information changes the severity assessment

When de-escalating:
- Notify the team you escalated to
- Update the ticket with the resolution
- Inform the customer of the resolution
- Document what was learned for future reference

## Using This Skill

When handling escalations:

1. Always quantify impact — vague escalations get deprioritized
2. Include reproduction steps for bugs — this is the #1 thing engineering needs
3. Be clear about what you need — "investigate" vs. "fix" vs. "decide" are different asks
4. Set and communicate a deadline — urgency without a deadline is ambiguous
5. Maintain ownership of the customer relationship even after escalating the technical issue
6. Follow up proactively — don't wait for the receiving team to come to you
7. Document everything — the escalation trail is valuable for pattern detection and process improvement

Overview

This skill structures and packages support escalations so engineering, product, security, or leadership can act immediately. It creates concise briefs with business impact, exact reproduction steps, mitigation attempts, and a clear ask. Use it to decide whether to escalate, draft the escalation, and manage follow-up until resolution.

How this skill works

The skill inspects the incident context, support history, and impact dimensions to recommend escalation tier and severity. It produces a standardized escalation brief containing impact metrics, a 3–5 sentence issue summary, step-by-step reproduction, evidence, actions tried, and the specific decision or fix requested. It also recommends follow-up cadence and de-escalation conditions.

When to use it

  • Issue appears to need code changes, infrastructure investigation, or security review
  • Multiple customers or high-value accounts are impacted or SLA risk exists
  • Support cannot reproduce or lacks required access/privileges to diagnose
  • Customer requests executive involvement or legal/PR risk is present
  • Issue has been open beyond SLA or is recurring/patterned

Best practices

  • Quantify impact: customers affected, revenue at risk, SLA status
  • Provide exact reproduction steps with environment, inputs, and evidence
  • Be explicit in the ask: investigate, fix, approve, or prioritize — include a deadline
  • Log what’s been tried and ruled out to avoid duplicated work
  • Assign follow-up cadence by severity and own the customer communication
  • Include links to tickets, logs, and internal threads for quick context

Example use cases

  • Frontline support confirms a bug that blocks exports for multiple customers and needs engineering triage
  • Senior support identifies a recurring workflow gap and escalates to Product with frequency and use cases
  • Suspected data exposure is reported and must be escalated directly to Security with containment details
  • High-revenue customer threatens churn after a missed SLA; escalate to Leadership with impact and decision needed
  • Support needs a rapid hotfix request: include reproduction, logs, and a same-day deadline

FAQ

What is the single most valuable thing to include in a bug escalation?

Precise reproduction steps from a clean state, including environment, exact inputs, and evidence — this saves engineering time.

How do I choose severity?

Map severity to breadth, depth, duration, and revenue/reputation risk: Critical for production down or data risk; High for major functionality broken or SLA at risk; Medium when a workaround exists.