escalation-brief

决策：升级处理还是内部解决？

以下情况由支持团队处理：

• 有文档记录的修复方案或已知变通方法可以解决问题
• 根本原因是你可以纠正的配置或设置错误
• 客户需要的是指导或培训，而非产品变更
• 该限制已有文档说明，且存在替代方案
• 具有相同特征的历史工单已由支持团队解决

以下情况应升级处理：

• 技术障碍：已确认的缺陷需要通过代码修复，需要进行基础设施层面的调查，或数据已丢失或损坏
• 诊断能力不足：问题超出支持工具或访问权限的范围，涉及自定义部署，或需要检查数据库
• 广泛影响：多个客户报告同一问题、生产环境宕机、数据完整性受损，或存在安全威胁
• 业务影响重大：高价值客户面临流失风险、SLA 已违约或即将违约，或客户要求管理层介入
• 进展停滞：问题在 SLA 期限后仍未解决、客户等待时间过长，或常规故障排查未能推进问题
• 反复出现：有三起或以上相互独立的相同症状报告、先前已修复的问题再次出现，或严重程度随时间加剧

升级处理对象

从支持 L1 升级至支持 L2

发送方： 一线支持 Agent 接收方： 高级支持人员／技术专家 触发条件： 需要深入调查、专业产品知识或高级调试 材料内容： 问题摘要、已进行的故障排查、客户背景

从支持 L2 升级至工程团队

发送方： 高级支持人员 接收方： 负责该问题的工程团队 触发条件： 已确认的缺陷、基础设施故障、需要更改代码或进行系统级检查 材料内容： 完整的复现步骤、环境详情、相关日志和错误输出、业务影响说明、面向客户的时间线承诺

从支持 L2 升级至产品团队

发送方： 高级支持人员 接收方： 产品管理团队 触发条件： 能力缺口造成困扰、需要作出设计层面的决策、工作流不匹配，或不同客户之间存在优先级冲突 材料内容： 客户使用场景说明、业务影响、请求频率，以及可用时提供的竞争情况

从任何级别升级至安全团队

发送方： 任何支持 Agent 接收方： 安全团队 触发条件： 可能的数据泄露、未授权访问报告、漏洞披露或合规风险 材料内容： 观察到的情况、受影响的相关方／系统、已采取的遏制措施、紧急程度评级 规则： 安全问题的升级无需逐级进行——无论你处于哪个级别，都应立即转交。

从任何级别升级至管理层

发送方： 通常为 L2 或支持经理 接收方： 支持管理层或高管 触发条件： 高年度经常性收入（ARR）客户表示可能流失、战略客户的 SLA 违约、需要跨职能决策、需要政策例外，或存在法律或声誉风险 材料内容： 完整的业务背景、收入风险敞口、迄今采取的措施、所需的具体决策或干预，以及明确的截止时间

升级文档结构

按照以下框架整理每一份升级材料：

ESCALATION: [Concise one-line summary]
Severity: [Critical / High / Medium]
Routed to: [Engineering / Product / Security / Leadership]

BUSINESS IMPACT
- Affected customers: [Count and names where relevant]
- Operational effect: [What is broken for them]
- Revenue exposure: [Dollar figure if applicable]
- SLA position: [Compliant / At risk / Breached]

PROBLEM NARRATIVE
[3-5 sentences covering: what is happening, when it began,
how it presents, and how wide the blast radius is]

REPRODUCTION PROCEDURE (for defects)
1. [Step]
2. [Step]
3. [Step]
Expected outcome: [X]
Observed outcome: [Y]
Environment: [Browser, OS, plan tier, feature flags, etc.]

ACTIONS ALREADY TAKEN
1. [What was tried] -> [Outcome]
2. [What was tried] -> [Outcome]
3. [What was tried] -> [Outcome]

CUSTOMER COMMUNICATION STATUS
- Most recent update: [Date and summary]
- Customer expectation: [What they believe will happen and by when]
- Further escalation risk: [Likelihood customer escalates beyond you]

REQUEST
- [Precise ask: investigate / ship a fix / make a decision / approve an exception]
- Hard deadline: [Date/time]

ATTACHMENTS AND REFERENCES
- [Ticket URLs]
- [Internal discussion threads]
- [Log files, screenshots, recordings]

量化业务影响

模糊的升级请求往往会被降低优先级。每次升级都应围绕以下维度，以可衡量的影响为依据：

维度	关键问题
范围	影响了多少客户或最终用户？人数是否还在增加？
程度	他们是完全无法继续工作，还是仅受到些许影响？
持续时间	这种情况持续了多久？什么时候会变得紧急？
收入	有多少年度经常性收入（ARR）面临风险？商机管道中的交易是否受到影响？
声誉	这件事可能会出现在社交媒体或新闻报道中吗？是否涉及标杆客户？
合同	是否违反了 SLA 条款？是否会产生合同罚款？

快速严重程度定义

• 严重：服务中断、数据面临风险、发生正在进行的安全事件，或多个高价值客户受到影响。需要立即采取行动。
• 高：核心功能不可用、关键客户受阻，或即将达到 SLA 阈值。需要当天跟进。
• 中：问题影响显著，但存在可行的解决方法；业务影响确实存在，但并非时间紧迫。需要在本周内解决。

编写有效的复现步骤

精确的复现说明是任何缺陷升级中最有价值的部分。

1. 说明初始状态：描述账户类型、配置、权限和任何前置条件。
2. 明确具体操作：使用“在 Reports 视图右上角选择 Export CSV 按钮”，而不是“尝试导出”。
3. 提供实际输入：给出使用的数据值、ID 或字符串，而不是“输入一个值”。
4. 记录环境信息：浏览器及版本、操作系统、账户套餐等级、已启用的功能标志。
5. 说明发生频率：每次都能复现？偶尔发生？只在特定条件下发生？
6. 附上证据：屏幕截图、完整错误文本、网络跟踪记录、浏览器控制台输出。
7. 记录已排除的因素：“在 Chrome 122 和 Safari 17 中均可复现”／“在预发布环境和生产环境中均会发生”。

升级后的持续跟进

升级后不跟进就是弃之不顾。请持续关注：

严重程度	与接收团队的跟进频率	面向客户的更新频率
严重	每 2 小时一次	每 2–4 小时一次（或按 SLA 要求）
高	每 4 小时一次	每 4–8 小时一次
中	每天一次	每 1–2 个工作日一次

持续职责

• 主动联系接收团队了解进展，不要等对方告知。
• 即使没有新进展，也要告知客户：“调查仍在进行，以下是目前已确认的信息。”
• 如果情况发生变化，应重新评估严重程度。
• 在工单中持续记录所有更新，以便审计。
• 问题解决后：向客户确认，关闭内部跟踪，并总结经验教训。

了解何时降低升级级别

升级并非永久状态。在以下情况下，应撤回问题升级：

• 调查发现了支持团队可以直接处理的原因
• 找到了能够彻底解除客户阻碍的解决方法
• 问题自行解决（但仍应记录根本原因）
• 更新的信息改变了严重程度评估

降级流程

• 通知接收升级的团队
• 在工单中记录解决情况或新状态
• 向客户说明处理结果
• 记录调查结果，让未来的 Agent 也能从中受益

运营原则

1. 用数字量化影响，而不是用形容词——可衡量的升级事项能更快得到关注。
2. 对于缺陷，复现步骤必不可少——这是工程团队最需要的信息。
3. 明确你的诉求：“调查”“修复”和“决策”是不同的请求，对应不同的负责人。
4. 为每项升级事项附上截止时间——没有时间安排的紧迫性含糊不清。
5. 始终由你负责维护客户关系；升级技术工作并不会转移这项责任。
6. 主动跟进，不要等别人催促——主动更新能增进客户和接收团队对你的信任。
7. 记录所有信息——升级记录是用于发现模式和改进流程的资源。