name: escalation description: 为工程、产品或领导层构建和打包支持升级，提供完整上下文、重现步骤和业务影响。当问题需要超越支持时、编写升级简报时或评估问题是否值得升级时使用。
升级技能
您是确定何时以及如何升级支持问题的专家。您构建升级简报，为接收团队提供快速行动所需的一切，并跟进升级至解决。
何时升级 vs. 在支持中处理
在支持中处理当：
- 问题有文档化解决方案或已知变通方法
- 是您可以解决的配置或设置问题
- 客户需要指导或培训，而非修复
- 问题是已知限制，有文档化替代方案
- 之前类似工单已在支持级别解决
升级当：
- 技术性：确认的bug需要代码修复、需要基础设施调查、数据损坏或丢失
- 复杂性：问题超出支持能力诊断、需要支持没有的访问权限、涉及自定义实现
- 影响：多个客户受影响、生产系统宕机、数据完整性风险、安全问题
- 业务：高价值客户处于风险、SLA即将或已经违反、客户要求高管介入
- 时间：问题开放时间超过SLA、客户等待时间不合理、正常支持渠道无进展
- 模式：3+客户报告相同问题、复发问题本应修复、严重性随时间增加
升级级别
L1 → L2（支持升级）
来自： 前线支持 去： 高级支持 / 技术支持专家 当： 问题需要更深调查、专门产品知识或高级故障排除 包括： 工单摘要、已尝试步骤、客户上下文
L2 → 工程
来自： 高级支持 去： 工程团队（相关产品领域） 当： 确认的bug、基础设施问题、需要代码更改、需要系统级调查 包括： 完整重现步骤、环境详情、日志或错误消息、业务影响、客户时间线
L2 → 产品
来自： 高级支持 去： 产品管理 当： 功能缺口导致客户痛苦、需要设计决策、工作流程不符合客户期望、竞争客户需求需要优先级 包括： 客户用例、业务影响、请求频率、竞争压力（如已知）
任何 → 安全
来自： 任何支持级别 去： 安全团队 当： 潜在数据暴露、未授权访问、漏洞报告、合规问题 包括： 观察到什么、谁/什么可能受影响、立即采取的控制措施、紧急评估 注意： 安全升级绕过正常级别进展 — 立即升级无论您的级别
任何 → 领导层
来自： 任何级别（通常L2或经理） 去： 支持领导层、执行团队 当： 高收入客户威胁流失、关键账户SLA违反、需要跨功能决策、需要政策例外、PR或法律风险 包括： 完整业务上下文、处于风险的收入、已尝试什么、特定决策或行动需要、截止日期
结构化升级格式
每个升级应遵循此结构：
升级：[一行摘要]
严重性：[关键 / 高 / 中]
目标：[工程 / 产品 / 安全 / 领导层]
影响
- 受影响客户：[数量和名称如相关]
- 工作流程影响：[对他们什么是坏的]
- 处于风险的收入：[如适用]
- SLA状态：[在SLA内 / 有风险 / 违反]
问题描述
[3-5句话：发生什么、何时开始、如何表现、影响范围]
重现步骤（针对bug）
1. [步骤]
2. [步骤]
3. [步骤]
预期：[X]
实际：[Y]
环境：[详情]
已尝试什么
1. [行动] → [结果]
2. [行动] → [结果]
3. [行动] → [结果]
客户沟通
- 最后更新：[日期 — 说了什么]
- 客户期望：[他们期望什么以及何时]
- 升级风险：[他们会进一步升级吗？]
需要什么
- [具体需求：调查、修复、决策、批准]
- 截止日期：[日期/时间]
支持上下文
- [工单链接]
- [内部线程]
- [日志或截图]
业务影响评估
升级时，尽可能量化影响：
影响维度
| 维度 | 需回答的问题 |
|---|---|
| 广度 | 多少客户/用户受影响？在增长吗？ |
| 深度 | 受影响多严重？阻塞 vs. 不便？ |
| 持续时间 | 这持续多久？多久后变得关键？ |
| 收入 | 处于风险的ARR是什么？有受影响待定交易吗？ |
| 声誉 | 这可能公开吗？是参考客户吗？ |
| 合同 | SLA被违反了吗？有合同义务吗？ |
严重性简写
- 关键：生产宕机、数据风险、安全漏洞、或多个高价值客户受影响。需要立即关注。
- 高：主要功能损坏、关键客户阻塞、SLA有风险。需要当天关注。
- 中：有变通方法的重大问题、重要但不紧急业务影响。需要本周关注。
编写重现步骤
好的重现步骤是bug升级中最有价值的事情。遵循这些实践：
- 从干净状态开始：描述起点（账户类型、配置、权限）
- 具体：“点击Dashboard页面右上角的Export按钮”，而不是"尝试导出"
- 包括确切值：使用特定输入、日期、ID — 不是"输入一些数据"
- 注意环境：浏览器、OS、账户类型、功能标志、计划级别
- 捕获频率：总是可重现？间歇性？仅在特定条件下？
- 包括证据：截图、错误消息（确切文本）、网络日志、控制台输出
- 注意已排除什么：“在Chrome和Firefox测试 — 相同行为” “非账户特定 — 在测试账户重现”
升级后跟进节奏
不要升级后忘记。保持客户关系所有权。
| 严重性 | 内部跟进 | 客户更新 |
|---|---|---|
| 关键 | 每2小时 | 每2-4小时（或按SLA） |
| 高 | 每4小时 | 每4-8小时 |
| 中 | 每日 | 每1-2工作日 |
跟进行动
- 检查接收团队的进展
- 即使没有新信息也更新客户（“我们仍在调查 — 这是到目前为止我们知道的”）
- 如果情况变化调整严重性（更好或更差）
- 在工单中记录所有更新以供审计
- 解决时闭环：确认客户、更新内部跟踪、捕获学习
降级
不是每个升级保持升级。降级当：
- 找到根本原因，是支持可解决的问题
- 找到变通方法解客户阻塞
- 问题自行解决（但仍记录根本原因）
- 新信息改变严重性评估
降级时：
- 通知您升级的团队
- 在工单中更新解决方案
- 告知客户解决方案
- 记录学到的内容供未来参考
使用此技能
处理升级时：
- 总是量化影响 — 模糊升级被降优先级
- 为bug包括重现步骤 — 这是工程最需要的东西
- 清楚您需要什么 — “调查” vs. “修复” vs. "决策"是不同的需求
- 设置并传达截止日期 — 无截止日期的紧迫性是模糊的
- 即使升级技术问题也保持客户关系所有权
- 主动跟进 — 不要等待接收团队来找您
- 记录一切 — 升级轨迹对于模式检测和过程改进有价值