安全边界不能打破。信息交换可以重做。

平台已经上线，客服工单却在真实使用中暴露出问题。

这个平台由集团内部自主设计开发，负责监管内、外场监控设备的运行状态。设备出现故障或异常后，平台需要支持及时发现、快速分发维修任务并跟踪修复结果，为监控设备稳定运行提供全流程保障。

一期部署上线后，问题开始出现在真实使用中。客服工单处理环节操作效率低、流程繁琐，成为最需要优先优化的部分。因此，本次迭代把客服工单模块作为重点。

只听一句“操作麻烦”，很容易把问题缩小成几个界面细节。

我跟随用研人员前往分公司，观察客服怎样查看告警、处理告警并跟踪处置结果，同时与 4 名一线客服、1 名运维经理进行一对一访谈。现场观察记录真实动作，访谈则用于理解动作背后的判断与限制。

现场最关键的发现是：监控告警位于专用内网，工单派发与跟踪位于互联网外网。安全要求决定了两个网络不能直接互通，客服只能依赖复制粘贴和人工记忆，把信息从一个系统带到另一个系统。

不把系统互通当作前提，而是在现有安全边界内选择能够落地的交换方式。

告警采集继续留在专用内网，工单派发与跟踪继续留在互联网外网。方案需要同时满足安全合规、批量处理和状态可追踪三个条件。

把每条告警重复执行的 3 个动作，改成每批告警完成 1 次结构化交换。

告警采集继续留在专用内网，客服在内网批量导出结构化文件，再到互联网外网批量导入；系统自动解析并高亮新告警，格式错误、信息重复和导入失败则进入统一异常反馈。

把“我记得处理过”变成系统里看得见的状态。

旧流程中，客服需要凭记忆判断告警是否已经派单，容易重复处理。新方案将未处理、已派单、已恢复、已关闭四种状态平铺展示，标记后自动归类，让状态跟随任务流转。

对停电、施工等同一原因触发的批量告警，我加入组合与解组能力。客服可以先把同类告警视为一个处理单元，设备恢复后再按实际情况解组，减少机械重复。

到期不等于具备维修条件，自动派单反而会制造无效任务。

现场调研发现，挂起工单到期时，设备故障点可能仍未排查清楚，维修人员可能尚未到位，现场也可能不具备维修条件。旧机制直接重新派单，会造成反复派单。

我将到期后的单一路径改为条件判断：满足维修条件时重新派单；仍不满足时填写延期日期和原因；挂起期间设备恢复则直接完结。到期前通过弹窗与消息中心双重提醒，避免任务被遗漏。

这次设计重新组织了客服工单的处理方式。

方案最终沉淀为客服工单全流程原型、交互说明、用户画像与痛点诊断，完成产品、安全和技术团队的方案对接与开发走查，并于 2025.04 上线。跨网交换、告警状态与挂起工单的处理路径被重新组织，形成了状态可见、路径可追踪的系统规则。