customer-escalation

/customer-escalation

如果你看到不熟悉的占位符，或需要检查已连接的工具，请参阅 CONNECTORS.md。

将支持问题整理为结构化的升级简报，供工程、产品或管理层使用。收集上下文、梳理复现步骤、评估业务影响，并确定合适的升级对象。

用法

/customer-escalation <issue description> [customer name or account]

示例：

• /customer-escalation API returning 500 errors intermittently for Acme Corp
• /customer-escalation Data export is missing rows — 3 customers reported this week
• /customer-escalation SSO login loop affecting all Enterprise customers
• /customer-escalation Customer threatening to churn over missing audit log feature

工作流程

1. 理解问题

解析输入内容，并确定以下信息：

• 故障或需求是什么：核心的技术或产品问题
• 谁受到影响：具体客户、客户群体，或全部用户
• 持续多久：问题何时开始？客户已等待多久？
• 已尝试过什么：已进行的任何排障或临时解决方案
• 为何现在升级：是什么使其需要超出常规支持的关注

请依据下方"何时升级 vs. 在支持内处理"的标准，确认该问题是否确实需要升级。

2. 收集上下文

从可用来源汇总相关信息：

• ~~支持平台：相关工单、沟通时间线、既往排障记录
• ~~CRM（如已连接）：客户账户详情、关键联系人、既往升级记录
• ~~聊天工具：关于此问题的内部讨论，以及其他客户的类似反馈
• ~~项目跟踪器（如已连接）：相关缺陷报告或功能请求、工程进展状态
• ~~知识库：已知问题或临时解决方案、相关文档

3. 评估业务影响

依据下方的影响维度，对以下内容进行量化：

• 广度：受影响的客户/用户有多少？是否在增长？
• 深度：是完全阻塞还是仅造成不便？
• 持续时长：该问题已持续多久？
• 收入：有多少 ARR 面临风险？是否影响待成交的交易？
• 时间压力：是否存在硬性截止期限？

4. 确定升级对象

依据下方的升级层级，确定合适的对象：L2 支持、工程、产品、安全，或管理层。

5. 梳理复现步骤（针对缺陷）

如果问题是缺陷，请遵循下方的复现步骤最佳实践，记录包含环境详情和证据的清晰复现步骤。

6. 生成升级简报

## ESCALATION: [One-line summary]

**Severity:** [Critical / High / Medium]
**Target team:** [Engineering / Product / Security / Leadership]
**Reported by:** [Your name/team]
**Date:** [Today's date]

### Impact
- **Customers affected:** [Who and how many]
- **Workflow impact:** [What they can't do]
- **Revenue at risk:** [If applicable]
- **Time in queue:** [How long this has been an issue]

### Issue Description
[Clear, concise description of the problem — 3-5 sentences]

### What's Been Tried
1. [Troubleshooting step and result]
2. [Troubleshooting step and result]
3. [Troubleshooting step and result]

### Reproduction Steps
[If applicable — follow the format below]
1. [Step]
2. [Step]
3. [Step]
Expected: [X]
Actual: [Y]
Environment: [Details]

### Customer Communication
- **Last update to customer:** [Date and what was communicated]
- **Customer expectation:** [What they're expecting and by when]
- **Escalation risk:** [Will they escalate further if not resolved by X?]

### What's Needed
- [Specific ask — "investigate root cause", "prioritize fix",
  "make product decision on X", "approve exception for Y"]
- **Deadline:** [When this needs resolution or an update]

### Supporting Context
- [Related tickets or links]
- [Internal discussion threads]
- [Documentation or logs]

7. 提供后续步骤

生成升级简报后：

• "需要我把这份内容发布到目标团队的 ~~聊天频道中吗？"
• "需要我先向客户发送临时回复吗？"
• "需要我设置后续提醒，以便跟进此事吗？"
• "需要我起草一份面向客户的当前状态更新吗？"

---

何时升级 vs. 在支持内处理

以下情况在支持内处理：

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

以下情况需要升级：

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

升级层级

L1 → L2（支持升级）

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

L2 → 研发

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

L2 → 产品

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

任意层级 → 安全

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

任意层级 → 管理层

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

业务影响评估

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

影响维度

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

严重程度简述

• 严重（Critical）：生产环境宕机、数据面临风险、发生安全漏洞，或多个高价值客户受影响。需要立即处理。
• 高（High）：主要功能故障、关键客户无法使用、SLA 面临风险。需要当天处理。
• 中（Medium）：存在可用的变通方案的重大问题，业务影响重要但不紧急。需要本周内处理。

编写复现步骤

良好的复现步骤是 Bug 升级中价值最高的内容。请遵循以下做法：

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. 记录一切，升级记录对于发现规律和改进流程很有价值