当客户问题超出常规支持、需升级给工程/产品/领导层时…

把支持问题整理成结构化升级简报，包含上下文、复现步骤、业务影响与升级对象，推动工程、产品或领导层介入。

适用场景

解决思路

1. 解析输入，明确：坏掉或需要什么、谁受影响、持续多久、已尝试过什么、为何现在必须升级；并用「何时升级 vs 何时在支持内处理」标准确认是否值得升级。
2. 从可用来源收集上下文：支持平台（相关工单、沟通时间线、既往排查）、CRM（账户详情、关键联系人、既往升级）、聊天（内部讨论、其他客户类似反馈）、项目跟踪器（相关 bug 或需求、工程状态）、知识库（已知问题、变通方案、相关文档）。
3. 按影响维度量化业务影响：广度（多少客户/用户受影响、是否在扩大）、深度（被阻塞还是仅不便）、时长（持续多久）、收入（风险 ARR、受影响待成交单）、时间压力（是否有硬性截止）。
4. 按升级层级确定目标：L2 支持、工程、产品、安全或领导层。
5. 若为 bug，按复现步骤最佳实践记录清晰复现步骤，含环境细节与证据。
6. 生成升级简报，包含：标题一行摘要、严重级别（Critical/High/Medium）、目标团队、报告人、日期；影响（受影响客户、工作流影响、风险收入、排队时长）；问题描述（3-5 句）；已尝试过什么（逐条列出排查步骤与结果）；复现步骤（步骤、预期、实际、环境）；客户沟通（上次更新时间与内容、客户期望、升级风险）；需要什么（具体诉求如调查根因/优先修复/做产品决策/批准例外，以及截止时间）；支持性上下文（相关工单或链接、内部讨论、文档或日志）。
7. 生成后提供后续动作：是否发到目标团队的聊天频道、是否给客户发临时回复、是否设置跟进提醒、是否起草客户可见的状态更新。
8. 判断在支持内处理的情形：有文档化解决方案或已知变通方案、是可自行解决的配置或设置问题、客户需要指导或培训而非修复、是已知限制且有文档化替代方案、既往类似工单在支持层已解决。
9. 判断应升级的情形：技术类（确认 bug 需改代码、需基础设施调查、数据损坏或丢失）；复杂度类（超出支持诊断能力、需要支持无权访问的权限、涉及定制实现）；影响类（多客户受影响、生产系统宕机、数据完整性受威胁、安全问题）；业务类（高价值客户有流失风险、SLA 即将或已违约、客户要求高管介入）；时间类（超过 SLA 未解决、客户等待过久、常规支持渠道无进展）；模式类（同一问题 3+ 客户报告、号称已修复的问题复发、严重程度随时间上升）。
10. 按层级升级：L1→L2 支持升级（需更深调查、专门产品知识或高级排查；包含工单摘要、已试步骤、客户上下文）；L2→工程（确认 bug、基础设施问题、需代码变更、需系统级调查；包含完整复现步骤、环境细节、日志或错误信息、业务影响、客户时间线）；L2→产品（功能缺口造成客户痛点、需设计决策、工作流不符客户预期、竞争性客户需求需排优先级；包含客户用例、业务影响、请求频率、竞争压力）；任意→安全（潜在数据暴露、未授权访问、漏洞报告、合规问题；包含观察到什么、谁/什么可能受影响、已采取的即时遏制措施、紧迫性评估；安全升级绕过正常层级，无论级别立即升级）；任意→领导层（高收入客户威胁流失、关键账户 SLA 违约、需跨职能决策、需政策例外、公关或法律风险；包含完整业务上下文、风险收入、已尝试过什么、所需具体决策或行动、截止时间）。
11. 按影响维度评估业务影响：广度（多少客户/用户受影响、是否增长）、深度（阻塞还是不便）、时长（持续多久、多久会变危急）、收入（风险 ARR、是否有待成交单受影响）、声誉（是否会公开、是否为标杆客户）、合同（是否违反 SLA、是否有合同义务）。
12. 使用严重级别简写：Critical（生产宕机、数据风险、安全泄露或多位高价值客户受影响，需立即关注）；High（主要功能损坏、关键客户被阻塞、SLA 有风险，需当日关注）；Medium（有变通方案的重要问题、业务影响重要但不紧急，需本周关注）。
13. 编写复现步骤时遵循：从干净状态开始（描述起点：账户类型、配置、权限）；具体（如「点击 Dashboard 页右上角 Export 按钮」而非「尝试导出」）；包含精确值（具体输入、日期、ID，而非「输入一些数据」）；注明环境（浏览器、操作系统、账户类型、功能开关、套餐级别）；记录频率（必现、间歇性还是特定条件下）；包含证据（截图、精确错误文本、网络日志、控制台输出）；注明已排除项（如「Chrome 和 Firefox 均如此」「非账户特定，测试账户可复现」）。
14. 升级后按严重级别维持跟进节奏：Critical 内部每 2 小时跟进、客户每 2-4 小时更新（或按 SLA）；High 内部每 4 小时、客户每 4-8 小时；Medium 内部每日、客户每 1-2 个工作日。
15. 执行跟进动作：向接收团队询问进展；即使无新信息也更新客户（「仍在调查，目前已知如下」）；情况变化时调整严重级别；在工单中记录所有更新以备审计；解决后闭环：与客户确认、更新内部跟踪、沉淀经验。
16. 在以下情况降级：找到根因且属支持可解决、找到变通方案解除客户阻塞、问题自行解决（但仍记录根因）、新信息改变严重级别评估。
17. 降级时：通知你升级到的团队、在工单中更新解决方案、告知客户解决情况、记录经验供未来参考。
18. 遵循升级最佳实践：始终量化影响（模糊升级会被降优先级）；bug 必须附复现步骤（工程最需要的第一件事）；明确你需要什么（「调查」「修复」「决策」是不同诉求）；设定并传达截止时间（无截止的紧迫是模糊的）；即使技术问题已升级仍保持对客户关系的负责；主动跟进，不要等接收团队来找你；记录一切（升级轨迹对模式识别和流程改进很有价值）。

适用边界 · 注意事项

• 问题已有文档化解决方案或已知变通方案、属可自行解决的配置问题、客户只需指导或培训、是已知限制且有替代方案、既往类似工单已在支持层解决时，不应升级。
• 安全类问题不要按常规层级逐级升级，应绕过层级立即升级。
• 不要升级后就不管：必须保持对客户关系的负责并主动跟进。