如何设计工单状态集合与状态命名

设计工单状态集合与命名，核心是先按服务请求生命周期切出最小状态集合，再统一命名规则，最后用状态流转表把每个状态变化的触发动作、责任角色和必填字段固定下来。本文面向服务台或运维团队，给出一套可直接落地的状态定义表、命名规则、流转表模板和上线检查清单。

要点总览（TL;DR）

• 先按服务请求生命周期切出五个主状态：受理、处理中、待反馈、已解决、关闭；重新打开作为已解决或关闭后的回退入口，不单独设为主状态。
• 命名全流程统一词性，采用同一套名词短语或动宾短语；同义状态、形容词式命名、把优先级或标签信息塞进状态名，都会让统计口径失真。
• 用状态流转表锁定规则：每个流转写明当前状态、触发动作、目标状态、执行角色、必填字段和完成标志，并单独列出禁止流转与例外审批路径。
• 状态数量先落地最小集合，出现有独立责任人和可统计时长的稳定环节再拆分；紧急程度、来源、涉及系统用字段或标签表达。
• 上线前逐项核对：每个状态有进入条件与责任角色、流转表无孤立状态、重新打开与关闭路径可追溯、状态变更记录可用于统计复盘。

先定状态集合：从服务请求生命周期切分

最小可用集合是五个主状态：受理、处理中、待反馈、已解决、关闭。重新打开作为已解决或关闭后的回退入口，不单独设为主状态。这套集合覆盖了从请求进入、有人接手、等待信息、给出结果到确认结束的完整路径，适合作为多数服务台团队的起点。

每个状态需要一条可判断的进入条件，否则不同人对同一张工单会给出不同状态。下表给出五个基本状态的含义、进入条件和默认责任角色。

状态名	含义	进入条件	责任角色
受理	工单已登记，尚未开始实质处理	请求已提交且信息完整，受理人完成登记与分类	服务台/受理人
处理中	处理人正在分析或执行解决方案	工单已分派给处理人，处理人确认接手	处理人
待反馈	处理暂停，等待请求人或第三方补充信息	处理人提出明确的信息需求并记录等待对象	处理人发起，请求人响应
已解决	处理人给出解决方案，等待确认	解决方案已填写，处理人提交解决说明	处理人
关闭	请求人确认或按规则自动确认，工单结束	请求人确认解决，或超过约定确认期未提出异议	审核角色/受理人

重新打开的处理方式是：已解决或关闭的工单在请求人反馈问题仍存在时，回到处理中，并保留原工单编号与历史记录。这样统计口径保持稳定，同一问题的反复处理可以在一条工单上追溯，避免为“重新打开”单独设状态导致状态数量膨胀。

状态数量与团队规模、工单量相关，但关系不是线性的。小团队、工单量低时，五个状态足够；当出现稳定的、需要独立统计和考核的环节，例如等待外部供应商、等待变更窗口，再考虑拆分。拆分的前提是该环节有独立的责任人和可统计的处理时长。以下信息不宜用新增状态表达：紧急程度用优先级字段，工单来源用来源字段，涉及的产品或系统用标签或分类字段。状态只回答“这张工单现在处在流程的哪个位置”。

状态命名规则：统一词性、粒度与用词

命名规则的目标是让任何人看到状态名就能判断流程位置，不需要额外解释。建议全流程采用统一的动宾短语或统一的名词短语，二选一后保持一致。例如统一用“受理、处理中、待反馈、已解决、关闭”这类表示阶段的名词短语，就不要再混入“提交处理”“等待回复”这类动宾表达。

常见错误有三类。第一类是同义状态并存，例如同时出现“处理中”“进行中”“处理”，三者含义重叠，统计时无法合并。第二类是形容词式命名，例如“紧急”“重要”“待优先”，这些描述的是优先级而非流程位置。第三类是状态与字段混用，例如把“已升级”“已转派”做成状态，而升级和转派本质上是动作或属性，应通过流转记录和字段表达。

错误命名	问题	建议改法
进行中 / 处理	与“处理中”同义，重复	统一保留“处理中”
紧急	形容词，表达优先级	移入优先级字段
已升级	动作结果，非流程位置	用流转记录或升级字段表达
待客户回复 / 等反馈	同义且用词不一致	统一为“待反馈”
Done / 已完成	中英文混用，且与“已解决”边界不清	统一中文，明确“已解决”与“关闭”的区别

中英文混用与缩写需要约定。如果团队使用英文界面或对接外部系统，应为每个状态确定唯一的中文名和英文名对照，并在文档中固定，例如“处理中 / In Progress”。缩写只在团队内已形成共识时使用，首次出现时给出全称。状态名与字段名、标签名要能区分：状态用流程阶段词，字段用属性词，标签用分类词，三者不交叉命名。

合法流转规则：用流转表锁定每个状态变化

状态集合是静态定义，流转表负责回答“谁能把工单从哪个状态改到哪个状态、需要满足什么条件”。每个流转至少记录六个字段：当前状态、触发动作、目标状态、执行角色、必填字段、完成标志。填写完成后，任何一次状态变更都能对应到一个具体动作和一份可核验的证据。

当前状态	触发动作	目标状态	执行角色	必填字段	完成标志
受理	分派并接手	处理中	受理人/处理人	处理人、分类、优先级	处理人确认接手
处理中	提出信息需求	待反馈	处理人	等待对象、所需信息、期望回复时间	信息需求已记录并通知请求人
待反馈	收到补充信息	处理中	处理人	回复内容记录	信息已补充，处理恢复
处理中	提交解决方案	已解决	处理人	解决说明、处理记录	解决说明已填写并提交
已解决	请求人确认	关闭	请求人/审核角色	确认结果	确认记录已留存
已解决/关闭	反馈问题仍存在	处理中	受理人/处理人	重新打开原因	原因已记录，工单回到处理中

重新打开的触发条件需要写清楚：请求人在确认期内反馈问题未解决，或关闭后同一问题再次出现且与原工单直接相关。回到的状态是处理中，原解决说明保留，新增重新打开原因，便于后续复盘区分“解决不彻底”和“新问题”。

禁止流转与例外审批同样要落到表里。例如“受理”不能直接跳到“关闭”，除非属于重复提交或无效请求，此时应走例外审批：由审核角色确认并填写关闭原因。禁止流转清单建议单独列出，配合系统校验，减少误操作。例外审批要记录审批人、审批时间和理由，作为状态变更记录的一部分。

在工具层面落地这套规则时，ONES Desk 支持灵活的自定义工作流，团队可以按自身工作方式配置工单流转；同时支持自定义工单属性，用于承载流转表中的必填字段。工单状态、处理进度和责任分工可以集中管理，状态变更与处理记录留在同一张工单上，便于后续统计和复盘。具体可配置的流转条件、校验项和版本差异，以实际环境和官方说明为准。

角色与交付物分工

状态被随意改动，通常不是规则缺失，而是责任没有落到人。建议按下列分工明确每个角色在状态维护和流转中的职责。

角色	负责的状态动作	交付物
流程负责人	定义与变更状态集合，维护流转表和命名规则	状态定义表、流转表、变更记录
服务台/受理人	受理登记、分派、待反馈跟进、超时提醒	工单登记信息、分派记录、跟进记录
处理人	推进处理中、发起待反馈、提交已解决及证据	处理记录、解决说明、信息需求单
请求人	补充信息、确认解决或反馈未解决	回复记录、确认结果
审核角色	关闭前确认、例外审批	确认记录、审批意见

流程负责人是状态集合的唯一变更入口，新增或合并状态需要评估对统计口径和历史数据的影响。受理人和处理人按流转表执行，遇到表外情况走例外审批，不自行新增状态。审核角色对关闭和例外负责，确保每次关闭都有确认依据。

示例：一条服务请求走完六个状态

以下为演示情景，用于说明状态集合、命名和流转规则如何配合，不代表真实案例。

某员工提交一条“办公软件无法登录”的服务请求。受理人登记后，工单进入“受理”，填写分类、优先级并分派给处理人，处理人确认接手，工单转为“处理中”。处理人排查后需要员工提供报错截图，于是发起“待反馈”，填写等待对象、所需信息和期望回复时间，工单转为“待反馈”。

等待期间，受理人按约定时间跟进；若超过期望回复时间仍未收到信息，受理人提醒请求人，并在记录中注明超时。员工补充截图后，处理人确认信息完整，工单回到“处理中”。处理人按截图定位到账号锁定问题，完成解锁并填写解决说明，工单转为“已解决”。

请求人确认可以正常登录，审核角色核对解决说明和确认记录后关闭工单，状态为“关闭”。三天后该员工反馈同一问题再次出现，受理人将工单重新打开，填写重新打开原因，工单回到“处理中”，原解决说明和历史记录保留。整个过程中，状态名始终使用同一套词，每次流转都有对应的必填字段和完成标志，状态变更记录可以直接用于统计处理时长和重新打开率。

完成检查：状态设计是否可上线

上线前逐项核对以下清单，全部通过再投入使用。

• 每个状态都有明确的进入条件和责任角色，不存在“看情况”的状态。
• 流转表覆盖全部允许的流转，每个状态至少有一条进入路径和一条离开路径，没有孤立状态。
• 状态命名无同义重复、无形容词、无字段混用，中英文对照已固定。
• 重新打开路径和关闭路径均可追溯，重新打开原因、关闭确认记录可查。
• 禁止流转和例外审批已列出，并有对应的审批记录要求。
• 状态变更记录包含时间、操作人、原状态、新状态和触发动作，可作为后续统计与复盘依据。
• 状态数量与当前团队规模和工单量匹配，新增状态的触发条件已写明。

这套检查同时适用于手工流程和工具配置。在 ONES Desk 中配置自定义工作流和工单属性后，建议用几条真实类型的工单走一遍完整路径，确认流转校验、必填字段和记录留存符合预期，再正式开放使用。

常见问题

团队工单量不大，五个状态是否够用，什么时候该拆分新状态？

小团队、工单量低时，受理、处理中、待反馈、已解决、关闭五个状态通常够用。判断是否拆分，看两个条件是否同时成立：该环节有独立的责任人，且处理时长可以单独统计并用于考核或复盘。例如等待外部供应商、等待变更窗口这类环节稳定出现，拆分才有意义。拆分前还要评估对历史数据和统计口径的影响，避免新旧状态混用导致报表断裂。

重新打开应该做成独立状态，还是回到处理中？

建议回到处理中，保留原工单编号、原解决说明和历史记录，同时新增重新打开原因。这样做的好处是同一问题的反复处理可以在一条工单上追溯，重新打开率可以直接统计。如果把重新打开做成独立主状态，状态数量会增加，且“重新打开后正在处理”和“处理中”的边界容易混淆。需要区分的是“解决不彻底”和“关闭后出现的新问题”，后者更适合新建工单并关联原工单。

状态流转表里，必填字段和完成标志有什么区别？

必填字段是这次流转必须填写或确认的数据，例如分派时的处理人、分类、优先级，提交解决时的解决说明。完成标志是判断这次流转是否真正完成的依据，例如“处理人确认接手”“解决说明已填写并提交”“确认记录已留存”。必填字段保证信息完整，完成标志保证动作可核验。两者一起写进流转表，状态变更才能对应到具体动作和证据，而不是只改了一个标签。

禁止流转和例外审批应该怎么设计，才不会让流程卡死？

先把明显不合理的路径列为禁止流转，例如受理直接跳到关闭，并通过系统校验拦截。再为确有需要的场景留例外审批通道，例如重复提交或无效请求需要直接关闭时，由审核角色确认并填写关闭原因。例外审批要记录审批人、审批时间和理由，作为状态变更记录的一部分。禁止流转清单和例外审批路径都要写进流转表，并定期回看审批记录，判断哪些例外频繁发生、是否需要调整规则。

用工具落地这套状态设计时，需要重点验证哪些配置？

建议用几条真实类型的工单走完整路径，重点验证三件事：流转校验是否按流转表拦截非法路径，必填字段是否在对应流转上强制填写，状态变更记录是否完整留存时间、操作人、原状态、新状态和触发动作。ONES Desk 支持灵活的自定义工作流和自定义工单属性，可作为状态与流转规则的落地载体；具体可配置的流转条件、校验项和版本差异，以实际环境和官方说明为准。