工单受理是把一条外部或内部请求转成可执行工单的过程，起于请求进入受理入口，止于工单具备明确责任人和可追踪的下一步。核心动作依次是登记、分类、去重、定级、派单和回执。本文按这个顺序说明每步怎么做、登记哪些字段、角色如何分工，并给出一个完整示例和受理完成检查清单，帮助团队把受理环节固定成可重复执行的动作。
要点总览（TL;DR）
- 工单受理起于请求进入受理入口，止于工单具备明确责任人并已向请求人发出回执，核心动作依次是登记、分类、去重、定级、派单和回执。
- 登记字段以“缺失后无法派单”划分必填项：请求人、联系方式、请求描述、影响范围、分类、优先级建议、受理人和受理时间应设为必填，期望时间和附件可设为选填。
- 一线受理人负责登记、分类、去重、初步定级和回执，派单协调人负责选择处理人和处理派单争议，处理人接单后对状态更新负责；三类角色可兼任，职责边界要写清。
- 受理是否完成用检查清单逐项核对：编号、字段完整性、分类、去重、定级、责任人、下一步、回执和可追溯，任一项不通过就退回补正。
- 受理记录和派单流转可依托工作项统一登记，用状态流转体现受理、派单、处理中的阶段，交接与回执作为工单内记录留存。
受理一条工单要完成哪些动作
受理环节的起点是请求被受理入口接收，终点是工单派给处理人并已向请求人发出回执。六个动作有先后依赖：登记产生工单记录，分类和去重决定这条记录是否独立成立，定级确定处理顺序，派单落实责任人，回执完成对请求人的交代。跳过任何一步，后续处理都会出现责任不清或重复劳动。
实际操作中，登记与分类可以连续完成，去重需要在分类之后对照已有工单判断，定级依赖分类结果和影响范围，派单依赖定级确定的责任团队，回执在派单确认后发出。下表按顺序列出每个动作的输入、做法、输出和完成标志。
| 动作 | 输入 | 做法 | 输出 | 完成标志 |
|---|---|---|---|---|
| 登记 | 请求人提交的描述、联系方式、相关截图或附件 | 在受理入口创建工单，填写基础字段，生成唯一编号 | 一条带编号的工单记录 | 编号已生成，请求人和请求描述可读 |
| 分类 | 工单记录、分类选项表 | 按请求性质选择分类，判断属于哪类服务或哪类内部需求 | 带分类标签的工单 | 分类字段已填写，且与请求内容一致 |
| 去重 | 分类结果、历史工单列表 | 按请求人、关键词、时间范围检索同类工单，判断是否重复 | 去重结论：新建、合并或关联已有工单 | 结论已记录，合并或关联关系已建立 |
| 定级 | 影响范围、紧急程度、请求人范围 | 对照定级标准给出优先级，写明判断依据 | 带优先级的工单 | 优先级已填写，依据可复核 |
| 派单 | 分类、优先级、处理人负载 | 按派单规则选择处理人或处理团队，写明交接内容 | 已指派责任人的工单 | 责任人已确认接单，下一步动作明确 |
| 回执 | 工单编号、责任人、预计下一步 | 向请求人说明已受理、由谁处理、后续如何跟进 | 回执记录 | 回执已发出并留痕 |
六个动作中，去重最容易被省略。请求人重复提交、同一故障多人反馈的情况很常见，受理时花一两分钟检索，可以避免处理团队重复排查。定级也不必追求精确到每一档，关键是让处理人看到优先级时能理解为什么排在这个位置。
受理登记需要哪些字段
登记字段的设计目标是让一条工单在不追问请求人的情况下就能进入分类和派单。字段分三层：基础信息说明谁在什么场景下遇到什么问题，分流信息支撑分类和定级，过程信息记录受理动作本身。必填项以“缺失后无法派单”为划分依据，能通过回访补齐且不影响首次派单的字段可以设为选填。
| 字段名 | 是否必填 | 用途 | 填写要求 |
|---|---|---|---|
| 工单编号 | 必填（系统生成） | 唯一标识，用于检索、关联和回执引用 | 创建时自动生成，不可重复 |
| 请求人 | 必填 | 确认身份，便于回访和回执 | 填写姓名或账号，内部请求填部门 |
| 联系方式 | 必填 | 受理人回访和回执送达 | 电话、邮箱或内部通讯账号，至少一种可用 |
| 请求描述 | 必填 | 说明发生了什么、期望什么结果 | 用请求人原话记录，补充时间、地点、操作步骤 |
| 影响范围 | 必填 | 支撑定级，判断影响人数或业务范围 | 写明受影响的对象和大致数量 |
| 分类 | 必填 | 决定派单方向和统计口径 | 从分类选项中选择，不自行造词 |
| 优先级建议 | 必填 | 给出初步定级，供派单参考 | 按团队定级标准选择，并写一句依据 |
| 期望时间 | 选填 | 了解请求人的时间预期 | 记录请求人提出的时间，不作为承诺 |
| 附件 | 选填 | 截图、日志、表单等佐证材料 | 与请求描述对应，命名可识别 |
| 受理人 | 必填 | 明确谁完成了受理动作 | 填写实际受理人 |
| 受理时间 | 必填（系统记录） | 计算受理耗时，追溯处理起点 | 创建或受理确认时自动记录 |
必填与选填的划分可以随团队成熟度调整。初期把分类和优先级建议设为必填，能迫使受理人做出判断；运行稳定后，可以把期望时间、附件保持为选填，减少请求人的填写负担。字段缺失时的处理方式是补录加回访：请求描述不完整，受理人先按已有信息登记并标注待补充，再通过联系方式回访补齐，补齐后更新工单记录，保留补录时间和补录人。
受理人、派单人与处理人如何分工
受理环节涉及三类角色。一线受理人负责接单、登记、初步分类和回执，是请求人接触到的第一个责任人。派单协调人负责判断工单该交给谁，处理跨团队的派单争议和负载均衡。处理人负责接单后的实际处理，并对工单状态更新负责。三类角色可以由同一人兼任，但职责边界要写清楚，避免出现“已受理但无人处理”的空档。
| 角色 | 主要职责 | 交接动作 | 边界说明 |
|---|---|---|---|
| 一线受理人 | 登记、分类、去重、初步定级、发出回执 | 向派单协调人或直接向处理人移交工单，说明请求要点和已做判断 | 可自行解决简单请求，复杂请求转派 |
| 派单协调人 | 确认分类与定级、选择处理人、处理派单争议 | 向处理人确认接单，记录派单依据 | 不代替处理人做技术判断 |
| 处理人 | 接单确认、处理、更新状态、反馈结果 | 接单时确认理解请求，处理中同步进展 | 发现信息不足时退回受理人补充 |
受理人判断能否自行解决，可以看两个条件：请求是否属于已知问题且有现成处理办法，以及处理是否能在受理环节的职责范围内完成。两个条件都满足时，受理人直接处理并关闭工单，同时在记录中写明处理方式；任一条件不满足，转派给处理人。转派时交接内容至少包括请求描述、已确认的影响范围、分类和优先级判断、请求人的期望时间，以及受理人已经做过的排查动作。
升级与退回各有触发条件。升级适用于影响范围扩大、请求人反复催办或原定处理人无法在合理时间内接单的情况，由派单协调人重新定级并调整处理人。退回适用于请求描述不足以判断问题、分类明显错误或请求人信息无法联系的情况，处理人退回时需写明缺少什么信息，受理人补齐后重新派单。退回不是终点，退回记录本身要保留在工单中。
一个受理示例：从提交到派单完成
以下为演示情景，用于说明字段填写和派单记录方式，不代表真实客户案例。
请求人通过受理入口提交一条请求，原始描述为：“财务系统导出报表时一直转圈，已经试了三次，今天下午要出月报。”受理人登记时补录了以下信息：请求人为财务部员工，联系方式为内部通讯账号；影响范围为财务部当月的报表出具工作，涉及至少两人；请求人期望当天下午前恢复。
分类判断：该请求属于业务系统使用问题，归入“财务系统”分类。去重判断：按“导出”“报表”检索近七天工单，发现另一名财务同事提交过类似描述，两条请求指向同一现象，受理人将新工单与已有工单关联，并在新工单中注明关联关系，避免重复派单。定级判断：影响月报出具且有多人受影响，优先级定为高，依据写为“影响财务月报，涉及多人”。
派单记录：受理人按分类将工单派给财务系统支持组，交接内容包括请求描述、关联的已有工单、影响范围、优先级依据和请求人期望时间。处理人接单后确认收到，并在工单中回复“已接单，先排查导出服务状态”。
回执内容：受理人向请求人发出回执，写明工单编号、已受理、由财务系统支持组处理、当前判断为导出服务问题、后续进展会在工单中同步。受理记录中保留受理人、受理时间、分类、优先级、关联工单和回执发出时间。这条工单到此完成受理，进入处理阶段。
受理完成检查清单
受理是否做完，用一张清单逐项核对比凭感觉判断更可靠。清单同时用于受理人自检和交接验收，任一项不通过就退回补正，补正后再进入处理。
| 检查项 | 通过标准 | 责任人 |
|---|---|---|
| 编号 | 工单已有唯一编号，可被检索到 | 一线受理人 |
| 字段完整性 | 必填字段全部填写，选填缺失项已标注待补充 | 一线受理人 |
| 分类 | 分类字段已填写，与请求内容一致 | 一线受理人 |
| 去重 | 已检索同类工单，新建、合并或关联结论已记录 | 一线受理人 |
| 定级 | 优先级已填写，判断依据可复核 | 一线受理人或派单协调人 |
| 责任人 | 处理人已确认接单，姓名或团队明确 | 派单协调人 |
| 下一步 | 工单中写明了下一步动作和预计跟进方式 | 处理人 |
| 回执 | 回执已发出，内容包含编号、责任人和跟进方式 | 一线受理人 |
| 可追溯 | 受理时间、受理人、派单记录和回执记录均可查询 | 一线受理人 |
不通过时的处理动作按项对应：字段缺失退回受理人补录并回访请求人；分类或定级有误退回重新判断；责任人未确认接单由派单协调人重新协调；回执未发出由受理人补发并记录补发时间。退回和补正都留在工单记录中，便于后续复盘受理质量。
用工具承载受理记录与派单流转
受理动作固定下来之后，记录和流转需要有统一的承载方式，否则编号、字段、责任人和回执分散在聊天记录和表格里，追溯成本很高。可以把每条工单作为一条工作项统一登记，受理字段作为工作项属性配置，分类选项和必填规则按团队字段清单设置，这样登记时就能约束必填项，减少事后补录。
状态流转对应受理阶段。工单从新建进入受理，受理完成后进入待派单或处理中，处理人接单后状态更新为处理中，处理完成再进入已解决。状态名称和流转条件可以按团队实际流程配置，关键是让每个状态对应一个明确的责任人和下一步动作。交接和回执作为工单内的记录保留，处理人接单、退回、升级都留下操作痕迹，复盘时可以还原受理过程。
ONES Desk 面向企业服务与协作场景，提供统一门户集中接收工单，支持自定义处理流程与字段配置，可用于承载受理记录和派单流转。请求人可以通过分享的填写链接在门户提单，受理人在工单中与请求人对话并同步处理进度，回执和沟通记录随工单留存。当工单需要研发侧介入时，可关联到 ONES Project 的需求或缺陷工作项持续跟踪，服务团队与研发团队的交接内容也保留在关联关系中。具体状态名称和字段配置方式以团队实际搭建为准。
常见问题
请求人描述太模糊，受理人应该先退回还是先登记？
建议先登记再补录，不要直接退回。受理人按已有信息创建工单并生成编号，把请求描述标注为待补充，再通过联系方式回访补齐时间、地点、操作步骤和影响范围。补齐后更新工单记录，保留补录时间和补录人。直接退回会让请求人重复提交，也丢失了首次受理的时间点，后续计算受理耗时和追溯处理起点都会受影响。
同一问题有多人反馈，是合并成一条工单还是各自保留？
取决于处理方式和统计需要。如果多条请求指向同一现象、由同一处理人解决，可以保留一条主工单，其余工单关联到主工单并注明关联关系，处理进展统一在主工单同步。如果不同请求人的影响范围、期望时间差异较大，各自保留工单、只建立关联更合适，避免回执和跟进对象混淆。无论哪种方式，去重结论都要记录在工单中，便于复盘时看清合并或关联的依据。
受理人自己就能解决的问题，还需要走派单流程吗？
可以不走派单，但受理记录要完整。判断条件是请求属于已知问题且有现成处理办法，并且处理能在受理环节职责范围内完成。两个条件都满足时，受理人直接处理并关闭工单，在记录中写明处理方式和处理时间，同时向请求人发出结果说明。任一条件不满足就转派。这样既保留了受理动作的留痕，也避免简单请求在派单环节空转。
处理人接单后发现信息不足，退回时要注意什么？
退回时写明缺少什么信息、需要受理人补充到什么程度，不要只写“信息不足”。受理人补齐后重新派单，退回和补正的记录都保留在工单中。退回次数较多时，可以反过来检查受理字段清单，看是否某些必填项设置得不够，或者请求描述字段的填写要求需要细化，从源头减少退回。
受理记录分散在聊天工具和表格里，怎么统一管理？
可以把每条工单作为一条工作项统一登记，受理字段配置为工作项属性，分类选项和必填规则按团队字段清单设置，登记时就约束必填项。状态流转对应受理阶段，从新建进入受理，受理完成后进入待派单或处理中，处理人接单后更新状态。交接、退回、升级和回执都作为工单内记录保留，复盘时可以还原受理过程。ONES Desk 提供统一门户集中接收工单，支持自定义处理流程与字段配置，可用于承载受理记录和派单流转；需要研发侧介入时，可关联到 ONES Project 的需求或缺陷工作项持续跟踪。
