| name | escalation |
| description | Guide support teams on when and how to escalate issues effectively with structured briefs |
| type | reference |
| version | 1.0.0 |
| category | business |
| last_updated | "2026-02-03T00:00:00.000Z" |
| source | https://github.com/anthropics/knowledge-work-plugins |
| related_skills | ["ticket-triage","customer-research","response-drafting","knowledge-management"] |
| capabilities | [] |
| requires | [] |
| see_also | [] |
| tags | [] |
Escalation Skill Summary
This guide teaches support teams when and how to escalate issues effectively. Here are the key takeaways:
Escalation Triggers
Escalate when issues involve confirmed bugs, production outages, data integrity risks, security concerns, or high-value customers at risk. Technical escalations include: bug confirmed and needs a code fix, infrastructure investigation needed, data corruption or loss.
Tier Structure
Issues flow through escalation levels (L1 -> L2 -> Engineering/Product) based on complexity and impact. Security concerns bypass normal progression and go immediately to the security team.
Critical Success Factor: Reproduction Steps
Good reproduction steps are the single most valuable thing in a bug escalation. Effective steps start from a clean state, use specific values, document the environment, and include exact error messages.
Quantifying Impact
Strong escalations measure impact across breadth (how many customers), depth (severity), duration, revenue at risk, reputation risk, and contractual obligations. This prevents vague escalations from being deprioritized.
Post-Escalation Ownership
Support maintains customer relationship responsibility after escalating. Follow-up frequency depends on severity: critical issues get updates every 2-4 hours; high-severity issues every 4-8 hours; medium issues every 1-2 business days.
