工单流程示例要能让人一眼看清：一张服务请求工单从提交到关闭，每个状态由谁负责、填哪些字段、满足什么条件才能往下走。本文用一张办公软件权限申请工单做完整填写示范，覆盖提交、受理、分派、处理、待验证、关闭六个状态，并逐项解释设计理由。示例为假设情景，用于演示流程设计方法，不指向真实客户或真实系统数据，也不展开事件恢复、根因分析和SLA时限承诺。
要点总览（TL;DR）
- 示例用一张办公软件权限申请工单，演示提交、受理、分派、处理、待验证、关闭六个状态的完整填写，每个状态都写明责任人、必填字段和进入下一状态的条件。
- 状态划分以责任转移为依据，字段设置围绕分派与验证两个目的，流转条件要求当前责任人可独立判断，避免工单空转和反复退回。
- 改造时按团队处理能力和服务类型调整状态数量与字段清单，参考类字段设为选填，每个完成动作配一个可核对的产物。
- 示例基于单一服务请求类型的假设情景，多级审批、事件恢复与根因处理、SLA时限承诺需要另行设计状态和字段。
示例要演示什么：一张服务请求工单的完整流转
本示例演示的对象是一张服务请求工单，具体情景是员工申请某办公软件的访问权限。服务请求的特点是需求明确、处理路径相对标准、结果可验证，适合用来展示状态流转的基本骨架。示例覆盖六个状态：提交、受理、分派、处理、待验证、关闭。每个状态都给出责任人、必填字段和进入下一状态的条件，读者可以对照填写。
示例的范围限定在服务请求流程本身。事件恢复与根因处理属于另一类流程，涉及故障定位、临时恢复、根因分析和复盘，状态划分与字段要求都不同，本文不展开。SLA时限承诺涉及响应时限、解决时限和升级规则，需要结合团队值班能力和服务等级协议单独设计，示例中不设时限字段，也不对处理时长做承诺。读者可以把本文当作流程骨架的参照，再按自己的服务类型补充相应内容。
完整示例：一张办公软件权限申请工单的流转记录
以下为假设情景：某公司员工需要申请一款办公软件的编辑权限，通过服务门户提交工单。示例中的姓名、部门、软件名称均为演示用占位内容，不对应真实客户或真实系统数据。
状态一：提交。申请人填写工单标题“申请办公软件A的编辑权限”，工单类型选择“权限申请”，申请部门填“市场部”，申请人填“示例员工”，申请说明写“因参与季度物料制作，需要编辑权限处理图片与文档”，期望完成时间填“提交后三个工作日内”。必填字段为标题、工单类型、申请人、申请说明。提交动作由申请人完成，触发条件为表单必填项填写完整并成功提交。提交后工单进入待受理队列，责任人为服务台值班人员。
状态二：受理。服务台值班人员查看工单，确认申请说明清晰、类型选择正确，补充“受理备注：权限申请类工单，信息完整”，并将工单状态改为已受理。必填字段为受理人和受理时间。进入下一状态的条件是受理人确认工单信息可用于后续处理；若申请说明缺失关键信息，受理人退回申请人补充，工单回到提交状态并附退回原因。
状态三：分派。受理人根据工单类型将工单分派给IT支持组，填写处理组“IT支持组”和处理人“示例处理人”，并注明“需确认该软件的授权席位余量”。必填字段为处理组、处理人和分派说明。触发条件为受理完成且处理组明确。分派后责任从服务台转移到处理人，工单进入处理中。
状态四：处理。处理人核对软件授权席位，确认有余量后为申请人开通编辑权限，在处理记录中写“已核对授权席位，剩余席位充足，已完成权限开通”，并附开通时间。必填字段为处理记录和处理结果。进入下一状态的条件是处理人完成实际操作并认为结果可交付验证；若席位不足，处理人记录情况并将工单转为待补充资源，由服务台与申请人沟通替代方案。
状态五：待验证。处理人将工单状态改为待验证，验证人默认为申请人。申请人在自己的账号下尝试打开软件并编辑文档，确认权限生效后填写“验证通过：已可正常编辑文档”，并提交验证结论。必填字段为验证人和验证结论。进入关闭的条件是验证通过；验证不通过时，工单退回处理状态，处理人根据验证反馈重新处理。
状态六：关闭。服务台或处理人确认验证通过后关闭工单，填写关闭原因“验证通过，权限已开通”，并可补充处理耗时供后续统计。必填字段为关闭原因和关闭时间。关闭后工单归档，申请人如需再次申请，应新建工单而非重新打开已关闭工单，以保证每次申请都有独立记录。
| 状态 | 责任人 | 必填字段 | 进入下一状态的条件 |
|---|---|---|---|
| 提交 | 申请人 | 标题、工单类型、申请人、申请说明 | 必填项完整并成功提交 |
| 受理 | 服务台值班人员 | 受理人、受理时间 | 信息完整可处理；否则退回补充 |
| 分派 | 受理人 | 处理组、处理人、分派说明 | 处理组和处理人明确 |
| 处理 | 处理人 | 处理记录、处理结果 | 实际操作完成且结果可验证 |
| 待验证 | 申请人（验证人） | 验证人、验证结论 | 验证通过；不通过则退回处理 |
| 关闭 | 服务台或处理人 | 关闭原因、关闭时间 | 验证通过后关闭 |
逐项解释：状态、字段与流转条件为什么这样设
状态划分的依据是“责任是否发生转移”。提交到受理，责任从申请人转到服务台；受理到分派，责任从服务台转到具体处理组；处理到待验证，责任从处理人转到验证人；验证通过后关闭，责任回到服务台做归档确认。每个状态对应一个明确的责任主体，工单停在某个状态时，团队能直接找到该谁推进。颗粒度上，示例没有把“处理中”再拆成“排队中”“处理中”“等待外部资源”，因为单一服务请求类型的处理路径较短，拆得过细会增加状态维护成本，反而让处理人频繁改状态而减少实际处理时间。
必填字段的设置围绕两个目的：支撑分派和支撑验证。工单类型和申请说明支撑受理人判断该分给谁；处理组和处理人支撑责任落地；处理记录和处理结果支撑验证人判断该验证什么；验证结论支撑关闭时确认结果。字段不是越多越好，示例中“期望完成时间”设为选填，因为它影响优先级参考但不阻断流转；申请人的联系方式也设为选填，因为工单系统内已有申请人账号信息，重复填写会增加提交负担。
流转条件的作用是防止工单空转和反复退回。受理环节要求“信息完整可处理”，避免受理人把信息不全的工单直接分派，导致处理人反复询问；处理环节要求“结果可验证”，避免处理人只写“已处理”而没有可核对的结果描述；验证环节要求验证人给出明确结论，避免工单在待验证状态长期停留。退回路径也要写清楚：受理退回提交、验证不通过退回处理，每次退回都要求填写原因，让下一次处理有依据。条件设置的原则是每个条件都能被当前责任人判断，不依赖其他角色的额外确认。
可迁移规律：把示例改成自己团队的工单流程
状态数量应与团队处理能力匹配。如果团队规模小、服务类型单一，四到五个状态即可覆盖提交、处理、验证、关闭；如果服务台与处理组分离、验证环节独立，六个状态更合适。状态过多的典型信号是某些状态平均停留时间极短、几乎没有实际动作，这类状态可以合并。调整时先画出当前实际流转路径，再对照示例删减或补充状态，而不是先定状态再套业务。
必填字段应随工单类型调整。权限申请需要“申请说明”和“验证结论”，设备报修可能需要“设备编号”和“故障现象”，账号变更可能需要“变更前后账号信息”。做法是按工单类型分别列出字段清单，标注哪些字段用于分派、哪些用于验证、哪些仅作参考，参考类字段设为选填。字段调整后要同步检查流转条件，避免条件依赖的字段被删掉。
流转条件与验证环节要成对设置。每个“完成”动作都应有一个可核对的产物：处理完成对应处理记录，验证通过对应验证结论，关闭对应关闭原因。验证人可以是申请人，也可以是独立的质量角色，取决于服务的重要程度。角色分工上，服务台负责受理和分派，处理组负责处理和提交验证，验证人负责确认结果，关闭动作由服务台统一执行，便于归档和统计。流程落地时把这四类角色写进工单模板的说明里，新成员按模板填写即可减少来回沟通。
当团队使用工单系统承载这套流程时，状态可以对应到工作项的状态配置，必填字段可以对应到自定义字段，流转条件可以对应到状态流转规则。ONES Desk 支持灵活调整工作流以适应不同企业的工作方式，并支持自定义工单属性与工单内容以适配不同收集场景；工单还可以关联到待办事项或 ONES Project 的工作项，便于服务团队与研发团队交接。示例中的受理、分派、处理、验证等动作，在系统中就体现为状态变更和字段填写，团队按同一套字段口径操作，流程记录才能用于后续的进度查看和工单分析。
适用边界：示例不能直接照搬的情形
本示例基于单一服务请求类型的假设情景，适合处理路径标准、结果可验证的申请类工单。直接照搬到其他场景前，需要先判断差异。多团队、多级审批的场景，例如涉及预算审批或跨部门资源调配的工单，需要在分派前后增加审批状态，并明确每一级审批人和审批通过条件，六个状态不足以表达审批链。事件恢复与根因处理不在本示例范围，故障类工单需要增加恢复确认、根因分析和复盘环节，状态和字段都要另行设计。
时限承诺与优先级管理需要单独设计。示例没有设置响应时限、解决时限和超时升级规则，也没有定义优先级取值和优先级对分派顺序的影响。如果团队需要对外承诺服务时限，应补充时限字段、计时规则和升级路径，并明确哪些状态计入计时。优先级方面，可以增加优先级字段和对应的分派策略，但优先级取值和判定标准要结合团队实际服务量确定，不宜直接套用示例。读者在改造流程时，先确认自己的服务类型、审批层级和时限要求，再决定在示例基础上增加还是删减状态与字段。
常见问题
工单被退回补充信息后，原来的处理记录还要保留吗？
要保留。退回发生在受理或验证环节时，工单回到前一个状态，但此前填写的申请说明、受理备注、处理记录都应作为历史记录留存，退回原因单独记录在当前状态。这样处理人重新处理时能看到上一轮做了什么、为什么被退回，避免重复操作。如果团队使用的系统支持状态变更历史，退回动作本身也会留下时间与操作人记录，便于后续核对。
验证人一定要是申请人本人吗？
取决于服务的重要程度。权限开通、账号变更这类结果由申请人直接感知的工单，申请人作为验证人最直接，验证成本也低。涉及生产环境变更或对外服务的工单，建议设置独立验证角色，由不参与处理的同事按检查项确认结果，减少处理人自证的情况。无论验证人是谁，验证结论都要写成可核对的具体描述，例如“已可正常编辑文档”，而不是只勾选“通过”。
工单关闭后申请人发现权限又失效了，应该重新打开还是新建工单？
建议新建工单。已关闭工单代表一次完整服务记录，重新打开会让关闭时间和处理耗时统计失真，也不利于区分“原申请未生效”和“新的权限需求”。新建工单时在申请说明里注明关联的原工单编号，处理人可以快速查到上次的处理方式。如果团队希望减少重复填写，可以在工单模板中保留常用申请信息，由申请人确认后提交。
状态数量增加后，怎么判断某个状态是否值得保留？
看这个状态是否对应独立的责任主体和实际动作。如果某个状态平均停留时间很短、没有专属字段、也没有人真正在该状态下做事，它更像一个过渡标记，可以合并到相邻状态。反过来，如果某个状态经常出现工单积压、需要单独统计等待时长，说明它有管理价值，应保留并补充对应字段。判断依据来自实际流转记录，而不是流程设计时的设想。
用ONES Desk承载这套流程时，状态和字段怎么对应？
示例中的六个状态可以对应到ONES Desk的工作项状态配置，必填字段可以对应到自定义工单属性，流转条件可以对应到状态流转规则。ONES Desk支持灵活调整工作流以适应不同企业的工作方式，并支持自定义工单属性与工单内容以适配不同收集场景；工单还可以关联到待办事项或ONES Project的工作项，便于服务团队与研发团队交接。具体状态取值和字段类型的配置方式，以团队实际使用的版本为准。
