工单什么时候算解决：处理完成与用户确认的边界

关联场景：企业沟通与售后协作平台。项目包含沟通与工单流转。本文提出可讨论的流程模型，不断言原项目已有这些状态、时限或角色权限。

回复过，不一定解决了

工程人员给出处理方案，客服把说明发给用户，用户实际使用后却发现问题仍然存在。如果系统把“已经回复”直接当成“已经解决”，服务状态就会提前结束。

需要分别回答：处理方做完了什么，用户确认了什么，以及组织在什么条件下认为这次服务可以关闭。

每个状态都要对应业务事实

可以先讨论以下候选含义：处理中表示还有待执行工作；待确认表示方案已交付但结果待验证；已关闭表示满足约定的结束条件；重新打开表示同一问题需要继续处理。

这不是要求所有团队采用四个固定状态。状态应该来自协作边界，数量以能解释责任、下一步动作和退出条件为准。

关闭条件需要可追溯

如果要求用户确认，应明确由谁确认、确认的内容是什么。若允许超时关闭，需要定义时限、提醒次数和重开方式，而不是把“用户没有回复”默认为满意。

处理方主动关闭、用户确认关闭和超时关闭可以有不同原因记录。这样后续复盘能知道发生了什么，不会把不同含义压缩成同一个绿色状态。

聊天和工单各保留自己的职责

聊天记录负责保存交流上下文，工单负责当前责任与推进状态。一次回复可以关联处理进展，但不能让任意聊天消息都自动推进工单。

同一段沟通也可能涉及多个问题。是否拆成多个工单，应看它们能否由不同负责人独立处理、是否拥有不同完成条件，而不是简单按消息数量拆分。

重开还是新建，需要统一口径

同一个问题再次出现、原方案无效，与新增一个独立需求，可能需要不同处理方式。可以比较问题目标、影响范围和交付条件，给出重开或新建的业务指引。

不应为了保持结案率，要求未解决的问题一律新建；也不应把所有后续需求无限追加到原工单，使完成条件不断变化。

用争议场景检验规则

处理方说完成、用户不同意；用户长期未回复；关闭后发现方案无效；一张工单包含两个不同责任人的问题。每种情况都应能判断谁来处理、下一步是什么，以及哪些记录需要保留。

一个可用的工单流程，需要让各方对状态含义形成共同理解。按钮和颜色是这份约定的表现形式。