工单在部门之间来回转，通常卡在这三种交接

“已经转给技术了。”“技术说资料不全。”“那先关掉，客户再问再开。”如果工单经常在这样的对话中流转，增加一个状态选项通常解决不了问题。需要先弄清每次移动究竟转走了什么责任。

对话一：“这不归我们，退回去”

退单可能确实因为分派错误，也可能是团队对负责范围理解不同。把退回原因写成具体条件，例如“该事项需要仓库核对出库记录”，接单方才知道下一步该补什么。只有一句“不归我”，原客服往往只能猜另一位接收人。

可以为常见事项写简短的接收规则：处理哪个问题、最低需要哪些资料、遇到缺项由谁补充。资料不齐时，还要区分能够先检查的部分与必须等待的部分。不要把任何缺项都当成拒收理由，让客户反复成为部门协作的传话人。

对话二：“先挂着，等对方回复”

等待本身可能合理，含糊的等待才容易积压。记录正在等谁、等什么、预计何时再检查，以及客户是否需要获知当前情况。没有预计时间时，也应指定下一次内部复查节点，而非让工单永远停在处理中。

等待说明示例：“等待供应方确认配件适配，已于周二发出型号资料；售后负责人周四上午再次核对进展，并向客户说明当前情况。暂未承诺发货日期。”

这段示例既不虚构处理完成，也不把责任留给一个模糊的部门名称。等待结束后，要由指定人员将结果带回原事项，避免供应方已经回复，客服仍然不知道。

对话三：“系统显示完成了，客户怎么还在问”

内部动作完成与客户问题解决，有时相隔一步。工程师提交处理结论后，可能还需要客户验证；仓库安排补发后，可能还需要确认地址与实际发出。关单条件应对应事项结果，不仅对应某个人已经操作过。

如果关闭后出现相关新信息，应有明确的继续处理方式。关联原工单还是新建事项，要依据当前系统能力与业务规则决定，但应保留来龙去脉。不能为了让完成率好看，把同一个未解决问题拆成多张“已完成”。

在千悦开展工单协作时，先用少量实际业务检验接收、等待与验收的含义，再配置可用状态与权限。任何自动分派规则都应有负责人处理例外；系统能把任务送到某个岗位，并不自动证明对方已经接收。

检查工单流转，可以从“被退回两次”“长时间没有新进展”“客户在关单后再次询问”三类样本开始。逐条找出责任或信息的缺口，修改对应规则，再观察相同问题是否减少。这样得到的流程，才与团队真正的协作方式相符。