设计工单流程图，核心是把一条服务请求从提交到关闭的完整路径画成主线：提交受理、分类定级、分派处理、处理反馈、验证确认、关闭归档。每个节点写清输入、动作、输出、负责人和完成标志，再补上退回、转派、挂起、重开等分支。流程图的作用是让每个角色知道自己在什么状态下做什么、交付什么。下面按定边界、画主干、补分支、分角色、走示例、做检查的顺序展开。
要点总览（TL;DR）
- 先划定流程边界：起点定在请求进入受理渠道，终点区分“关闭”与“完成未关闭”，事件恢复、根因处理和时限承诺不放进主图。
- 主干由提交受理、分类定级、分派处理、处理反馈、验证确认、关闭归档六个节点组成，每个节点写清输入、动作、输出、负责人和完成标志。
- 退回、转派、挂起、重开四类分支用判断节点标注触发条件，并为每个状态写明进入条件与离开条件。
- 流程图定稿前用三到五条真实工单试运行，记录等待、频繁触发的分支和缺失字段，再对照检查清单修订。
先定流程边界：哪些请求进这张图
动笔之前先回答一个问题：这张图从哪开始、到哪结束、装哪些请求。边界不清，流程图会越画越大，最后把事件处理、根因分析、时限承诺都塞进来，节点之间互相牵扯，没人愿意照着执行。
起点通常定在“请求进入受理渠道”这一刻。渠道可以是服务门户的表单、专用邮箱、服务电话或聊天工具，不同渠道进入后应汇入同一个受理节点，否则后续统计和跟踪会分裂成几套口径。终点要区分两种情形：关闭指请求已处理完毕、请求人确认、记录归档；完成但未关闭指处理动作已结束、仍在等待请求人确认或等待归档动作，这类工单应保留在待确认或待关闭状态，不能直接算作关闭。
纳入范围建议以常规服务请求为主，包括咨询答复、权限与账号申请、软件安装、设备报修、数据提取等可标准化受理的事项。判断标准是：请求有明确的提出人、有可描述的服务内容、有可确认的完成结果。排除项同样要写清楚：故障发生后的恢复动作与根因排查归服务事件与问题管理，不在本图展开；响应时限、解决时限的承诺与考核归工单优先级与 SLA 管理，本图只保留“定级”这个动作，不写具体时限数值。
边界确认的产出是一页范围说明，包含四项内容：起点定义（哪些渠道、以什么事件为进入标志）、终点定义（关闭与完成未关闭的判定）、纳入清单（服务类型列表）、排除清单（相邻流程及归属）。这一页说明是后续画图、评审和系统配置的共同依据，建议在流程图定稿前先让受理人和处理人各看一遍。
核心答案：一张工单流程图的主干步骤
主干流程由六个节点组成，顺序固定，每个节点用五要素描述：输入、动作、输出、负责人、完成标志。把这张表填满，流程图的主干就成立了，剩下的工作是把表转成方框和箭头。
| 节点 | 输入 | 动作 | 输出 | 负责人 | 完成标志 |
|---|---|---|---|---|---|
| 提交受理 | 请求人填写的表单或来信 | 请求人填写服务类型、问题描述、影响范围、联系方式；受理人核对字段完整性并回复已收到 | 一张字段齐全的待受理工单 | 请求人、受理人 | 工单进入待分类状态，请求人收到受理回执 |
| 分类定级 | 待受理工单 | 按服务类型归类，按影响范围与紧急程度定级，把定级依据写在节点说明里 | 带分类与优先级标签的工单 | 受理人 | 分类与级别字段填写完整，可进入分派 |
| 分派处理 | 已分类定级的工单 | 按技能组或责任人分派，通知接手人，接手人确认接收 | 已指派责任人的工单 | 受理人、处理人 | 处理人确认接手，工单进入处理中状态 |
| 处理反馈 | 处理中工单 | 处理人执行处理动作，记录处理过程与结果，向请求人反馈结论 | 含处理说明与反馈记录的工单 | 处理人 | 处理说明填写完整，请求人收到反馈 |
| 验证确认 | 已反馈工单 | 请求人验证结果是否满足需求，确认解决或提出未解决 | 确认结果记录 | 请求人 | 请求人给出确认结论 |
| 关闭归档 | 已确认工单 | 核对关闭条件，补齐归档字段，将可复用经验沉淀为知识条目 | 已关闭工单与归档记录 | 受理人或流程负责人 | 工单状态变为已关闭，归档字段完整 |
画主干草图时，六个节点纵向排列，节点之间用单向箭头连接，每个方框内写节点名称和负责人，方框下方用小字标注完成标志。分类定级节点上要显式写出定级依据，例如“影响多人且无替代方案定为高”，避免定级变成受理人的个人感觉。处理反馈节点要区分“处理动作”和“反馈动作”，两者都完成才算节点结束，只处理不反馈会让请求人反复追问。
主干画完后先不要加分支，用一条真实工单在纸上走一遍，检查每个节点的输出是否正好是下一个节点的输入。如果出现某个节点拿不到上游输出、或者输出无人接收，说明节点划分或字段设计需要调整。
分支怎么画：退回、转派、挂起与重开
真实工单很少一路直行，退回、转派、挂起、重开是四类必须画出的分支。画法统一为：在产生分支的节点旁加一个菱形判断节点，菱形上写触发条件，从菱形引出带条件标签的箭头指向目标节点，箭头方向尽量单向，避免来回交叉。
- 退回：触发条件是信息不全、描述无法定位问题或分类明显错误。退回目标为提交受理节点，责任在受理人，退回时须写明缺什么字段、需要请求人补充什么。退回后工单状态回到待补充，请求人补充完成再重新进入分类。
- 转派：触发条件是接手人判断该请求不属于本技能组职责。转派须填写交接字段：已排查的内容、判断依据、建议接手方，并通知原受理人和新处理人。转派后工单保持处理中状态，责任人字段更新为新处理人，原处理人不再承担该单。
- 挂起：触发条件是等待请求人补充信息或等待外部依赖返回。挂起是一个独立状态，须记录挂起原因、挂起时间和恢复条件，并约定到期未恢复时的提醒动作。挂起期间工单不占用处理人正常处理队列，恢复后回到挂起前的节点继续。
- 重开：触发条件是关闭后问题复现或请求人认为未真正解决。重开须设定条件，例如关闭后一定期限内可重开、需说明复现情况，重开目标节点为处理反馈，工单状态从已关闭回到处理中，并保留原处理记录作为上下文。
分支画完后检查两件事：每个分支是否有明确的状态名称，状态名称是否与主干节点使用的名称体系一致；是否存在没有出口的节点，例如挂起后没有任何恢复路径，或退回后没有重新进入的箭头。状态名称建议单独列一张小表，写明状态、含义、可进入的下一个状态，这张表后续可以直接对照工单系统的状态配置。
角色与交付物：谁在哪个节点负责什么
流程图只有方框没有责任人，执行时就会出现“都以为对方在做”。把节点对应到角色，并明确每个角色在每个节点交付什么，流程图才具备可执行性。
| 角色 | 参与节点 | 职责 | 交付物 |
|---|---|---|---|
| 请求人 | 提交受理、验证确认、退回补充 | 如实填写请求信息，配合补充材料，验证处理结果 | 完整的请求描述、补充信息、确认结论 |
| 受理人/服务台 | 提交受理、分类定级、分派处理、关闭归档 | 核对字段、初判分类、按规则分派、跟踪进度、执行关闭 | 受理回执、分类定级记录、分派通知、关闭记录 |
| 处理人/技能组 | 分派处理、处理反馈、转派、挂起 | 确认接手、执行处理、记录过程、反馈结论、判断是否需要转派或挂起 | 处理说明、反馈内容、转派交接说明、挂起原因 |
| 流程负责人 | 全流程 | 维护流程定义与状态规则，处理升级与例外，组织试运行与复盘 | 流程范围说明、流程图与状态表、例外处理记录、复盘结论 |
交接动作要单独标出：分派时向处理人发通知并附工单链接，转派时向新处理人交代已排查内容，关闭时向请求人发送关闭通知并说明重开方式。这些动作在图上可以用带箭头的虚线表示通知流向，与实线表示的状态流转区分开。
流程落地到系统时，节点、状态、角色和字段需要一一对应。ONES Desk 面向企业服务与协作场景，支持通过统一门户集中接收工单，并提供自定义处理流程与字段配置，可以把上面这张角色表和状态表映射为工单类型、状态流转与责任人字段。它的自定义工作流允许企业按自身工作方式制定问题响应流程，工单可关联到 ONES Project 的需求或缺陷工作项持续跟踪，也可关联 ONES Wiki 页面沉淀服务经验，适合把“关闭归档”节点的知识沉淀动作固定下来。分支状态的具体配置方式，建议在选型或实施时按实际系统核验。
示例：一条权限申请工单走完整张图
以下为演示情景，用于说明流程运转方式，不代表真实客户案例。
员工申请某业务系统的查询权限。请求人通过服务门户提交工单，填写申请系统名称、所需权限范围、使用期限和直属主管，工单进入待受理。受理人核对字段，发现未填写使用期限，触发退回分支，工单状态变为待补充，请求人补填后重新进入待受理。受理人将工单分类为“权限申请”，按影响范围定为普通级，分派给应用支持组。处理人确认接手，核对权限清单后完成授权，在处理说明中记录授权范围和生效时间，并向请求人反馈。请求人登录验证后确认可用，工单进入已确认。受理人核对关闭条件，补齐归档字段，将本次授权记录关联到对应的权限管理知识页面，工单关闭。
这条工单在图上经过的节点依次为：提交受理、退回、提交受理、分类定级、分派处理、处理反馈、验证确认、关闭归档。状态变化为：待受理、待补充、待受理、待分派、处理中、待确认、已关闭。记录字段包括申请系统、权限范围、使用期限、分类、级别、责任人、处理说明、确认结论和归档关联。把这条路径标注在流程图上，可以直观看出退回分支的位置和重新进入的节点。
完成检查：流程图可用的判断标准
流程图定稿前，用下面这份清单逐项核对。每一项都能给出明确答案，流程图才具备执行条件。
- 每个节点都写明了负责人、输入、输出和完成标志，没有只写节点名称的空方框。
- 主干节点与分支节点的状态名称统一，状态表中每个状态都有明确的进入条件和离开条件。
- 图中没有孤立节点，每个节点至少有一条进入箭头和一条离开箭头。
- 关闭条件与重开条件分别写明，重开的期限、说明要求和目标节点清晰。
- 角色职责表与流程节点一一对应，每个节点都能找到唯一的第一责任人。
- 流程图中的字段名称与实际工单系统的表单字段、状态字段能对上，不存在图上写了系统里没有的字段。
- 用三到五条真实工单试运行一遍，记录卡点：哪些节点出现等待、哪些分支被频繁触发、哪些字段经常缺失。
- 根据试运行结果修订流程图和状态表，修订记录保留版本，便于后续复盘。
试运行是判断流程图是否可用的关键一步。纸面完整的流程图，在真实工单上往往会暴露出分派规则不清、退回条件过宽、挂起无人跟进等问题。把这些问题记录下来并回到对应节点修订，流程图才算真正可用。
常见问题
流程图里的“完成但未关闭”状态有必要单独设吗？
有必要，尤其当处理动作结束与请求人确认之间存在时间差时。处理人已反馈结果、请求人尚未验证的工单，如果直接算作关闭，后续确认结论和重开记录就无处安放。建议把这类工单保留在待确认或待关闭状态，明确由谁跟进、跟进多久，再进入关闭归档。这样关闭动作有确认依据，统计口径也能区分“已处理”和“已关闭”。
退回和转派都会让工单离开当前处理人，画图时怎么区分？
两者方向不同。退回是向上游走，工单回到提交受理或待补充状态，责任回到受理人和请求人，触发原因通常是信息不全或分类错误；转派是横向走，工单仍在处理中，责任人换成另一个处理人或技能组，触发原因是职责归属不符。画图时退回箭头指向提交受理节点，转派箭头指向分派处理节点，并在箭头上分别标注“信息不全”“非本组职责”等条件，避免两条线混在一起。
挂起状态需要设自动恢复或提醒吗？
建议设置。挂起意味着工单暂时离开正常处理队列，如果没有恢复条件或到期提醒，容易长期滞留。画图时在挂起节点旁写明挂起原因、挂起时间和恢复条件，并约定到期未恢复时由谁提醒、提醒谁。恢复后工单回到挂起前的节点继续处理，原处理记录保留。具体提醒方式可以借助工单系统的通知能力实现，配置方式按实际系统核验。
流程图和工单系统里的状态配置对不上，先改哪边？
先改流程图。流程图是流程定义的表达，系统状态是它的实现。核对时逐项比对节点名称、状态名称、字段名称和责任人字段，找出图上写了但系统里没有的字段，或者系统里有但图上没体现的状态。确认差异属于流程设计遗漏还是系统配置限制，再决定调整图还是调整配置。两边对齐后再试运行，能减少上线后的返工。
小团队也需要画这么完整的流程图吗？
可以按需简化，但主干六节点和角色分工建议保留。团队规模小、工单量少时，分类定级可以合并到受理环节，验证确认可以由受理人代为确认，分支只保留退回和重开两类。简化的是节点数量和分支种类，每个保留节点的负责人、完成标志仍需写明，否则流程执行时依然会出现责任不清。随着工单量和技能组增多，再逐步补回分支和状态。
