工单状态是服务请求在受理、处理、等待、解决、关闭等环节中所处的阶段标记，用来回答“这张工单现在走到哪一步、下一步由谁处理”。它由状态集合、允许的流转路径和进入条件共同定义，状态变化通常伴随责任角色、处理时限与可执行动作的变化。本文聚焦服务请求流程内的状态定义与边界，并在流转与交接环节说明ONES Desk可承载状态与流转记录。
要点总览（TL;DR）
- 工单状态是服务请求在受理、处理、等待、解决、关闭等环节所处的阶段标记，由状态集合、流转路径和进入条件三要素共同定义。
- 典型序列为新建/待受理、处理中、等待用户或第三方、已解决、已关闭；每个状态对应明确的责任角色和进入条件。
- 事件恢复与根因处理归服务事件与问题管理，时限承诺归工单优先级与 SLA 管理，状态本身只描述流程位置。
- 状态与优先级、流程阶段、解决结果各自独立：高优先级工单同样可能处于等待用户状态，关闭也不代表根因已消除。
- 状态数量以责任角色和可执行动作是否变化为判断标准，每次状态变化应留下操作人、时间和原因作为交接凭据。
工单状态是什么：一句话定义与核心要素
可以直接引用的定义是：工单状态是对一张服务请求当前所处处理阶段的标准化标记，它同时约束这张工单现在由谁负责、可以执行哪些动作、距离承诺完成还有多少时间。状态回答的是流程位置问题，而非对问题严重程度或处理质量的评价。
理解这个定义，需要拆出三个构成要素。三者缺一，状态就会退化成一个人为填写的标签，无法支撑流程协作。
- 状态集合：一个团队约定使用的全部状态名称，例如待受理、处理中、等待用户、已解决、已关闭。集合决定了流程被切成几段，也决定了报表能按哪些口径统计。
- 流转路径：状态之间允许的移动方向。例如待受理可以进入处理中，处理中可以进入等待用户或已解决，已解决可以关闭或被重新打开。路径明确了哪些跳转合法、哪些需要审批或说明。
- 进入条件：进入某个状态必须满足的前提。例如进入“处理中”要求已指定处理人，进入“已解决”要求填写解决说明，进入“已关闭”要求确认人确认或超过自动关闭期限。
这三个要素共同把状态与责任角色、处理时限、可执行动作绑定起来。状态为“等待用户”时，责任方暂时转移到用户一侧，处理人可执行的动作主要是催办和补充记录；状态为“处理中”时，责任方是处理人，时限计时通常处于运行状态。状态名称本身信息量有限，真正起作用的是名称背后的角色、时限与动作约定。
工单状态的范围边界：哪些内容不属于状态定义
工单状态的定义范围限定在服务请求流程内的阶段标记。它描述“流程走到哪”，不描述“问题有多严重”“承诺多久完成”“根因是什么”。把相邻概念划清归属，可以避免状态字段被塞入过多职责。
| 内容 | 是否属于状态定义 | 归属主题 |
|---|---|---|
| 服务请求在受理、处理、等待、解决、关闭中的阶段标记 | 属于 | 工单状态 |
| 事件恢复步骤、临时规避措施、根因分析与问题单管理 | 不属于 | 服务事件与问题管理 |
| 响应时限、解决时限、超时升级与承诺达成率 | 不属于 | 工单优先级与 SLA 管理 |
| 工单的紧急程度、影响范围与处理排序 | 不属于 | 工单优先级管理 |
| 关闭原因、解决方式、是否根除 | 不属于状态本身 | 解决结果与关闭原因字段 |
需要特别注意的是，不同组织中相同的状态名称可能含义不同。某团队的“已解决”指处理人自认为完成，另一团队的“已解决”指已通过用户确认。跨团队协作或对接外部服务台时，应按各自流程约定理解状态含义，必要时在工单模板或流程说明中写明进入条件，避免用名称直接推断进度。
工单状态如何流转：常见状态与进入条件
典型服务请求会经历新建或待受理、处理中、等待用户或第三方、已解决、已关闭这几个阶段。下表按同一口径列出每个状态的进入条件、责任角色与主要产出，便于对照自家流程检查缺口。
| 状态 | 进入条件 | 责任角色 | 主要产出 |
|---|---|---|---|
| 新建 / 待受理 | 工单已提交，尚未分派处理人 | 服务台受理人 | 分类、优先级、分派对象 |
| 处理中 | 已指定处理人，处理人开始实际处理 | 处理人 | 处理记录、临时方案、进展说明 |
| 等待用户 | 需要用户补充信息或确认方案，处理暂时无法推进 | 用户（处理人负责催办） | 补充信息、确认意见 |
| 等待第三方 | 依赖外部供应商、其他团队或上游系统响应 | 第三方（处理人负责跟进） | 外部回复、依赖完成证明 |
| 已解决 | 处理人给出解决方案并填写解决说明 | 处理人 | 解决方案、解决结果字段 |
| 已关闭 | 用户确认解决，或满足自动关闭规则 | 受理人或系统规则 | 确认记录、关闭原因 |
等待状态与处理中状态的区别在于责任方和计时口径。处理中状态下，推进责任在处理人，解决时限通常持续计时；等待用户或等待第三方状态下，推进责任暂时转移，很多团队会暂停解决时限计时或单独统计等待时长。若两者混用，处理人实际工作量与用户等待时间就无法分开衡量。
重开与关闭需要明确的规则设定。常见做法是：已解决状态保留一段确认期，用户在期内反馈未解决则工单回到处理中并记录重开次数；确认期结束无反馈则自动关闭；已关闭工单在约定期限内可重开，超过期限则新建关联工单。规则应写清由谁触发、是否计入原工单时限、重开次数如何统计，否则状态流转会在交接处失去约束力。
在状态流转与交接环节，ONES Desk 可集中管理工单状态、处理进度和责任分工，让问题处理过程更清晰、更容易追踪；其工作流支持灵活调整，团队可按自身受理与交接方式配置状态流转。状态字段之外，工单属性也可按不同角色的收集需求自定义，便于在流转中补齐必要信息。
容易混淆的相邻概念：状态、阶段、优先级与处理结果
状态常与几个相邻概念混用。它们各自回答不同问题，混在一起会导致字段职责不清、报表口径失真。
| 概念 | 回答的问题 | 与状态的关键区别 |
|---|---|---|
| 状态 | 这张工单现在走到哪一步，下一步由谁处理 | 流程位置标记，随处理动作变化 |
| 流程阶段 | 流程被划分为哪几个大段落 | 阶段是流程结构的粗粒度划分，一个阶段可包含多个状态；阶段相对稳定，状态随工单实时变化 |
| 优先级 | 这张工单应多快被处理 | 优先级影响排序和时限承诺，在工单生命周期内可调整，与所处状态相互独立 |
| 解决结果 / 关闭原因 | 这张工单以什么方式结束 | 记录结束的性质，如已解决、无法复现、重复提交、用户撤回；同一关闭状态下可有不同解决结果 |
| 事件等级 | 事件的影响范围和紧急程度属于哪一级 | 用于事件管理与升级决策，不描述单张工单的流程位置 |
状态与阶段的关系可以用一句话概括：阶段是流程地图上的区域，状态是地图上的当前位置。设计流程时先划分阶段，再在阶段内定义状态，可以避免状态数量失控。状态与优先级的关系则体现为两个独立维度：一张高优先级工单同样可能处于等待用户状态，一张低优先级工单也可能正在处理中，用优先级替代状态会丢失流程位置信息。
具体例子与常见误解
以下为演示情景，用于说明状态变化，不代表真实案例。某员工提交一张“办公软件无法登录”的工单：提交后处于待受理，服务台受理人完成分类并分派给桌面支持，工单进入处理中；处理人排查后需要用户提供报错截图，工单转为等待用户；用户补充截图后回到处理中；处理人重置账号并填写解决说明，工单进入已解决；用户在确认期内回复“已恢复”，工单关闭。若用户回复“仍无法登录”，工单重开回到处理中，重开次数加一。整个过程里，优先级可能始终为“中”，解决结果最终记录为“账号配置修复”，这些字段与状态各自独立。
围绕状态设计，有几类常见误解值得纠正。
- 误解一：状态越多越精细。状态数量增加会带来更多流转路径和进入条件，交接成本随之上升。判断标准是每个状态是否对应明确的责任角色和可执行动作；若两个状态的责任方与动作相同，合并通常更利于协作。
- 误解二：状态等同于进度百分比。状态是离散的阶段标记，不表示完成比例。处理中可能刚起步也可能接近完成，用百分比替代状态会让责任交接失去明确节点。
- 误解三：关闭即代表问题已根除。关闭只表示这张服务请求按流程结束，可能通过临时方案、规避措施或用户撤回而关闭。根因是否消除属于问题管理范畴，需要单独跟踪。
状态设计与团队协作、交接记录直接相关。每次状态变化都应留下操作人、时间和原因，等待状态要写明等待对象与预计回复时间，重开要记录触发原因。这样状态才不只是看板上的一个词，而是可追溯的交接凭据。对于需要跨团队跟进的事项，ONES Desk 支持将工单一键关联到 ONES Project 的需求或缺陷工作项，持续跟踪直至处理完成，使服务请求的流程状态与后端处理进展能够对照查看。
常见问题
工单状态和工单阶段是同一个概念吗？
两者粒度不同。阶段是流程结构的粗粒度划分，相对稳定；状态是工单在阶段内的实时位置，随处理动作变化。一个阶段通常包含多个状态，例如“处理阶段”下可以有处理中、等待用户、等待第三方。设计流程时先划分阶段，再在阶段内定义状态，可以控制状态数量。
等待用户状态期间，解决时限应该继续计时还是暂停？
这属于时限口径问题，归工单优先级与 SLA 管理范畴，需要团队在流程约定中写明。常见做法有两种：暂停解决时限计时并单独统计等待时长，或继续计时但把等待时间单列。选择哪种取决于承诺对象和考核方式，关键是处理中与等待状态分开统计，否则处理人工作量与用户等待时间无法区分。
工单关闭后用户又反馈问题，应该重开原工单还是新建一张？
取决于团队设定的重开规则。常见做法是已关闭工单在约定期限内可重开，超过期限则新建关联工单。规则需要写清由谁触发、重开是否计入原工单时限、重开次数如何统计。若同一问题反复出现，更适合转入问题管理跟踪根因，而非在工单层面反复重开。
状态字段能不能直接用来统计团队处理效率？
状态可以支撑按阶段统计，例如各状态停留时长、等待用户占比、重开次数，但需要配合时间戳和操作记录才有分析价值。仅看当前状态分布只能反映某一时刻的积压情况。ONES Desk 可汇总工单处理情况并提供工单分析报表，具体统计维度以实际配置为准。
跨团队协作时，双方状态名称不一致怎么办？
按各自流程约定理解，并在工单模板或流程说明中写明每个状态的进入条件。对接外部服务台时，可以建立状态映射表，把对方状态对应到本团队的责任角色和动作，避免仅凭名称推断进度。对于需要后端研发跟进的事项，ONES Desk 支持将工单一键关联到 ONES Project 的需求或缺陷工作项，持续跟踪直至处理完成。
