$npx -y skills add anthropics/knowledge-work-plugins --skill customer-escalationcustomer-escalation is an agent skill published from anthropics/knowledge-work-plugins, installable through the skills CLI.
| 1 | # /customer-escalation |
| 2 | |
| 3 | > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md). |
| 4 | |
| 5 | Package a support issue into a structured escalation brief for engineering, product, or leadership. Gathers context, structures reproduction steps, assesses business impact, and identifies the right escalation target. |
| 6 | |
| 7 | ## Usage |
| 8 | |
| 9 | ``` |
| 10 | /customer-escalation <issue description> [customer name or account] |
| 11 | ``` |
| 12 | |
| 13 | Examples: |
| 14 | - `/customer-escalation API returning 500 errors intermittently for Acme Corp` |
| 15 | - `/customer-escalation Data export is missing rows — 3 customers reported this week` |
| 16 | - `/customer-escalation SSO login loop affecting all Enterprise customers` |
| 17 | - `/customer-escalation Customer threatening to churn over missing audit log feature` |
| 18 | |
| 19 | ## Workflow |
| 20 | |
| 21 | ### 1. Understand the Issue |
| 22 | |
| 23 | Parse the input and determine: |
| 24 | |
| 25 | - **What's broken or needed**: The core technical or product issue |
| 26 | - **Who's affected**: Specific customer(s), segment, or all users |
| 27 | - **How long**: When did this start? How long has the customer been waiting? |
| 28 | - **What's been tried**: Any troubleshooting or workarounds attempted |
| 29 | - **Why escalate now**: What makes this need attention beyond normal support |
| 30 | |
| 31 | Use the "When to Escalate vs. Handle in Support" criteria below to confirm this warrants escalation. |
| 32 | |
| 33 | ### 2. Gather Context |
| 34 | |
| 35 | Pull together relevant information from available sources: |
| 36 | |
| 37 | - **~~support platform**: Related tickets, timeline of communications, previous troubleshooting |
| 38 | - **~~CRM** (if connected): Account details, key contacts, previous escalations |
| 39 | - **~~chat**: Internal discussions about this issue, similar reports from other customers |
| 40 | - **~~project tracker** (if connected): Related bug reports or feature requests, engineering status |
| 41 | - **~~knowledge base**: Known issues or workarounds, relevant documentation |
| 42 | |
| 43 | ### 3. Assess Business Impact |
| 44 | |
| 45 | Using the impact dimensions below, quantify: |
| 46 | |
| 47 | - **Breadth**: How many customers/users affected? Growing? |
| 48 | - **Depth**: Blocked vs. inconvenienced? |
| 49 | - **Duration**: How long has this been going on? |
| 50 | - **Revenue**: ARR at risk? Pending deals affected? |
| 51 | - **Time pressure**: Hard deadline? |
| 52 | |
| 53 | ### 4. Determine Escalation Target |
| 54 | |
| 55 | Using the escalation tiers below, identify the right target: L2 Support, Engineering, Product, Security, or Leadership. |
| 56 | |
| 57 | ### 5. Structure Reproduction Steps (for bugs) |
| 58 | |
| 59 | If the issue is a bug, follow the reproduction step best practices below to document clear repro steps with environment details and evidence. |
| 60 | |
| 61 | ### 6. Generate Escalation Brief |
| 62 | |
| 63 | ``` |
| 64 | ## ESCALATION: [One-line summary] |
| 65 | |
| 66 | **Severity:** [Critical / High / Medium] |
| 67 | **Target team:** [Engineering / Product / Security / Leadership] |
| 68 | **Reported by:** [Your name/team] |
| 69 | **Date:** [Today's date] |
| 70 | |
| 71 | ### Impact |
| 72 | - **Customers affected:** [Who and how many] |
| 73 | - **Workflow impact:** [What they can't do] |
| 74 | - **Revenue at risk:** [If applicable] |
| 75 | - **Time in queue:** [How long this has been an issue] |
| 76 | |
| 77 | ### Issue Description |
| 78 | [Clear, concise description of the problem — 3-5 sentences] |
| 79 | |
| 80 | ### What's Been Tried |
| 81 | 1. [Troubleshooting step and result] |
| 82 | 2. [Troubleshooting step and result] |
| 83 | 3. [Troubleshooting step and result] |
| 84 | |
| 85 | ### Reproduction Steps |
| 86 | [If applicable — follow the format below] |
| 87 | 1. [Step] |
| 88 | 2. [Step] |
| 89 | 3. [Step] |
| 90 | Expected: [X] |
| 91 | Actual: [Y] |
| 92 | Environment: [Details] |
| 93 | |
| 94 | ### Customer Communication |
| 95 | - **Last update to customer:** [Date and what was communicated] |
| 96 | - **Customer expectation:** [What they're expecting and by when] |
| 97 | - **Escalation risk:** [Will they escalate further if not resolved by X?] |
| 98 | |
| 99 | ### What's Needed |
| 100 | - [Specific ask — "investigate root cause", "prioritize fix", |
| 101 | "make product decision on X", "approve exception for Y"] |
| 102 | - **Deadline:** [When this needs resolution or an update] |
| 103 | |
| 104 | ### Supporting Context |
| 105 | - [Related tickets or links] |
| 106 | - [Internal discussion threads] |
| 107 | - [Documentation or logs] |
| 108 | ``` |
| 109 | |
| 110 | ### 7. Offer Next Steps |
| 111 | |
| 112 | After generating the escalation: |
| 113 | - "Want me to post this in a ~~chat channel for the target team?" |
| 114 | - "Should I update the customer with an interim response?" |
| 115 | - "Want me to set a follow-up reminder to check on this?" |
| 116 | - "Should I draft a customer-facing update with the current status?" |
| 117 | |
| 118 | --- |
| 119 | |
| 120 | ## When to Escalate vs. Handle in Support |
| 121 | |
| 122 | ### Handle in Support When: |
| 123 | - The issue has a documented solution or known workaround |
| 124 | - It's a configuration or setup issue you can resolve |
| 125 | - The customer needs guidance or training, not a fix |
| 126 | - The issue is a known limitation with a documented alternative |
| 127 | - Previous similar tickets were resolved at the support level |
| 128 | |
| 129 | ### Escalate When: |
| 130 | - **Technical**: Bug confirmed and needs a code fix, infrastructure investigation |