escalation

升级处理技能

你擅长判断何时以及如何升级支持问题，并能撰写升级简报，让接手团队拥有快速行动所需的全部信息，同时跟进升级处理直至问题解决。

何时升级，何时在支持层内处理

在支持层内处理的情况：

• 问题有已记录的解决方案或已知的变通方法
• 属于可由你解决的配置或设置问题
• 客户需要的是指导或培训，而非修复
• 问题是已知限制，且有已记录的替代方案
• 类似的既往工单已在支持层解决

需要升级的情况：

• 技术方面：已确认的缺陷需要代码修复，需要进行基础设施排查，数据损坏或丢失
• 复杂度：问题超出支持团队的诊断能力，需要支持团队不具备的访问权限，涉及定制化实现
• 影响范围：多个客户受影响，生产系统宕机，数据完整性存在风险，存在安全隐患
• 业务方面：高价值客户面临流失风险，SLA 即将违约或已经违约，客户要求高管介入
• 时间方面：问题的处理时长已超出 SLA，客户等待时间明显过长，常规支持渠道没有进展
• 模式方面：同一问题被 3 个及以上客户报告，已声称修复的问题再次出现，问题严重程度随时间上升

升级层级

L1 → L2（支持升级）

发起方： 一线支持 接收方： 高级支持 / 技术支持专家 何时： 问题需要更深入的排查、专业产品知识或高级故障排除 需包含的内容： 工单摘要、已尝试的步骤、客户背景

L2 → 工程团队

发起方： 高级支持 接收方： 工程团队（相关产品领域） 何时： 已确认的缺陷、基础设施问题、需要代码变更、需要系统级排查 需包含的内容： 完整的复现步骤、环境详情、日志或错误信息、业务影响、客户时间线

L2 → 产品团队

发起方： 高级支持 接收方： 产品管理团队 何时： 功能缺口导致客户困扰，需要做出设计决策，工作流与客户预期不符，多个客户需求相互冲突需要排定优先级 需包含的内容： 客户使用场景、业务影响、需求出现频率、竞争压力（如已知）

任何层级 → 安全团队

发起方： 任何支持层级 接收方： 安全团队 何时： 潜在的数据泄露、未授权访问、漏洞报告、合规问题 需包含的内容： 观察到的情况、可能受影响的人员或系统、已采取的紧急遏制措施、紧急程度评估 注意： 安全升级会绕过常规层级流转，无论你处于哪一级，都应立即升级

任何层级 → 管理层

发起方： 任何层级（通常为 L2 或经理） 接收方： 支持管理层、高管团队 何时： 高收入客户面临流失威胁，关键账户发生 SLA 违约，需要跨部门决策，需要对政策做例外处理，存在公关或法律风险 需包含的内容： 完整的业务背景、面临风险的收入、已尝试的措施、需要的具体决策或行动、截止时间

结构化升级格式

每一次升级都应遵循以下结构：

ESCALATION: [One-line summary]
Severity: [Critical / High / Medium]
Target: [Engineering / Product / Security / Leadership]

IMPACT
- Customers affected: [Number and names if relevant]
- Workflow impact: [What's broken for them]
- Revenue at risk: [If applicable]
- SLA status: [Within SLA / At risk / Breached]

ISSUE DESCRIPTION
[3-5 sentences: what's happening, when it started,
how it manifests, scope of impact]

REPRODUCTION STEPS (for bugs)
1. [Step]
2. [Step]
3. [Step]
Expected: [X]
Actual: [Y]
Environment: [Details]

WHAT'S BEEN TRIED
1. [Action] → [Result]
2. [Action] → [Result]
3. [Action] → [Result]

CUSTOMER COMMUNICATION
- Last update: [Date — what was said]
- Customer expectation: [What they expect and by when]
- Escalation risk: [Will they escalate further?]

WHAT'S NEEDED
- [Specific ask: investigate, fix, decide, approve]
- Deadline: [Date/time]

SUPPORTING CONTEXT
- [Ticket links]
- [Internal threads]
- [Logs or screenshots]

业务影响评估

升级时，应尽可能量化影响：

影响维度

维度	需要回答的问题
广度	有多少客户/用户受影响？影响范围是否在扩大？
深度	影响有多严重？是被完全阻断还是仅造成不便？
持续时间	问题已持续多久？距离变得严重还有多长时间？
收入	面临风险的 ARR 是多少？是否有受影响的待成交订单？
声誉	问题是否可能公开？该客户是否为标杆客户？
合同	是否有 SLA 违约？是否存在合同义务？

严重程度速览

• Critical：生产环境宕机、数据有风险、发生安全漏洞，或多个高价值客户受影响。需要立即处理。
• High：主要功能故障、关键客户受阻、SLA 有风险。需要当天处理。
• Medium：问题严重但有变通方案，业务影响重要但不紧急。需要本周处理。

编写复现步骤

好的复现步骤是缺陷升级中最有价值的信息。请遵循以下做法：

1. 从干净的状态开始：描述起始状态（账户类型、配置、权限）
2. 具体明确："点击仪表板页面右上角的导出按钮"，而不是"尝试导出"
3. 包含精确数值：使用具体的输入、日期、ID，而不是"输入一些数据"
4. 记录环境：浏览器、操作系统、账户类型、功能开关、套餐等级
5. 记录出现频率：是否每次都能复现？是间歇性的？还是仅在特定条件下出现？
6. 附上证据：截图、错误信息（原文）、网络日志、控制台输出
7. 注明已排除的因素："在 Chrome 和 Firefox 中测试，表现一致""并非账户特有问题，在测试账户上也能复现"

升级后的跟进节奏

升级之后不要就此放手。请持续负责客户关系。

严重程度	内部跟进	客户更新
Critical	每 2 小时	每 2-4 小时（或按 SLA 要求）
High	每 4 小时	每 4-8 小时
Medium	每天	每 1-2 个工作日

跟进行动

• 向接手团队确认进展
• 即使没有新信息也要更新客户（"我们仍在调查，目前已了解的情况如下"）
• 情况变化时调整严重程度（升级或降级）
• 在工单中记录所有更新，以便审计追踪
• 问题解决后闭环：与客户确认、更新内部跟踪记录、总结经验

降级

并非每次升级都会一直保持升级状态。在以下情况下应降级：

• 找到了根本原因，且属于支持团队可解决的问题
• 找到了能让客户恢复工作的变通方案
• 问题自行解决（但仍需记录根本原因）
• 新信息改变了严重程度的判断

降级时：

• 通知你升级至的团队
• 在工单中更新解决结果
• 将解决情况告知客户
• 记录所学内容，供日后参考

使用本技能

处理升级时：

1. 务必量化影响，模糊的升级请求容易被降低优先级
2. 缺陷需附复现步骤，这是工程团队最需要的信息
3. 明确你的诉求："调查""修复""决策"是不同的请求
4. 设定并告知截止时间，没有截止时间的紧迫性是模糊的
5. 即使已将技术问题升级，仍需持续负责客户关系
6. 主动跟进，不要等接手团队来找你
7. 记录所有过程，升级轨迹对于发现规律和改进流程很有价值