customer-escalation

Anthropic ｜ 商業與營運 ｜ 原文 ｜ Apache-2.0

把客戶問題整理成附完整背景的升級簡報，交給工程或管理層

---
name: customer-escalation
description: 把升級案件連同完整背景，整理好交給工程、產品或管理層。用在 bug 需要工程介入、超出一般支援處理範圍，多位客戶回報同一個問題、客戶威脅要流失，或問題已超過 SLA 仍未解決的時候。
argument-hint: "<issue summary> [customer name]"
---

# /customer-escalation

> 如果看到不熟的佔位符，或需要確認目前連了哪些工具，請看 [CONNECTORS.md](../../CONNECTORS.md)。

把支援問題整理成結構化的升級簡報，交給工程、產品或管理層。蒐集背景、整理重現步驟、評估商業影響，並找出正確的升級對象。

## 用法

```
/customer-escalation <issue description> [customer name or account]
```

範例：
- `/customer-escalation API returning 500 errors intermittently for Acme Corp`
- `/customer-escalation Data export is missing rows — 3 customers reported this week`
- `/customer-escalation SSO login loop affecting all Enterprise customers`
- `/customer-escalation Customer threatening to churn over missing audit log feature`

## 工作流程

### 1. 了解問題

解析輸入，判斷：

- **什麼壞了或需要什麼**：核心的技術或產品問題
- **誰受影響**：特定客戶、某個區隔，或所有使用者
- **多久了**：什麼時候開始的？客戶已經等了多久？
- **試過什麼**：嘗試過的任何疑難排解或替代做法
- **為什麼現在升級**：是什麼讓這件事需要超出一般支援的關注

用下面的「何時升級 vs. 在支援層處理」標準，確認這件事值得升級。

### 2. 蒐集背景

從可用的來源整理相關資訊：

- **~~support platform**：相關工單、溝通時間軸、先前的疑難排解
- **~~CRM**（如果有連接）：帳號詳細資料、主要聯絡人、先前的升級案件
- **~~chat**：關於這個問題的內部討論、其他客戶的類似回報
- **~~project tracker**（如果有連接）：相關的 bug 回報或功能需求、工程的狀態
- **~~knowledge base**：已知問題或替代做法、相關文件

### 3. 評估商業影響

用下面的影響維度，量化：

- **廣度**：有多少客戶／使用者受影響？在擴大嗎？
- **深度**：是被完全擋住，還是只是不方便？
- **持續時間**：這已經持續多久了？
- **營收**：有多少 ARR 有風險？有受影響的待簽 deal 嗎？
- **時間壓力**：有硬性期限嗎？

### 4. 決定升級對象

用下面的升級層級，找出正確的對象：L2 支援、工程、產品、資安，或管理層。

### 5. 整理重現步驟（針對 bug）

如果問題是 bug，就照下面的重現步驟最佳實務，寫出清楚的重現步驟，附上環境細節和證據。

### 6. 產生升級簡報

```
## ESCALATION: [一行摘要]

**Severity:** [Critical / High / Medium]
**Target team:** [Engineering / Product / Security / Leadership]
**Reported by:** [你的名字／團隊]
**Date:** [今天的日期]

### Impact
- **Customers affected:** [哪些、有多少]
- **Workflow impact:** [他們無法做什麼]
- **Revenue at risk:** [如果適用]
- **Time in queue:** [這個問題已經存在多久]

### Issue Description
[清楚、簡潔地描述問題，3-5 句]

### What's Been Tried
1. [疑難排解步驟與結果]
2. [疑難排解步驟與結果]
3. [疑難排解步驟與結果]

### Reproduction Steps
[如果適用，請依下面的格式]
1. [步驟]
2. [步驟]
3. [步驟]
Expected: [X]
Actual: [Y]
Environment: [細節]

### Customer Communication
- **Last update to customer:** [日期，以及溝通了什麼]
- **Customer expectation:** [他們期待什麼、何時前]
- **Escalation risk:** [如果沒在 X 之前解決，他們會再往上升級嗎？]

### What's Needed
- [具體的請求：「investigate root cause」「prioritize fix」、
  「make product decision on X」「approve exception for Y」]
- **Deadline:** [何時前需要解決或更新]

### Supporting Context
- [相關工單或連結]
- [內部討論串]
- [文件或 log]
```

### 7. 提供下一步

產生升級簡報之後：
- 「要我把這個貼到 ~~chat 頻道，給對應的團隊看嗎？」
- 「要不要先給客戶一個暫時性的回覆？」
- 「要我設一個跟進提醒來追蹤這件事嗎？」
- 「要我起草一份面向客戶、說明目前狀態的更新嗎？」

---

## 何時升級 vs. 在支援層處理

### 這些情況在支援層處理：
- 問題有已記錄的解決方案或已知的替代做法
- 是你能解決的設定或安裝問題
- 客戶需要的是指引或訓練，不是修復
- 問題是已知的限制，而且有記錄在案的替代方案
- 先前類似的工單是在支援層解決的

### 這些情況要升級：
- **技術面**：確認是 bug、需要改程式碼，需要調查基礎設施，資料毀損或遺失
- **複雜度**：問題超出支援能診斷的範圍，需要支援沒有的權限，涉及客製化實作
- **影響**：多位客戶受影響、正式環境系統當機、資料完整性有風險、有資安疑慮
- **商業面**：高價值客戶有風險、SLA 即將違約或已經違約、客戶要求高層介入
- **時間**：問題已超過 SLA、客戶已經等得不合理地久、一般支援管道沒有進展
- **模式**：同一個問題有 3 位以上客戶回報、據說已修好的問題又重複出現、嚴重程度隨時間升高

## 升級層級

### L1 → L2（支援層升級）
**來自：** 第一線支援
**交給：** 資深支援／技術支援專員
**何時：** 問題需要更深入的調查、專門的產品知識，或進階的疑難排解
**要附上什麼：** 工單摘要、已試過的步驟、客戶背景

### L2 → 工程
**來自：** 資深支援
**交給：** 工程團隊（相關的產品領域）
**何時：** 確認是 bug、基礎設施問題、需要改程式碼、需要系統層級的調查
**要附上什麼：** 完整的重現步驟、環境細節、log 或錯誤訊息、商業影響、客戶的時程

### L2 → 產品
**來自：** 資深支援
**交給：** 產品管理
**何時：** 功能缺口造成客戶痛點、需要設計決策、工作流程不符合客戶預期、互相競爭的客戶需求需要排優先順序
**要附上什麼：** 客戶的使用情境、商業影響、需求出現的頻率、競爭壓力（如果知道）

### 任何層級 → 資安
**來自：** 任何支援層級
**交給：** 資安團隊
**何時：** 可能的資料外洩、未經授權的存取、弱點回報、合規疑慮
**要附上什麼：** 觀察到什麼、可能影響到誰／什麼、已採取的立即圍堵措施、緊急程度評估
**注意：** 資安升級會跳過一般的層級流程：不論你在哪一層，都要立即升級

### 任何層級 → 管理層
**來自：** 任何層級（通常是 L2 或主管）
**交給：** 支援管理層、高階主管團隊
**何時：** 高營收客戶威脅要流失、關鍵帳號的 SLA 違約、需要跨部門決策、需要政策例外、有公關或法律風險
**要附上什麼：** 完整的商業背景、有風險的營收、已試過什麼、需要的具體決定或行動、期限

## 商業影響評估

升級時，盡量把影響量化：

### 影響維度

| 維度 | 要回答的問題 |
|-----------|-------------------|
| **廣度** | 有多少客戶／使用者受影響？在擴大嗎？ |
| **深度** | 他們受到多嚴重的影響？被擋住，還是只是不方便？ |
| **持續時間** | 這已經持續多久了？多久之後會變成緊急？ |
| **營收** | 有多少 ARR 有風險？有受影響的待簽 deal 嗎？ |
| **聲譽** | 這有可能公開嗎？這是參考客戶嗎？ |
| **合約** | SLA 有被違反嗎？有合約義務嗎？ |

### 嚴重程度速記

- **Critical**：正式環境當機、資料有風險、資安事件，或多位高價值客戶受影響。需要立即處理。
- **High**：主要功能壞了、關鍵客戶被擋住、SLA 有風險。需要當天處理。
- **Medium**：有替代做法的重大問題，商業影響重要但不緊急。需要本週處理。

## 撰寫重現步驟

好的重現步驟是 bug 升級裡最有價值的一件事。請遵循這些做法：

1. **從乾淨的狀態開始**：描述起點（帳號類型、設定、權限）
2. **要具體**：「Click the Export button in the top-right of the Dashboard page」，而不是「try to export」
3. **包含確切的值**：使用具體的輸入、日期、ID，不要寫「enter some data」
4. **註明環境**：瀏覽器、作業系統、帳號類型、feature flag、方案等級
5. **記下頻率**：每次都能重現？間歇性的？只在特定條件下？
6. **附上證據**：截圖、錯誤訊息（確切文字）、網路 log、console 輸出
7. **註明你已經排除了什麼**：「Tested in Chrome and Firefox — same behavior」「Not account-specific — reproduced on test account」

## 升級後的跟進節奏

不要升級完就不管了。要持續負責客戶關係。

| 嚴重程度 | 內部跟進 | 客戶更新 |
|----------|-------------------|-----------------|
| **Critical** | 每 2 小時 | 每 2-4 小時（或依 SLA） |
| **High** | 每 4 小時 | 每 4-8 小時 |
| **Medium** | 每天 | 每 1-2 個工作天 |

### 跟進行動
- 向接手的團隊確認進度
- 即使沒有新資訊也要更新客戶（「We're still investigating — here's what we know so far」）
- 如果情況改變（變好或變壞），就調整嚴重程度
- 把所有更新記錄在工單裡，作為稽核軌跡
- 解決時要收尾：向客戶確認、更新內部追蹤、記錄學到的教訓

## 降級

不是每個升級案件都會一直維持在升級狀態。出現以下情況時要降級：
- 找到根本原因，而且是支援層能解決的問題
- 找到能讓客戶解除阻礙的替代做法
- 問題自己消失了（但仍要記錄根本原因）
- 新資訊改變了嚴重程度的評估

降級時：
- 通知你當初升級給的團隊
- 在工單裡更新解決方式
- 通知客戶已經解決
- 把學到的東西記錄下來，供未來參考

## 升級最佳實務

1. 一定要量化影響：模糊的升級會被降低優先順序
2. bug 要附上重現步驟：這是工程最需要的第一件事
3. 要清楚說明你需要什麼：「調查」「修復」「決定」是不同的請求
4. 設定並傳達期限：沒有期限的急迫性是模糊的
5. 即使把技術問題升級出去了，也要持續負責客戶關係
6. 主動跟進：不要等接手的團隊來找你
7. 記錄一切：升級的軌跡對偵測模式和改善流程很有價值

---
name: customer-escalation
description: Package an escalation for engineering, product, or leadership with full context. Use when a bug needs engineering attention beyond normal support, multiple customers report the same issue, a customer is threatening to churn, or an issue has sat unresolved past its SLA.
argument-hint: "<issue summary> [customer name]"
---

# /customer-escalation

> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).

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.

## Usage

```
/customer-escalation <issue description> [customer name or account]
```

Examples:
- `/customer-escalation API returning 500 errors intermittently for Acme Corp`
- `/customer-escalation Data export is missing rows — 3 customers reported this week`
- `/customer-escalation SSO login loop affecting all Enterprise customers`
- `/customer-escalation Customer threatening to churn over missing audit log feature`

## Workflow

### 1. Understand the Issue

Parse the input and determine:

- **What's broken or needed**: The core technical or product issue
- **Who's affected**: Specific customer(s), segment, or all users
- **How long**: When did this start? How long has the customer been waiting?
- **What's been tried**: Any troubleshooting or workarounds attempted
- **Why escalate now**: What makes this need attention beyond normal support

Use the "When to Escalate vs. Handle in Support" criteria below to confirm this warrants escalation.

### 2. Gather Context

Pull together relevant information from available sources:

- **~~support platform**: Related tickets, timeline of communications, previous troubleshooting
- **~~CRM** (if connected): Account details, key contacts, previous escalations
- **~~chat**: Internal discussions about this issue, similar reports from other customers
- **~~project tracker** (if connected): Related bug reports or feature requests, engineering status
- **~~knowledge base**: Known issues or workarounds, relevant documentation

### 3. Assess Business Impact

Using the impact dimensions below, quantify:

- **Breadth**: How many customers/users affected? Growing?
- **Depth**: Blocked vs. inconvenienced?
- **Duration**: How long has this been going on?
- **Revenue**: ARR at risk? Pending deals affected?
- **Time pressure**: Hard deadline?

### 4. Determine Escalation Target

Using the escalation tiers below, identify the right target: L2 Support, Engineering, Product, Security, or Leadership.

### 5. Structure Reproduction Steps (for bugs)

If the issue is a bug, follow the reproduction step best practices below to document clear repro steps with environment details and evidence.

### 6. Generate Escalation Brief

```
## ESCALATION: [One-line summary]

**Severity:** [Critical / High / Medium]
**Target team:** [Engineering / Product / Security / Leadership]
**Reported by:** [Your name/team]
**Date:** [Today's date]

### Impact
- **Customers affected:** [Who and how many]
- **Workflow impact:** [What they can't do]
- **Revenue at risk:** [If applicable]
- **Time in queue:** [How long this has been an issue]

### Issue Description
[Clear, concise description of the problem — 3-5 sentences]

### What's Been Tried
1. [Troubleshooting step and result]
2. [Troubleshooting step and result]
3. [Troubleshooting step and result]

### Reproduction Steps
[If applicable — follow the format below]
1. [Step]
2. [Step]
3. [Step]
Expected: [X]
Actual: [Y]
Environment: [Details]

### Customer Communication
- **Last update to customer:** [Date and what was communicated]
- **Customer expectation:** [What they're expecting and by when]
- **Escalation risk:** [Will they escalate further if not resolved by X?]

### What's Needed
- [Specific ask — "investigate root cause", "prioritize fix",
  "make product decision on X", "approve exception for Y"]
- **Deadline:** [When this needs resolution or an update]

### Supporting Context
- [Related tickets or links]
- [Internal discussion threads]
- [Documentation or logs]
```

### 7. Offer Next Steps

After generating the escalation:
- "Want me to post this in a ~~chat channel for the target team?"
- "Should I update the customer with an interim response?"
- "Want me to set a follow-up reminder to check on this?"
- "Should I draft a customer-facing update with the current status?"

---

## 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

## 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

## Escalation Best Practices

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