如果您看到不熟悉的占位符或需要检查已连接的工具，请参阅 CONNECTORS.md。
将支持问题打包成结构化的升级简报，提交给工程、产品或者管理层。收集上下文，结构化复现步骤，评估业务影响，并确定正确的升级目标。
/customer-escalation <问题描述> [客户名称或账户]示例：
/customer-escalation API 为 Acme Corp 间歇性返回 500 错误/customer-escalation 数据导出缺少行——本周已有 3 位客户报告/customer-escalation SSO 登录循环影响所有企业版客户/customer-escalation 客户因缺少审计日志功能威胁要流失解析输入并确定：
使用下面的"何时升级与在支持中处理"标准来确认是否值得升级。
从可用来源汇集相关信息：
使用下面的影响维度，量化评估：
使用下面的升级层级，确定正确的目标：二级支持、工程、产品、安全或管理层。
如果问题是错误，请遵循下面的复现步骤最佳实践，记录清晰的复现步骤，包括环境详情和证据。
## 升级案例：[一句话摘要]
**严重程度：** [严重 / 高 / 中]
**目标团队：** [工程 / 产品 / 安全 / 管理层]
**报告人：** [您的姓名/团队]
**日期：** [今天日期]
### 影响
- **受影响的客户：** [谁以及多少]
- **工作流影响：** [他们无法做什么]
- **收入风险：** [如适用]
- **队列时间：** [这个问题已存在多久]
### 问题描述
[清晰、简洁的问题描述——3-5句话]
### 已尝试的措施
1. [故障排除步骤和结果]
2. [故障排除步骤和结果]
3. [故障排除步骤和结果]
### 复现步骤
[如适用——遵循以下格式]
1. [步骤]
2. [步骤]
3. [步骤]
预期结果：[X]
实际结果：[Y]
环境：[详情]
### 客户沟通
- **上次更新给客户：** [日期和沟通内容]
- **客户期望：** [他们期望什么以及何时]
- **升级风险：** [如果在 X 时间前未解决，他们是否会进一步升级？]
### 需要什么
- [具体请求——"调查根本原因"、"优先修复"、
"对 X 做出产品决策"、"批准对 Y 的例外"]
- **截止日期：** [何时需要解决或更新]
### 支持性上下文
- [相关工单或链接]
- [内部讨论线程]
- [文档或日志]生成升级信息后：
从： 一线支持 到： 高级支持 / 技术支持专家 时机： 问题需要更深入的调查、专业产品知识或高级故障排除 包含内容： 工单摘要、已尝试的步骤、客户上下文
从： 高级支持 到： 工程团队（相关产品领域） 时机： 已确认的错误、基础设施问题、需要代码变更、需要系统级调查 包含内容： 完整的复现步骤、环境详情、日志或错误消息、业务影响、客户时间线
从： 高级支持 到： 产品管理 时机： 功能缺口导致客户困扰、需要设计决策、工作流不符合客户期望、相互冲突的客户需求需要优先级排序 包含内容： 客户用例、业务影响、请求频率、竞争压力（如已知）
从： 任何支持层级 到： 安全团队 时机： 潜在的数据泄露、未授权访问、漏洞报告、合规问题 包含内容： 观察到的内容、谁/什么可能受影响、已采取的即时遏制步骤、紧急程度评估 注意： 安全问题绕过正常的层级递进——无论您处于哪个层级都立即升级
从： 任何层级（通常是 L2 或经理） 到： 支持领导层、高管团队 时机： 高收入客户威胁流失、关键账户违反 SLA、需要跨职能决策、需要政策例外、公关或法律风险 包含内容： 完整的业务背景、收入风险、已尝试的措施、需要的具体决策或行动、截止日期
升级时，尽可能量化影响：
| 维度 | 需要回答的问题 |
|---|---|
| 广度 | 多少客户/用户受影响？是否在增长？ |
| 深度 | 他们的受影响程度有多严重？业务受阻还是仅感不便？ |
| 持续时间 | 这个问题已经持续多久了？多久后会变得严重？ |
| 收入 | 有多少 ARR 面临风险？是否有待定的交易受影响？ |
| 声誉 | 这个问题会公开化吗？是否是标杆客户？ |
| 合同层面 | SLA 是否被违反？是否有合同义务？ |
良好的复现步骤是错误升级中最有价值的事情。遵循以下实践：
不要升级后就忘记了。保持对客户关系的主导权。
| 严重程度 | 内部跟进 | 客户更新 |
|---|---|---|
| 严重 | 每 2 小时 | 每 2-4 小时（或按 SLA） |
| 高 | 每 4 小时 | 每 4-8 小时 |
| 中 | 每天 | 每 1-2 个工作日 |
并非每次升级都会保持升级状态。在以下情况下降级：
降级时：