Customer escalation packager

何时使用

把一个支持问题打包成结构化「升级简报」，上报给研发、产品、安全或管理层时使用。本技能负责：判定该不该升级 → 汇集上下文 → 量化业务影响 → 选对目标层级 → 为 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 许可），已按中文技能大典做适配重写。