工单受理是把用户提交的服务请求转成可跟踪、可派发、可交付的工作项的过程。它包含登记与去重、分类与优先级初判、受理确认、派单交接、状态推进与关闭回访几个关键动作，产物是字段完整的工单记录、受理确认信息、派单记录和关闭结论。本文只覆盖受理环节：事件恢复与根因分析归服务事件与问题管理，时限承诺归工单优先级与 SLA 管理，均不在此展开。受理记录与状态推进可以借助 ONES 工作项与流程能力承载，下文在相应步骤中自然说明。
要点总览（TL;DR）
- 工单受理的主流程分六步：入口与登记、去重与合并、分类与优先级初判、受理确认与回执、派单与交接、状态推进与关闭，每一步都要有输入、动作、输出和完成标志。
- 角色划分以交付物为准：服务台受理人交出完整工单记录与派单记录，一线与二线处理人交出处理结论，流程负责人维护字段与状态规则并抽查受理质量。
- 受理字段按必填最小集合设计，覆盖请求人、描述、分类、影响范围、优先级初判、受理人和状态；状态主干为新建—已受理—已派单—处理中—待确认—已关闭，退回与升级作为分支动作记录原因。
- 判断受理是否做到位，看每条工单能否回答四个问题：谁提的、是什么问题、为什么这样分类定级、现在在谁手上。
- 受理环节只负责接住请求并交到正确的人手上，事件恢复与根因分析、时限承诺分别归服务事件与问题管理、工单优先级与 SLA 管理。
工单受理要完成哪些动作：核心流程与操作步骤
受理环节的目标是把请求接住，并交到正确的人手上。围绕这个目标，主流程可以拆成六步，每一步都要有明确的输入、动作、输出和完成标志，避免工单停在“已收到”却无人推进的状态。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 入口与登记 | 用户通过门户、邮件、电话或即时消息提交的请求 | 在统一入口创建工单，填写请求人、联系方式、请求描述、提交时间等基础信息 | 一条新建状态的工单记录 | 必填字段齐全，请求描述能独立读懂 |
| 2. 去重与合并 | 新建工单及近期同类工单 | 按请求人、对象、现象、时间窗口比对，判断是否为重复提交或同一问题的多次反馈 | 去重结论；合并后的主工单与关联记录 | 确认唯一主工单，重复记录已关联并注明原因 |
| 3. 分类与优先级初判 | 请求描述、影响范围、受影响人数或业务 | 选择服务分类，判断影响范围，给出优先级初判并写明依据 | 分类、影响范围、优先级字段及判断说明 | 分类取值在字典内，优先级有可复核的理由 |
| 4. 受理确认与回执 | 已分类的工单 | 向请求人确认已受理，说明下一步和预计响应方式，补充缺失信息 | 受理确认信息、补充后的工单记录 | 请求人收到回执，关键信息无歧义 |
| 5. 派单与交接 | 受理确认后的工单 | 按分类和技能选择处理人或处理组，写清交接说明与已尝试动作 | 派单记录：处理人、派单时间、交接说明 | 处理人明确接单，交接内容足以独立开展处理 |
| 6. 状态推进与关闭 | 处理过程中的进展与结论 | 随处理进展更新状态，处理完成后确认结果并关闭，必要时回访 | 状态变更记录、关闭结论 | 关闭结论写明解决方式，请求人确认或回访完成 |
六步中，第2、3步最容易压缩成“看一眼就派”。去重判断依赖对近期工单的可见性，分类和优先级初判依赖取值字典和判断依据的书写习惯。把这两步的完成标志写进流程，受理质量才有可检查的抓手。
在工具承载上，统一入口可以用 ONES Desk 的工单门户集中接收请求，通过分享填写链接收集反馈，让请求人直接提交结构化信息；自定义工单属性可以把分类、影响范围等字段固化到表单里，减少受理人手工补录。工单进入系统后，状态推进和派单记录随工作项流转留存，便于后续检查。
受理环节的角色与交付物怎么划分
受理环节涉及五类角色。职责边界清晰的关键，是每个角色都有明确的交付物，交接时以交付物为准，而不是口头转述。
| 角色 | 核心职责 | 交付物 |
|---|---|---|
| 服务台受理人 | 接住请求，完成登记、去重、分类与优先级初判，发出受理回执，执行派单 | 字段完整的工单记录、受理确认信息、派单记录 |
| 一线支持 | 处理常见请求和标准问题，判断是否需要升级二线 | 处理过程记录、解决结论或升级说明 |
| 二线处理人 | 处理一线无法解决的技术或业务问题，给出处理结论 | 处理记录、根因线索、解决或转出结论 |
| 请求人 | 提交清晰的问题描述，配合补充信息，确认处理结果 | 请求描述、补充信息、结果确认 |
| 流程负责人 | 维护分类字典、状态规则和受理标准，抽查受理质量 | 字段与状态规则、受理检查记录、改进项 |
角色之间的交接物要能独立支撑下一步动作。受理人交给一线支持的，不只是工单编号，还包括请求现象、影响范围、已尝试的排查动作和请求人的期望；一线升级二线时，交接物要写清已排除的方向和需要二线判断的具体问题。交接物缺失时，接收方有权退回补充，退回原因记录在工单上，形成可追溯的闭环。
升级与退回需要规则约束。升级适用于影响范围扩大、超出当前处理人权限或技能范围、处理时限临近的情况，升级时保留原处理人为协办人，避免信息断档。退回适用于交接信息不足、分类明显错误或派错对象的情况，退回必须写明缺什么、应由谁补，退回次数纳入受理质量抽查。
小团队或单人服务台场景，受理人与一线支持可以由同一人承担，但登记记录和派单记录仍要保留。合并角色时，建议把“受理确认”和“开始处理”两个动作在记录上分开，否则后续统计无法区分等待时间和处理时间。
受理字段与工单模板怎么设计
字段设计的目标是支撑三件事：受理人能快速判断，处理人能独立接手，流程负责人能统计。字段分必填和选填两类，必填字段控制在能支撑判断的最小集合，避免表单过长导致请求人不愿填写。
| 字段 | 必填/选填 | 填写规则 |
|---|---|---|
| 请求人及联系方式 | 必填 | 门户提交时自动带入；电话或邮件受理时由受理人补录 |
| 请求描述 | 必填 | 写清现象、发生时间、操作步骤和期望结果，避免只写“用不了” |
| 服务分类 | 必填 | 从分类字典中选择，字典按业务域两级维护，禁止手填自由文本 |
| 影响范围 | 必填 | 按单人、单部门、多部门、全组织等档位选择，作为优先级初判依据 |
| 优先级初判 | 必填 | 取值如紧急、高、中、低，选择时附一句判断理由 |
| 受理人 | 必填 | 记录实际完成受理动作的人，便于追溯 |
| 状态 | 必填 | 按状态流转规则变更，不允许跳过中间状态 |
| 期望完成时间 | 选填 | 由请求人提出或受理人沟通确认，仅作参考，不构成时限承诺 |
| 附件与截图 | 选填 | 用于补充现象证据，敏感信息需脱敏 |
| 关联资产或系统 | 选填 | 涉及具体设备、系统或账号时填写，便于处理人定位 |
状态字段建议采用“新建—已受理—已派单—处理中—待确认—已关闭”的主干，退回和升级作为分支动作记录原因，不单独增设状态，避免状态数量膨胀。状态流转规则要写清每个状态的进入条件和责任人：新建进入已受理，以受理确认发出为准；已受理进入已派单，以处理人明确接单为准；处理中进入待确认，以处理人提交解决结论为准；待确认进入已关闭，以请求人确认或回访完成为准。团队规模较小时可以合并“已受理”和“已派单”，但合并后要保留派单时间字段。
字段和状态需要定期维护。建议流程负责人每季度回顾一次分类字典的使用情况，合并长期空置的分类，拆分高频的“其他”类；新增字段前先确认它服务于哪个判断或统计口径，没有明确用途的字段不进入必填集合。字段调整要同步更新门户表单和受理检查清单，避免规则与实际填写脱节。
ONES Desk 支持自定义工单属性与工单内容，并可灵活调整工作流，上述分类、影响范围、优先级等字段和状态主干可以按团队实际口径配置；工单优先级支持评估和定义，便于受理人把初判结果落到字段上。
一个受理示例：从提交到派单的完整走查
以下为演示情景，用于说明字段填写与判断依据，不代表真实客户案例。
请求人通过门户提交：“财务共享中心的报销系统从今天上午开始，提交报销单后一直显示加载中，部门内多位同事都遇到，下午要完成本月报销截止。”受理人按流程走查：
| 环节 | 处理结果 | 判断依据 |
|---|---|---|
| 登记 | 门户表单自动带入请求人、部门、联系方式；请求描述补充了发生时间、操作步骤和期望 | 描述能独立读懂，无需二次追问即可判断影响面 |
| 去重 | 检索近三日同类工单，发现另一部门有一条“报销单提交卡顿”记录，现象一致，合并为同一主工单并关联 | 请求对象相同、现象一致、时间窗口重叠 |
| 分类与优先级 | 分类选“业务系统—财务报销”；影响范围选“多部门”；优先级初判为“高”，理由：影响报销截止，涉及多部门但系统仍可登录 | 影响范围跨部门，存在时间压力，尚未达到全组织不可用 |
| 受理确认 | 向请求人回执：已受理，正在核实，预计当日反馈进展；请补充一张报错截图 | 回执说明下一步和补充要求，请求人可预期 |
| 派单 | 派给财务系统支持组，交接说明写明：多部门提交卡顿、已合并一条同类工单、请求人将补充截图、下午为报销截止时间 | 分类对应处理组，交接内容足以让处理人直接排查 |
| 状态变化 | 新建→已受理→已派单，派单时间与处理人记录在案 | 处理人明确接单，状态与记录一致 |
这条示例说明两个判断要点：去重不是简单看标题，而是比对请求对象、现象和时间窗口；优先级初判要写出理由，理由本身是可以被复核和纠正的。派单交接说明里带上截止时间和已合并信息，处理人就不必回头再问受理人。
当请求涉及研发侧修复时，受理后的工单可以在 ONES Desk 中一键关联到 ONES Project 的需求或缺陷工作项，持续跟踪到处理完成，服务团队与研发团队的交接因此有共同的记录载体。
受理质量怎么检查：完成标准与常见缺口
受理是否做完、做对，可以用一张检查清单逐项核对。检查以工单记录为依据，抽查频率可按团队规模设定，例如每周抽查已派单工单，每月回顾关闭工单。
| 检查项 | 通过标准 | 常见缺口与纠正动作 |
|---|---|---|
| 必填字段完整性 | 请求人、描述、分类、影响范围、优先级、受理人、状态均已填写 | 描述过于简略：退回请求人补充或受理人电话确认后补录 |
| 去重判断 | 有比对记录，重复工单已关联并注明主工单 | 未检索近期工单：在流程中增加检索步骤，抽查时核对关联记录 |
| 分类准确性 | 分类取值在字典内，与请求内容匹配 | 习惯性选“其他”：复盘“其他”类占比，补充细分分类 |
| 优先级依据 | 优先级有书面理由，与影响范围一致 | 只填档位不写理由：把理由设为必填说明项 |
| 受理回执 | 请求人收到确认，回执含下一步说明 | 受理后无回音：将回执作为进入已受理状态的条件 |
| 派单交接 | 处理人明确，交接说明含现象、影响、已尝试动作 | 只转工单号：退回补充，退回原因记录在案 |
| 状态一致性 | 状态与实际进展一致，无跳步 | 长期停在已派单：设置状态停留提醒，由流程负责人跟进 |
| 关闭结论 | 写明解决方式，请求人确认或回访完成 | 无结论直接关闭：关闭前校验结论字段，缺失则退回处理人 |
证据留存跟着检查项走：工单记录本身是主要证据，受理回执、派单记录、退回原因和关闭结论都应在工单上可查。流程负责人对检查结果负责，抽查发现的问题按类型归并，属于字段设计的改字段，属于习惯问题的做针对性说明，属于规则缺失的补规则。ONES Desk 可汇总工单处理情况、把控处理进度，并提供工单分析报表，抽查和回顾可以直接基于报表数据展开，减少手工统计。
受理环节做到位，标志是每条工单都能回答四个问题：谁提的、是什么问题、为什么这样分类和定级、现在在谁手上。这四个问题有答案，受理就完成了把请求接住并交到正确的人手上的任务，后续处理与时限管理才有可靠起点。
常见问题
请求人只写了一句“系统用不了”，受理人应该退回还是先受理？
建议先受理再补充，不要直接退回。受理人可以先按已有信息登记，把请求人、提交时间、涉及系统等基础字段填上，然后通过回执向请求人提出具体补充要求，例如现象截图、发生时间、操作步骤和受影响范围。补充信息到位后再完成分类和优先级初判。退回更适合交接信息不足或派错对象的情况，用在请求人首次提交上容易让请求人重复提交、拉长受理时间。
单人服务台把受理和处理合并成一个人做，流程上要注意什么？
合并角色可以简化操作，但记录上要把“受理确认”和“开始处理”两个动作分开留痕。受理确认对应回执发出时间，开始处理对应实际动手时间，两者分开后，等待时间和处理时间才能分别统计。登记记录和派单记录也要保留，即使派单对象就是自己，派单时间和交接说明仍要写入工单，否则后续抽查无法判断受理是否完成。
分类字典里的“其他”类占比越来越高，该怎么处理？
先看“其他”类工单的实际内容，把出现频率高的请求归并成新的细分分类，再回顾原有分类是否有长期空置的项，合并或停用。调整分类字典时同步更新门户表单和受理检查清单，避免请求人看到的选项和受理人使用的字典不一致。建议由流程负责人按季度回顾一次分类使用情况，把分类维护纳入例行工作，而不是等到统计失真再集中整改。
工单已经派出去，处理人迟迟不接单，受理环节要不要跟进？
要跟进，但跟进的边界是确认交接是否被接收，不介入具体处理。可以在流程中约定接单确认时限，超时未接单时由受理人提醒处理人或其所在组负责人；如果处理人认为交接信息不足，按退回规则写明缺什么、由谁补，退回原因记录在工单上。状态长期停在已派单的情况，适合纳入受理质量抽查，由流程负责人跟进，判断是交接质量问题还是派单对象选择问题。
受理阶段记录的“期望完成时间”和 SLA 时限承诺是什么关系？
期望完成时间是请求人提出或双方沟通确认的参考信息，用于安排处理顺序和沟通预期，本身不构成时限承诺。时限承诺的制定、计算和考核属于工单优先级与 SLA 管理的范围，需要单独定义服务级别、响应与解决时限以及计算口径。受理环节要做的是把期望时间如实记录，并给出优先级初判及理由，为后续时限管理提供输入。
