工单流程由入口、状态、角色和交接规则组成：服务请求进入统一入口后登记为工单，按受理、分派、处理、验证、关闭推进，每个状态都要明确谁负责、需要什么输入、留下什么记录、满足什么条件才能流转。本文聚焦服务请求类工单，给出从零搭建的步骤、状态机与字段清单、角色职责表、一条工单的完整流转示例，以及上线前的检查方式；事件恢复与根因处理、SLA时限承诺不在本文展开。
要点总览（TL;DR）
- 工单流程由入口、状态、角色和交接规则构成，搭建顺序建议为：先固定字段与状态机，再定义角色分工与升级规则，最后用少量真实工单试跑。
- 状态从四到六个起步，每个状态写明进入条件、退出条件和唯一责任角色；关键字段标注填写时点与必填要求，并绑定到状态流转条件中。
- 角色定义要落到输入、动作和交付物，服务台、受理人、处理人、请求人、流程负责人各自有可交接的产出，交接与升级需写明触发条件。
- 判断流程是否跑通，看真实工单能否在无人反复催促下闭环，并观察状态停留时间、退回次数和记录完整度三项指标。
- 流程上线后由流程负责人定期查看流转数据，把高频退回原因转化为字段提示或表单校验，状态机调整保留版本记录并小范围验证后再推行。
工单流程的核心答案与搭建步骤
搭建工单流程可以按四步推进：先固定工单字段与状态机，再定义角色分工与交接规则，然后设定升级条件，最后用少量真实工单试跑并检查流转记录是否完整。这个顺序的价值在于，状态和字段是流程的骨架，角色和升级规则挂在骨架上，试跑则用来暴露骨架上的缺口。反过来先讨论“谁负责什么”，往往会因为状态定义不清而反复返工。
每一步都需要明确的输入、动作和输出，否则流程容易停留在文档层面。下表给出可直接对照执行的搭建步骤表。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 固定字段与状态机 | 现有服务请求类型、常见问题分类、当前处理习惯 | 列出工单类型与关键字段，画出状态及进入退出条件 | 状态机表、字段清单 | 每个状态都有进入条件、退出条件和责任人，字段标注必填时点 |
| 2. 定义角色分工 | 状态机表、现有岗位设置 | 为每个状态指定负责角色，写明输入、动作与交付物 | 角色职责与交付物对照表 | 任一状态都能找到唯一责任角色，交接物可被下一环节直接使用 |
| 3. 设定升级规则 | 角色表、历史积压或退回情况 | 确定超时、信息不全、跨部门等情况的升级触发条件与接收人 | 升级规则清单 | 每条升级规则都有触发条件、接收角色和处理动作 |
| 4. 小范围试跑 | 状态机、字段清单、角色表、升级规则 | 选取少量真实工单按新流程走一遍，记录卡点 | 试跑记录与问题清单 | 试跑工单全部走完闭环，流转记录可追溯，问题清单有明确修订项 |
试跑阶段建议控制范围，选一两类高频请求、两三个处理角色即可。范围过大时，问题会同时出现在字段、状态和角色三个层面，难以判断该改哪里。每轮试跑后只修订最突出的两三个问题，再进入下一轮，流程会逐步稳定。
工单状态机与必填字段怎么定
状态划分的原则是：每个状态对应一个明确的责任主体和一段可观察的工作，状态之间不重叠、不空转。常见的四段状态是待受理、处理中、待验证、已关闭，复杂场景可在此基础上增加待分派、待补充信息、已挂起等状态。状态越多，流转记录越细，维护成本也越高，建议从四到六个状态起步。
每个状态都要写明进入条件、退出条件和责任人，形成状态机表。下表是一份可直接套用的状态机框架。
| 状态 | 进入条件 | 退出条件 | 责任角色 |
|---|---|---|---|
| 待受理 | 请求人通过统一入口提交工单 | 服务台完成登记确认并分派，或判定为无效请求退回 | 服务台 |
| 待分派 | 工单已登记但尚未确定处理人 | 指定处理人并附上必要背景信息 | 服务台或受理人 |
| 处理中 | 处理人已接单 | 处理人提交处理结果与处理记录 | 处理人 |
| 待验证 | 处理结果已提交 | 请求人或验证人确认解决，或退回处理中 | 请求人或指定验证人 |
| 已关闭 | 验证通过 | 无（如需重开则回到待受理或处理中） | 服务台 |
字段设计要与状态对应，避免出现“状态已推进但关键信息为空”的空转。工单类型决定走哪条流程，请求人和受理人决定责任归属，优先级影响处理顺序，处理记录是验证和复盘依据。下表给出字段清单示例，实际使用时按业务增减。
| 字段名 | 填写时点 | 是否必填 | 负责人 |
|---|---|---|---|
| 工单类型 | 提交时 | 必填 | 请求人 |
| 请求人及联系方式 | 提交时 | 必填 | 请求人 |
| 问题描述与期望结果 | 提交时 | 必填 | 请求人 |
| 优先级 | 受理时 | 必填 | 服务台 |
| 受理人 | 受理时 | 必填 | 服务台 |
| 处理人 | 分派时 | 必填 | 受理人 |
| 处理记录 | 处理中每次动作后 | 必填 | 处理人 |
| 验证结论 | 待验证转已关闭前 | 必填 | 请求人或验证人 |
状态与字段的对应关系要在流程配置中体现：进入处理中时，处理人字段不能为空；提交验证结论前，处理记录不能为空。把这类约束写进状态流转条件，可以减少人工检查，也让流转记录本身成为可追溯的证据。对于信息不全的工单，可设置待补充信息状态，由请求人补齐后再回到待受理，避免工单在待受理状态长期滞留。
角色分工与交付物
交接责任不清通常源于角色只写了名称、没写交付物。判断一个角色是否定义清楚，可以看它是否有明确的输入、动作和可交接的产出。服务请求流程中常见的五类角色如下表。
| 角色 | 输入 | 动作 | 交付物 |
|---|---|---|---|
| 请求人 | 业务问题或服务需求 | 通过统一入口提交工单，补充必要信息，验证处理结果 | 完整工单描述、验证结论 |
| 服务台 | 新提交的工单 | 登记确认、判定类型与优先级、分派或退回、关闭工单 | 已分派工单、关闭记录 |
| 受理人 | 已分派工单 | 确认处理范围、指定处理人、跟踪进度、协调升级 | 处理人指派记录、进度跟踪记录 |
| 处理人 | 指派工单与背景信息 | 分析处理、记录处理过程、提交处理结果 | 处理记录、处理结果说明 |
| 流程负责人 | 流转数据与试跑问题 | 维护状态机与字段、修订升级规则、组织复盘 | 流程版本、修订记录、复盘结论 |
交接与升级需要明确的触发条件，否则规则形同虚设。常见触发条件包括：工单在某一状态停留超过约定时长；处理人判断问题超出自身职责范围；请求人补充信息后仍无法推进；同一问题重复提交。每条触发条件都应指定接收角色和处理动作，例如超时未受理的工单升级给受理人，跨部门问题升级给流程负责人协调。
当工单需要跨部门协同或与研发工作项衔接时，流程承载工具的选择会影响交接效率。ONES Desk 是面向企业服务与协作场景的工单管理产品，帮助团队统一受理、分派、处理和跟踪客户反馈、内部需求及服务事项；其企业版介绍提到通过统一门户集中接收工单，支持自定义处理流程与字段配置。这类能力对应本文前面讨论的统一入口、状态机和字段清单，可作为流程落地时的一种工具选择。工单还可关联到 ONES Project 的需求或缺陷工作项，或关联到 ONES Wiki 页面，用于跨部门跟踪与经验沉淀，这一衔接需同时使用对应产品。
示例：一条服务请求工单的完整流转
以下为演示情景，用于说明各环节的记录内容与状态变化，不代表真实客户案例。假设某部门员工发现内部报表系统导出功能报错，通过统一入口提交工单。
| 环节 | 动作与记录内容 | 状态变化 |
|---|---|---|
| 提交 | 请求人填写工单类型“系统故障”、问题描述“报表导出报错，附截图”、期望结果“恢复正常导出”，提交后生成工单编号 | 无 → 待受理 |
| 受理 | 服务台确认信息完整，判定优先级为高，登记受理人 | 待受理 → 待分派 |
| 分派 | 受理人指定报表系统处理人，附上截图与影响范围说明 | 待分派 → 处理中 |
| 处理 | 处理人复现问题，记录排查过程与修复动作，提交处理结果“已修复导出配置，请验证” | 处理中 → 待验证 |
| 验证 | 请求人按原场景重新导出，确认正常，填写验证结论 | 待验证 → 已关闭 |
| 关闭 | 服务台确认验证结论完整，关闭工单并归档处理记录 | 已关闭 |
异常情况同样要在示例中体现。若请求人提交时未附截图、问题描述模糊，服务台可退回并转入待补充信息状态，注明需要补充的内容，请求人补齐后回到待受理。若处理人提交的结果经请求人验证仍未解决，工单从待验证退回处理中，退回原因写入处理记录，退回次数计入后续观察指标。若问题需要研发介入，处理人可将工单关联到对应的需求或缺陷工作项，继续跟踪直至处理完成，工单本身保持处理中状态，避免同一问题在两处重复登记。
流程落地与完成检查
判断流程是否跑通，不能只看文档是否写完，而要看真实工单能否在无人反复催促的情况下走完闭环。上线前先做一轮检查，确认状态、字段、角色和升级规则四类要素齐备。
- 状态定义：每个状态都有进入条件、退出条件和唯一责任角色，不存在两个状态描述同一段工作。
- 字段必填：关键字段标注了填写时点和必填要求，状态流转条件中已绑定必要字段。
- 角色到位：五类角色均有对应人员或岗位，交接物明确，不存在无人认领的状态。
- 升级规则：超时、跨部门、信息不全等触发条件已配置接收角色和处理动作。
- 入口统一：服务请求有唯一提交入口，表单字段与工单字段一致。
上线后可用三项指标观察流程健康度：状态停留时间，反映哪个环节容易积压；退回次数，反映信息质量与分派准确性；记录完整度，反映处理记录和验证结论是否按要求填写。试跑阶段建议逐条检查工单的流转记录是否完整，包括每次状态变化的时间、操作人和原因。三项指标稳定、试跑工单全部闭环、退回原因可归类，即可视为流程初步跑通。
流程上线后仍需维护。流程负责人可定期查看流转数据，把高频退回原因转化为字段提示或表单校验，把反复出现的跨部门问题补充为升级规则。状态机和字段的每次调整都应保留版本记录，并在小范围验证后再全量推行，避免一次改动影响所有在途工单。工具层面，ONES Desk 支持灵活调整工作流以适应不同企业的工作方式，并可自定义工单属性以满足不同角色的收集需求，同时支持一键分享填写链接让用户在门户提单、在处理中直接对话用户，这些能力对应本文的统一入口、字段配置和进度同步环节，可作为流程稳定后扩大使用范围的承载方式。
常见问题
工单状态设多少个比较合适，状态多了会有什么问题？
建议从四到六个状态起步，覆盖待受理、处理中、待验证、已关闭这类主干环节，复杂场景再按需增加待分派、待补充信息、已挂起。状态越多，流转记录越细，但维护成本和填写负担也越高，容易出现状态定义重叠或长期空转。判断标准是每个状态都对应一段可观察的工作和一个明确的责任主体，两个状态描述同一段工作时就应合并。
请求人提交的信息不全，工单应该退回还是先受理？
两种做法都可行，取决于信息缺失的程度。缺少关键信息、无法判断类型和影响范围时，可设置待补充信息状态退回请求人，注明需要补充的内容，补齐后回到待受理；信息基本完整、只缺细节时，可先受理分派，由处理人在处理过程中直接向请求人确认。无论选哪种，退回原因都应写入记录，便于后续统计高频缺失项并优化表单提示。
工单处理需要研发介入时，怎么避免同一问题在两处重复登记？
常见做法是让工单保持处理中状态，同时关联到对应的需求或缺陷工作项，由研发在工作项中推进，处理人负责把结论回填到工单，再进入待验证。这样工单始终是请求人对外的唯一进度入口，工作项承担内部研发跟踪。使用 ONES 时，工单可关联到 ONES Project 的需求或缺陷工作项，也可关联到 ONES Wiki 页面用于经验沉淀，这一衔接需同时使用对应产品。
流程上线后，怎么判断哪些环节需要优先调整？
可以先看三项指标：状态停留时间最长的环节通常是积压点，退回次数集中的环节反映信息质量或分派准确性问题，记录完整度低的环节说明填写要求没有被执行。调整时一次只改最突出的两三个问题，例如把高频退回原因做成表单必填校验，或为反复超时的状态补充升级规则，改完在小范围验证后再全量推行，避免一次改动影响所有在途工单。
小团队也需要区分服务台、受理人、处理人这些角色吗？
角色划分的目的是让每个状态都有明确责任人，人数少时可以由同一人兼任多个角色，但职责边界仍要写清楚。例如一人同时承担服务台和受理人时，登记确认与指定处理人这两个动作仍要分别留下记录，否则出问题时无法判断卡在哪一步。团队规模扩大或工单量上升后，再按现有分工把兼任角色拆开，比一开始就设置大量岗位更容易落地。
