复盘本该升级却未升级的工单

这个场景解决什么问题

客户连续求助、涉及资金或群体故障，却始终按普通咨询处理。复盘应找出当时可见的升级信号、规则是否明确、系统是否展示必要信息，而不能拿后来的严重结果倒推一线必然知道风险。WorkBuddy 帮助形成证据对照和改进建议。

开始前需要准备什么

准备当时有效的升级规则、完整会话、工单流转和操作时间、相关历史工单以及最终结果。规则包括触发条件、接收团队、时限和无人响应兜底。当前规则已变时，旧版与新版分别提供；没有旧规则只能按现行标准做差距分析，不能认定过去违规。

具体怎么做

第一步：还原当时服务链。 按时间列出客户诉求、重复来访、已尝试动作、处理状态和一线可见信息。区分信息存在于系统与当时已展示给客服。

第二步：逐项匹配规则。 让 WorkBuddy 标注首次满足升级条件的时间和消息，引用规则，比较实际是否转交、给谁、有没有接收。不把客户激烈措辞单独当危机依据。

第三步：判断漏判类型。 将疑点分为规则不清、历史关联未显示、执行未达要求或接收方未响应。证据不足的部分写待核，不凭单份聊天记录评价个人态度。

第四步：提出改进与演练题。 针对问题补提示字段、澄清触发条件、建立兜底联系人或设计训练会话，说明谁确认。修改后用原工单和相似但不需升级的对照案例测试。

可以直接交给 WorkBuddy 的完整要求

按当时有效的升级规则复盘指定脱敏工单。先建立时间线，分别记录客户原话、已做动作、一线当时可见的信息和后续新增事实。
逐规则输出触发证据、首次满足条件时间、实际流转、接收情况及差距。后来的损失不得倒推当时已经知道；旧规则缺失时只做现行规则差距分析。
把问题区分为规则缺口、系统信息缺失、执行差距、接收或兜底失效。无法确认就列待核。给出具体改进建议、责任角色、正反测试案例，不形成处分或责任裁定。

完成后会得到什么

示例：首次信号：同一资金问题第二次未解决｜规则：应交专员｜实际：普通关闭｜待核：当时界面是否展示历史来访｜建议：补历史关联提示与升级训练。

结果应该怎么检查

触发时间与消息能对上；规则版本匹配事件日期；当时事实与后来事实分开；升级不只“发出了”，还核对接收；每项改进针对真实缺口，有正常和异常对照案例。

遇到这些情况怎么处理

工单关联不全，先补历史记录；无接收日志，不假定对方没处理；规则可作多种解释，交负责人统一口径。重大安全、钱款或合同事件交有权限人员另行处置。

哪些必须人工决定

主管和业务负责人确认规则适用及改进，技术人员核实界面可见信息。AI 可整理证据与建议，不能判员工责任、客户责任或实际赔偿。