stephenrogan/escalation-decision-framework

Escalation Decision Framework

Helps with the judgment call: should I escalate this, and if so, to whom? The skill addresses the decision, not the documentation. Most CSMs either escalate too late (waiting until the situation is critical) or too rarely (absorbing issues they should not be absorbing alone).

How to Use

Provide:

• The issue (what is happening)
• The customer impact (how it affects their business)
• What you have tried (your resolution attempts so far)
• The account context (ARR, health, renewal proximity, strategic importance)
• Your gut feel (do you think you can resolve this, or do you need help?)

The Escalation Decision Matrix

Score the situation on four dimensions:

| Dimension | 1 (Low) | 3 (Medium) | 5 (High) | |-----------|---------|-----------|----------| | Customer impact | Inconvenience. Workaround exists. No business disruption | Moderate disruption. Workaround is painful. Some business impact | Severe disruption. No workaround. Direct business or revenue impact | | Account value | <EUR 10k ARR, non-strategic | EUR 10-50k ARR or moderate strategic value | >EUR 50k ARR or high strategic value (logo, reference, board-level) | | Time sensitivity | Can be addressed within normal cadence (1-2 weeks) | Needs resolution within days | Needs resolution today. Delay creates compounding damage | | CSM capability | You can resolve this with existing resources and authority | You need input or resources you do not have, but the issue is defined | The issue is beyond your expertise, authority, or access. You cannot resolve it alone |

Decision logic:

| Score Range | Decision | |------------|---------| | 4-8 | Handle it yourself. Standard CSM resolution. No escalation needed | | 9-13 | Escalate for support. You need resources, not rescue. Route to the appropriate team with a clear ask | | 14-17 | Escalate with urgency. This requires attention beyond your level. Route to CS leadership and the relevant functional team | | 18-20 | Escalate immediately. Executive-level attention. Same-day routing to CS leadership and potentially CRO |

Escalation Routing Guide

| Issue Type | Route To | When | |-----------|---------|------| | Product defect (technical) | Engineering via support platform | When the issue cannot be resolved through standard support channels within SLA | | Feature gap blocking the customer | Product management | When the gap is affecting retention and there is no workaround | | Service failure (SLA breach, repeated issues) | CS leadership + support leadership | When the pattern indicates a systemic problem, not a one-off | | Commercial dispute (billing, contract, pricing) | CS leadership + finance | When the customer disputes terms the CSM cannot resolve | | Relationship at risk (trust damage, champion frustration) | CS leadership | When the relationship damage exceeds what the CSM can repair alone | | Executive intervention needed | CRO or CEO office (via CS leadership) | When the situation requires a peer-level response from your leadership | | Cross-functional coordination | Relevant team leads | When the resolution requires coordinated action across teams the CSM does not control |

Common Escalation Mistakes

| Mistake | Why It Happens | How to Avoid | |---------|---------------|-------------| | Escalating too late | CSM tries to handle everything themselves. By the time they escalate, the customer is furious and the issue is entrenched | Set a personal "if I cannot resolve this in [X] days, I escalate" rule. The threshold depends on severity | | Escalating too broadly | CSM panics and involves everyone. Leadership, engineering, product, support -- all get the same message | Route to one team with a specific ask. Others can be informed later if needed | | Escalating without context | CSM says "customer is unhappy, please help" without providing the history, the ask, or the commercial context | Use the escalation-brief-writer skill to structure the brief before routing | | Escalating instead of communicating | CSM escalates internally but does not tell the customer what is happening. The customer feels ignored | Always communicate with the customer in parallel: "I have escalated this to [team] and expect an update by [date]" | | Not escalating because "it is not that bad" | CSM underestimates the severity because they are too close to the situation | Ask yourself: "If my manager heard about this from the customer instead of from me, would they be surprised?" If yes, escalate | | Escalating as a complaint, not an ask | CSM describes the problem but does not say what they need | Every escalation must include a specific ask: "I need engineering to investigate [X] and provide a fix or timeline by [date]" |

Output Format

## Escalation Assessment: [Account Name]

### Situation
[2-3 sentences: what is happening]

### Scoring
| Dimension | Score | Rationale |
|-----------|-------|-----------|
| Customer impact | [1-5] | [why] |
| Account value | [1-5] | [why] |
| Time sensitivity | [1-5] | [why] |
| CSM capability | [1-5] | [why] |
| **Total** | **[4-20]** | |

### Decision
[Handle yourself / Escalate for support / Escalate with urgency / Escalate immediately]

### If Escalating
- Route to: [team/person]
- Specific ask: [what you need]
- By when: [deadline]
- Customer communication: [what the customer needs to hear, and when]

Quality Gates

• Did you score all four dimensions honestly? The temptation is to underweight "CSM capability" because admitting you need help feels uncomfortable. Asking for help early is a sign of judgment, not weakness
• Is the specific ask clear? If you are escalating, the receiving team should know exactly what you need from them. "Help" is not an ask
• Have you communicated with the customer? An internal escalation without a customer communication is half an escalation. They need to know you are taking action

Principles

• Escalation is a tool, not a failure. A CSM who escalates appropriately is demonstrating judgment. A CSM who never escalates is either handling everything (unlikely for a large portfolio) or absorbing issues they should not be
• The customer should never find out about an escalation before you tell them. If they hear from engineering before they hear from you, you have lost control of the narrative
• Speed of escalation matters more than perfection of documentation. A brief escalation today is better than a detailed escalation next week. You can supplement the brief once the escalation is in motion
• The "would my manager be surprised?" test is the best escalation heuristic. If the answer is yes, escalate. If the answer is "probably not, but I'm not sure," escalate. If the answer is definitely not, handle it yourself