escalation-tree
GitHub设计支持或故障升级路径，明确层级职责、严重性定义、基于时间的触发规则及联系方式。解决工单流转混乱和升级不及时问题，确保关键人员及时介入并规范客户沟通。
触发场景
安装
npx skills add mohitagw15856/pm-claude-skills --skill escalation-tree -g -y
SKILL.md
Frontmatter
{
"name": "escalation-tree",
"description": "Design a support\/incident escalation tree — who handles what, when it escalates, and to whom. Use when asked to design an escalation path, an escalation matrix, support tiers, an on-call escalation policy, or to fix 'tickets bounce around \/ nothing gets escalated in time'. Produces an escalation tree — tiers & ownership, severity definitions, time-based triggers, routing rules, contacts\/roles, and the customer-communication cadence per level."
}
Escalation Tree Skill
Escalation goes wrong two ways: things sit too long before someone senior is pulled in, or everything gets escalated and senior people drown. A clear escalation tree fixes both — it defines the tiers, the severity that sets the path, the time triggers that force escalation, and who owns each step. This skill designs that, so the right person is on the right issue at the right time.
Required Inputs
Ask for these only if they aren't already provided:
- The context — customer support, incident/on-call, or both.
- The tiers/teams available — tier-1/2/3, engineering on-call, management, exec.
- Severity meaning — what counts as critical vs. high vs. normal in your context.
- Constraints — hours of coverage, SLAs/contractual response times, key roles.
Output Format
Escalation Tree: [support / incident]
1. Severity levels — define each (SEV1/P1 … or Critical/High/Normal/Low) with concrete criteria — what qualifies, blast radius, and the response & resolution targets per level. Ambiguous severity is why escalation fails.
2. The tiers — who owns what:
| Tier | Owns | Can resolve | Escalates when |
|---|---|---|---|
| Tier 1 | first response, known issues | runbook items | unresolved in [time] or sev ≥ [x] |
| Tier 2 | deeper diagnosis | most issues | needs code/infra change |
| Eng on-call | code/infra | the system | — |
3. The tree (routing) — by severity, the path and the time triggers:
SEV1 → page eng on-call immediately + notify manager; if unacked in 5 min → secondary; if 15 min → eng lead. Normal → tier-1; if unresolved in 1 business day → tier-2.
Show the branch logic clearly (who, after how long, to whom).
4. Contacts & roles — by role (not just names — names change): who fills each, primary/secondary, and how they're reached per severity (page vs. Slack vs. ticket).
5. Customer communication — the update cadence per severity (e.g. SEV1: status-page + update every 30 min; normal: reply within SLA). Who owns the customer comms vs. the fix.
6. After — for high-sev, the handoff to a postmortem (pair with incident-postmortem).
Quality Checks
- Severity levels have concrete qualifying criteria + response/resolution targets
- Each tier's ownership and "escalate when" condition is explicit
- Escalation triggers are time-boxed (after N minutes/days), not "when needed"
- Routing is defined by role with primary/secondary and the contact method per severity
- Customer-communication cadence is specified per level, with an owner
- High-severity paths hand off to a postmortem
Anti-Patterns
- Do not leave severity fuzzy — if "critical" is subjective, everything becomes critical (or nothing does)
- Do not write "escalate when needed" — time-box it so issues don't rot waiting on judgement
- Do not route to named people only — use roles with primary/secondary; people leave and go on holiday
- Do not forget customer comms in the tree — internal escalation without customer updates still feels like neglect
- Do not over-escalate everything — tiers exist so seniors see only what truly needs them
Based On
Support & incident-management practice — severity matrices, tiered ownership, time-based escalation, on-call routing.
版本历史
- a38bc30 当前 2026-07-05 11:34
