设计工单状态流转规则，核心是把服务请求的生命周期拆成几个责任交接点，再为每个交接点写清进入条件、责任角色和允许的下一步。本文给出一套可直接采用的最小状态集合、命名规范、状态转移表模板、角色分工和上线检查清单，适用于服务请求类工单；SLA时限承诺、优先级策略以及服务事件的恢复与根因处理不在本篇展开。
要点总览（TL;DR）
- 按责任交接点划分状态：待受理、处理中、待反馈、已解决、关闭，并保留重新打开作为回流路径，同一角色连续动作不拆状态。
- 状态命名用动宾或阶段描述，同一含义只保留一个词；待反馈进入时强制填写等待对象与等待内容，并与看板列名、字段取值保持一致。
- 用状态转移表配置合法路径，列结构为当前状态、目标状态、触发动作、执行角色、守卫条件、必填字段；表外流转在流程配置中阻断，例外走审批。
- 重新打开统一回到处理中并由受理人重新分派，设置重开次数上限，避免反复开关导致解决率与处理时长统计失真。
- 上线前用正常解决、待反馈往返、关闭后重开三类工单走查，确认无死胡同、每个状态有责任角色，并约定规则变更的维护方式。
状态集合怎么定：从受理到重新打开的最小闭环
状态集合按“谁在等谁”来划分：工单在谁手里、等谁动作，就对应一个状态。按这个口径，服务请求工单保留六个核心状态即可覆盖完整闭环：待受理、处理中、待反馈、已解决、关闭、重新打开。状态数量取舍的判断依据是责任交接点——发生责任转移才拆状态，同一角色连续动作不拆。
| 状态名 | 定义 | 进入条件 | 责任角色 |
|---|---|---|---|
| 待受理 | 工单已提交，尚未有人接手 | 请求人提交工单，必填字段齐全 | 受理人（服务台值班或队列负责人） |
| 处理中 | 已有人接手，正在分析或执行处理 | 受理人完成分派或自行接单，处理人已明确 | 处理人 |
| 待反馈 | 处理人已给出阶段性结论或补充问题，等待请求人回应 | 处理人提交反馈请求，写明等待对象与等待内容 | 请求人（处理人负责催办） |
| 已解决 | 处理人认为问题已解决，等待请求人确认 | 处理人填写解决说明并提交 | 处理人提交，请求人确认 |
| 关闭 | 工单终结，不再推进 | 请求人确认解决，或确认超时后按规则自动关闭 | 受理人或系统规则 |
| 重新打开 | 已解决或已关闭的工单因问题复现被重新激活 | 请求人或受理人发起重开，说明复现情况 | 受理人重新分派 |
合并与拆分的判断可以看三个信号：两个状态由同一角色连续推进、中间没有外部等待，可以合并；一个状态里混有“等对方回应”和“本方处理”两类动作，应当拆分；某状态长期没有工单停留，说明它不承载实际交接，可以去掉。待反馈是最容易被省略的状态，一旦省略，处理人等待请求人的时间就会混进处理中，后续统计处理时长时无法区分。
需要说明边界：SLA时限是对各状态停留时间的承诺，属于另一层规则，本文只保证状态划分能让计时口径清晰；服务事件的恢复与根因处理走事件管理流程，工单状态只记录服务请求本身的推进，不承载根因分析结论。
状态命名怎么写才不产生歧义
命名规则的目标是让受理人、处理人、请求人看到同一个词时理解一致。可采用四条规则：
- 用动宾结构或阶段描述表达工单所处位置，例如“待受理”“待反馈”直接说明在等谁；“处理中”说明本方正在动作。
- 同一含义只保留一个词。处理中与进行中、已解决与已完成、关闭与结束不能并存，选定一个后在全系统统一使用。
- 待反馈必须能回答“等谁、等什么”。状态名本身写“待反馈”，同时在进入该状态时强制填写等待对象（请求人还是第三方）和等待内容（补充信息、确认结果、环境截图等）。
- 状态名与工单字段取值、看板列名、报表口径保持一致。看板上的一列就是一个状态，字段里的下拉选项使用同一套词，避免出现“看板叫处理中、字段叫处理阶段”的错位。
| 反例 | 问题 | 改法 |
|---|---|---|
| 处理中 / 进行中并存 | 同义状态，统计时被拆成两段 | 统一为“处理中” |
| 待反馈 | 看不出等谁、等什么 | 保留状态名，进入时必填等待对象与等待内容 |
| 已解决 / 已完成 | “完成”含义模糊，可能指处理完成也可能指确认完成 | 统一为“已解决”，确认环节单独用“关闭” |
| 挂起 | 与待反馈重叠，且不说明原因 | 并入待反馈，或按等待对象拆成明确状态 |
合法流转规则怎么配置：状态转移表与守卫条件
把状态集合转成一张状态转移表，每一行是一条合法路径。列结构固定为：当前状态、目标状态、触发动作、执行角色、守卫条件、必填字段。配置时只允许表内路径生效，表外流转在流程配置中直接阻断。
| 当前状态 | 目标状态 | 触发动作 | 执行角色 | 守卫条件 | 必填字段 |
|---|---|---|---|---|---|
| 待受理 | 处理中 | 接单或分派 | 受理人 | 处理人已指定 | 处理人、分类、优先级 |
| 处理中 | 待反馈 | 请求补充信息 | 处理人 | 已写明等待对象与等待内容 | 反馈问题、等待对象、期望回复时间 |
| 待反馈 | 处理中 | 请求人回复 | 请求人 | 回复内容非空 | 回复内容 |
| 处理中 | 已解决 | 提交解决 | 处理人 | 已填写解决说明 | 解决说明、处理记录 |
| 已解决 | 关闭 | 请求人确认 | 请求人 | 确认结论为已解决 | 确认结论 |
| 已解决 | 重新打开 | 问题复现 | 请求人或受理人 | 未超过重开次数上限 | 复现说明 |
| 关闭 | 重新打开 | 问题复现 | 请求人或受理人 | 未超过重开次数上限 | 复现说明 |
| 重新打开 | 处理中 | 重新分派 | 受理人 | 处理人已指定 | 处理人、重开原因 |
重新打开的回流目标建议统一回到“处理中”，由受理人重新分派，而不是直接回到待受理，这样能保留原处理记录并让原处理人优先接手。重开次数需要设上限，例如同一工单重开不超过两次，超过后转由上级或问题管理流程处理，避免反复开关导致解决率与处理时长统计失真。
非法流转的阻断方式分两层：流程配置层面不提供表外路径的按钮或入口；接口与批量操作层面同样校验当前状态，防止绕过界面直接改状态。确有例外需要跳转时，走例外审批：由受理人发起，说明跳转原因，审批通过后由管理员在受控入口执行，并留下操作记录。
规则落地到工具时，需要工作流配置能承载状态集合、流转路径和字段校验。ONES Desk 支持灵活的自定义配置与工作流调整，并可自定义工单属性，团队可以按上述转移表设置状态与字段；具体到守卫条件的配置粒度与非法流转的阻断方式，建议在选型或实施时结合实际版本确认。
角色与交付物怎么分工
状态空转通常源于两件事：状态变了但没人接手，或者接手了但没有可用的交接信息。责任矩阵把每个状态的责任角色和交接交付物固定下来。
| 状态 | 推进角色 | 动作 | 交接交付物 |
|---|---|---|---|
| 待受理 | 受理人 | 判断分类、定优先级、分派 | 处理人、分类、优先级 |
| 处理中 | 处理人 | 分析、执行、记录处理过程 | 处理记录（已尝试的动作与结果） |
| 待反馈 | 请求人回复，处理人催办 | 请求人补充信息；处理人按期望回复时间催办 | 反馈问题清单、回复内容 |
| 已解决 | 处理人提交，请求人确认 | 给出解决说明；请求人验证 | 解决说明、确认结论 |
| 关闭 | 受理人或系统规则 | 确认关闭或按超时规则关闭 | 关闭原因 |
| 重新打开 | 请求人或受理人发起，受理人分派 | 说明复现情况，重新指定处理人 | 复现说明、重开原因 |
待反馈状态的催办与超时回退需要明确责任：处理人在进入待反馈时设定期望回复时间，到期未回复由处理人催办一次；超过约定时限仍无回复，工单回到处理中，由处理人基于现有信息给出结论或按规则关闭，并在记录中注明“请求人未回复”。关闭权限归受理人或按规则自动执行，重新打开权限开放给请求人和受理人，处理人不能自行重开已关闭工单，以免绕过受理环节。
示例：一条服务请求工单的完整流转
以下为演示情景，用于说明规则如何走通，不代表真实客户案例。
- 请求人提交工单：“办公软件登录后提示许可证失效”。工单进入待受理，必填字段齐全，受理人当天分派给桌面支持处理人，状态变为处理中，记录处理人、分类“软件许可”、优先级“中”。
- 处理人排查后发现需要请求人提供报错截图与账号信息，将工单转为待反馈，填写等待对象“请求人”、等待内容“报错截图与登录账号”、期望回复时间“次日中午”。
- 请求人回复并上传截图，工单回到处理中。处理人核对许可证分配记录，重新绑定许可后验证登录正常，填写解决说明并提交，状态变为已解决。
- 请求人收到确认通知，验证后确认已解决，工单进入关闭。若请求人在约定确认期内未回应，按规则自动关闭并记录关闭原因。
- 三天后同一问题复现，请求人发起重新打开并填写复现说明。受理人核对重开次数未超上限，将工单重新分派给原处理人，状态回到处理中，原处理记录完整保留。
这条走查覆盖了六个状态和全部典型路径，也验证了每次状态变化都伴随一次明确的责任交接和必填信息。
上线前怎么检查规则是否可用
规则设计完成后，用一份清单逐项核对，全部通过再上线：
- 状态定义无重叠、无遗漏：任意一条工单在任一时刻只能处于一个状态，六个状态覆盖从提交到终结的全部阶段。
- 转移表覆盖全部合法路径且无死胡同：每个非终结状态都至少有一条出边，已解决和关闭都能通过重新打开回流。
- 每个状态都有明确责任角色：不存在“无人负责”的状态，待反馈的催办责任也已指定。
- 典型工单走查通过：至少用一条正常解决、一条待反馈往返、一条关闭后重开的工单实际走一遍，确认状态与责任交接一致。
- 非法流转被阻断：尝试从待受理直接跳到已解决、从关闭直接改回处理中，确认系统拒绝或要求例外审批。
- 规则变更的维护方式已约定：状态与转移表的修改由谁提出、谁审批、如何通知相关角色，变更后是否需要用历史工单回归走查。
上线后建议每月抽查一次状态停留分布，若某状态长期为空或大量工单卡在同一状态，说明状态划分或守卫条件需要调整，按约定的变更流程修订转移表。ONES Desk 可集中管理工单状态、处理进度和责任分工，便于在运行中观察各状态的分布与交接情况，为规则迭代提供依据。
常见问题
待反馈状态经常被省略，省略后会带来什么问题？
省略待反馈后，处理人等待请求人补充信息的时间会混入处理中，后续统计处理时长时无法区分“本方处理”与“等待对方回应”两类时间。保留该状态并在进入时填写等待对象与等待内容，可以让计时口径清晰，也便于处理人按期望回复时间催办。
重新打开应该回到哪个状态，次数限制怎么设比较合理？
建议统一回到“处理中”，由受理人重新分派，这样能保留原处理记录并让原处理人优先接手。次数限制可按工单类型约定，例如同一工单重开不超过两次；超过上限后转由上级或问题管理流程处理，避免反复开关影响解决率与处理时长统计。具体上限需结合团队服务量级确定。
非法流转在工具里怎么阻断，是否允许例外跳转？
阻断分两层：流程配置层面不提供表外路径的按钮或入口；接口与批量操作层面同样校验当前状态，防止绕过界面直接改状态。确有例外需要跳转时，走例外审批：由受理人发起并说明原因，审批通过后由管理员在受控入口执行，并留下操作记录。ONES Desk 支持自定义配置与工作流调整，团队可按转移表设置状态与字段；守卫条件的配置粒度与阻断方式建议在选型或实施时结合实际版本确认。
状态命名和看板列名不一致会有什么影响？
看板列名、工单字段取值和报表口径使用同一套词，才能保证统计时同一状态不被拆成两段。若看板叫“处理中”、字段叫“处理阶段”，按字段统计和按看板统计会得到不同结果。建议在配置前先确定状态词表，再同步到看板、字段下拉选项和报表维度。
规则上线后，状态停留分布出现异常该怎么调整？
建议每月抽查一次状态停留分布。若某状态长期为空，说明它不承载实际交接，可以考虑去掉；若大量工单卡在同一状态，检查守卫条件是否过严或责任角色是否明确。调整时按约定的变更流程修订转移表，变更后用历史工单做回归走查，确认状态与责任交接仍然一致。
