Customer Escalation Packager

---
name: customer-escalation-packager
title: 客户问题升级打包
description: 当一个支持问题超出常规客服范畴、需上报研发/产品/安全/管理层时使用（确诊 bug 需改代码、多客户同问题、高价值客户欲流失、超 SLA 未解、疑似安全事件）；做的事是判定是否该升级、跨工单/CRM/聊天/项目板汇集上下文、量化业务影响（广度/深度/时长/营收/时压）、选对升级目标层级、为 bug 写可复现步骤，并产出结构化「升级简报」与跟进节奏；不适用于已有文档解法或可在客服层自助解决的工单、也不替你执行修复或发客户邮件（仅打包升级）。触发词：升级、escalate、escalation、上报研发、SLA breach、客户要流失、churn risk、多客户同 bug、安全升级、升级简报、复现步骤、reproduction steps
domain: 商业/copy
triggers: [升级, escalate, escalation, 上报研发, SLA breach, 客户要流失, churn risk, 多客户同bug, 安全升级, 升级简报, 复现步骤, reproduction steps, L2, engineering escalation, 业务影响评估, severity]
tags: [customer-support, escalation, incident, triage, sla, reproduction-steps, business-impact]
level: 进阶
status: stable
agents: [claude-code, codex, cursor, gemini-cli]
tools: []
requires: []
related: [support-ticket-triage, customer-response-drafter, ai-customer-support, customer-health-scorer]
combines_with: [support-ticket-triage, bug-hunter, stakeholder-update-writer]
license: Apache-2.0
source: anthropics/knowledge-work-plugins
source_license: Apache-2.0
---
## 何时使用

把一个支持问题打包成结构化「升级简报」，上报给研发、产品、安全或管理层时使用。本技能负责：判定该不该升级 → 汇集上下文 → 量化业务影响 → 选对目标层级 → 为 bug 写复现步骤 → 产出简报 → 给出跟进节奏。

**该升级（满足任一）**：
- 技术：确诊 bug 需改代码、基础设施需排查、数据损坏或丢失。
- 复杂度：超出客服诊断能力、需要客服没有的访问权限、涉及定制实现。
- 影响：多客户受影响、生产系统宕机、数据完整性/安全受威胁。
- 业务：高价值客户面临流失、SLA 即将/已经违约、客户要求高管介入。
- 时间：已超 SLA、客户等待过久、常规客服渠道推不动。
- 模式：同一问题 3+ 客户上报、「修过又复发」、严重度持续升级。

**不该用（留在客服层自处理）**：有文档解法或已知 workaround、配置/安装类可自行解决、客户需要的是指导/培训而非修复、是有文档替代方案的已知限制、同类历史工单都在客服层解决了。

## 步骤

1. **理解问题**：拆出——坏了/缺了什么（核心技术或产品问题）｜谁受影响（具体客户/客群/全量）｜多久了（何时起、客户等了多久）｜试过什么（已做的排障/workaround）｜为何现在升级（超出常规客服的点）。对照上面的判据确认确实该升级。
2. **汇集上下文**：从可用源拉取——支持平台（相关工单、沟通时间线、过往排障）｜CRM（账户详情、关键联系人、历史升级）｜内部聊天（相关讨论、其他客户的类似上报）｜项目跟踪器（关联 bug/需求、研发状态）｜知识库（已知问题/workaround、相关文档）。
3. **评估业务影响**（量化，见「指令·影响维度」）：广度、深度、时长、营收、时间压力。
4. **定升级目标**：按「指令·升级层级」选对 L2 / 研发 / 产品 / 安全 / 管理层。**安全类立即升级，跳过常规层级递进。**
5. **写复现步骤（仅 bug）**：按「指令·复现步骤七要点」写清环境与证据。
6. **生成升级简报**：套用「示例」模板。
7. **给出下一步**：是否发到目标团队的聊天频道？是否给客户发临时回复？是否设跟进提醒？是否起草一份对客状态更新？

## 指令

**升级层级（From → To｜何时｜简报须含）**：
- **L1 → L2**：前线客服 → 资深/技术客服。需更深排查、专业产品知识或高级排障。含：工单摘要、已试步骤、客户背景。
- **L2 → 研发**：资深客服 → 对应产品域研发。确诊 bug、基础设施问题、需改代码、需系统级排查。含：完整复现步骤、环境详情、日志/报错、业务影响、客户时间线。
- **L2 → 产品**：→ 产品管理。功能缺口致客户痛、需设计决策、流程不符客户预期、多客户需求需排优先级。含：客户用例、业务影响、需求频次、竞争压力（若知）。
- **任意 → 安全**：→ 安全团队。疑似数据暴露、越权访问、漏洞上报、合规隐患。含：观察到什么、谁/什么可能受影响、已采取的即时控制、紧急度评估。**立即升级，不走层级递进。**
- **任意 → 管理层**（通常 L2/主管发起）：→ 客服负责人、高管。高营收客户欲流失、关键账户 SLA 违约、需跨职能决策、需破例、PR/法律风险。含：完整业务背景、营收风险、已试方案、具体所需决策/行动、截止时间。

**业务影响·影响维度**：

| 维度 | 要回答的问题 |
|---|---|
| 广度 | 多少客户/用户受影响？在扩大吗？ |
| 深度 | 多严重？被完全阻塞 vs 仅不便？ |
| 时长 | 持续多久了？多久会变临界？ |
| 营收 | 多少 ARR 有风险？影响待签单吗？ |
| 声誉 | 会公开化吗？是否标杆客户？ |
| 合约 | 是否违反 SLA？有无合约义务？ |

**严重度速记**：Critical = 生产宕机/数据风险/安全事件/多个高价值客户受影响，需即刻处理；High = 主功能损坏/关键客户被阻塞/SLA 有风险，需当日处理；Medium = 有 workaround 的重要问题，本周处理。

**复现步骤七要点（bug 升级里最有价值的东西）**：① 从干净状态起（账户类型/配置/权限）；② 具体（「点 Dashboard 右上角 Export 按钮」而非「试着导出」）；③ 精确值（具体输入/日期/ID，别用「随便填点数据」）；④ 注明环境（浏览器/OS/账户类型/功能开关/套餐）；⑤ 复现频率（必现/间歇/特定条件）；⑥ 带证据（截图、报错原文、网络/控制台日志）；⑦ 注明已排除项（「Chrome+Firefox 同现象」「非账户特有，测试账户可复现」）。

**升级后跟进节奏（别一升了之，保持对客户关系的 ownership）**：

| 严重度 | 内部跟进 | 对客更新 |
|---|---|---|
| Critical | 每 2 小时 | 每 2-4 小时（或按 SLA） |
| High | 每 4 小时 | 每 4-8 小时 |
| Medium | 每日 | 每 1-2 工作日 |

跟进动作：向接收团队问进展；即便无新信息也更新客户（「仍在排查，目前已知…」）；情况变化（好转/恶化）随时调严重度；所有更新写入工单留审计轨；解决后闭环——向客户确认、更新内部跟踪、沉淀经验。

**降级（de-escalation）**：找到根因且属客服可解、找到 workaround 已解阻塞、问题自愈（仍要记录根因）、新信息改变了严重度判定。降级时：通知被升级的团队、工单写入解决方案、告知客户、沉淀经验。

## 示例

升级简报模板：

```
## 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. [排障步骤及结果]

### Reproduction Steps
1. [步骤]
2. [步骤]
Expected: [X]
Actual: [Y]
Environment: [详情]

### Customer Communication
- **Last update to customer:** [日期 + 沟通了什么]
- **Customer expectation:** [他们期待什么、何时要]
- **Escalation risk:** [若 X 前未解会否进一步升级]

### What's Needed
- [具体诉求 —— "查根因"/"排优先级修复"/"对 X 做产品决策"/"批准 Y 的例外"]
- **Deadline:** [何时需解决或给更新]

### Supporting Context
- [相关工单/链接] · [内部讨论串] · [文档或日志]
```

## 注意事项

- **务必量化影响**——模糊的升级会被降优先级。
- **bug 必带复现步骤**——这是研发最需要的第一项。
- **说清诉求**——"调查" / "修复" / "决策" 是不同的 ask，别混。
- **设并传达截止时间**——只讲紧急不给 deadline 等于含糊。
- **升级后仍保持对客户关系的 ownership**，主动跟进，别等接收团队来找你。
- **安全类立即升级**，不走层级递进。
- **全程留痕**——升级轨迹对模式识别与流程改进很有价值。

## 互见

- related：`ai-customer-support` —— 工单路由/SLA 升级与情感分析的自动化侧，上游接住该升级的工单。
- related：`churn-prevention` —— 当升级动因是「客户欲流失」时，留存与挽留侧的体系化打法。
- related：`customer-research-synthesizer` —— 同一问题被 3+ 客户上报时，把工单/反馈聚类成产品洞察。

---

本条采编自 anthropics/knowledge-work-plugins 的 `customer-escalation`（Apache-2.0 许可），已按中文技能大典做适配重写。