内部IT请求受理要把“谁提、提什么、怎么进、谁来接、多久回、何时关”固化成一条可执行链路，通常由统一入口、表单字段、分级判定、分诊派单、时限升级和关闭归档六个环节组成。本文按顺序给出每一步的做法与交付物，并说明表单、分级规则、角色分工和上线检查项；ONES Desk 可作为承载受理流程的工具，相关能力在对应环节说明。
要点总览（TL;DR）
- 内部IT请求受理按“统一入口—字段校验—分级判定—分诊派单—响应升级—关闭归档”六步推进，每步都要有可检查的输出和完成标志。
- 表单只保留影响分诊的五到七个必填字段，用影响范围与紧急度两维组合定级，判定依据写入工单便于复核。
- 角色分工的关键是每个交接点都有交付物：请求单编号、已确认级别、已尝试动作和联系方式，缺项可退回并记录。
- 上线先用单一入口加分级派单跑通最小闭环，试运行两周后观察首次响应达标率、平均解决时长、升级比例和关闭确认率。
- ONES Desk 可作为承载受理流程的工具，统一门户接收工单、自定义流程与字段、集中管理状态与责任分工，具体时限与升级配置需结合所选版本确认。
受理链路的核心答案与操作步骤
受理链路的价值在于让每个请求都有明确的状态和责任人。落地时按六步推进，每一步都要有可检查的输出，避免请求停在“已收到”却无人推进的状态。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 统一入口 | 请求人身份、请求内容 | 发布唯一提交入口（门户、表单链接或服务台），停用分散的私聊、邮件口头报修 | 一条待受理的请求记录 | 请求人知道从哪里提，且提交后能看到记录编号 |
| 2. 字段校验 | 请求记录 | 检查必填字段是否完整，缺失时退回补充或由受理台电话补录 | 信息完整的请求单 | 请求类型、影响范围、期望时间等关键字段无空缺 |
| 3. 分级判定 | 完整请求单 | 按影响范围与紧急度组合定级，记录判定依据 | 优先级结论 | 请求单上有明确级别和判定理由 |
| 4. 分诊派单 | 已分级请求 | 受理台按类型路由到一线支持组或个人，指定责任人 | 已分派的工单 | 工单有唯一责任人，请求人可见当前处理人 |
| 5. 响应与升级 | 已分派工单 | 责任人在响应时限内首次回复，无法解决时按规则转二线或升级 | 处理记录与升级记录 | 首次响应时间达标，升级时携带完整上下文 |
| 6. 关闭与归档 | 处理完成的工单 | 请求人确认结果，责任人填写解决说明后关闭 | 已关闭工单与归档记录 | 关闭前有请求人确认，解决说明可供后续查询 |
六步中，第2步和第3步最容易失控。信息不全导致来回沟通，分级随意导致高影响请求被低优先级处理。把这两步做成强制规则，后续派单和时限才有可靠基础。建议先跑通“单一入口加分级派单”的最小闭环，再补充知识库、自助提交和报表复盘。
在工具承载上，ONES Desk 面向企业服务与协作场景，可用于 IT 服务、内部支持等场景，通过统一门户集中接收工单，支持自定义处理流程与字段配置，并集中管理工单状态、处理进度和责任分工。这些能力对应上述入口、字段、派单和状态跟踪环节；具体时限与升级规则的配置方式需结合所选版本确认。
请求表单与分级规则怎么设计
表单设计的目标是让受理台在不追问的情况下完成分诊。字段分为两类：影响分诊的字段设为必填，描述性补充信息设为选填。必填字段过多会降低提交意愿，过少则无法分级，通常控制在五到七个。
请求表单字段清单
| 字段 | 必填/选填 | 填写方式 | 用途 |
|---|---|---|---|
| 请求人及所属部门 | 必填 | 从组织目录选择 | 确认身份、联系方式和归属 |
| 请求类型 | 必填 | 下拉选择：账号权限、软件安装、设备故障、网络问题、系统使用咨询等 | 决定默认分诊去向 |
| 影响范围 | 必填 | 单选：仅本人、本团队、多部门、全公司 | 分级的主要依据 |
| 紧急度 | 必填 | 单选：阻塞工作、影响效率、可延后 | 与影响范围组合定级 |
| 期望完成时间 | 必填 | 日期选择 | 校验请求人预期与时限规则是否一致 |
| 问题描述与截图 | 选填 | 文本与附件 | 帮助支持人员预判处理方式 |
| 相关资产编号 | 选填 | 文本或从资产清单选择 | 设备类请求定位具体资产 |
影响度与紧急度组合定级
单一维度定级容易失真：请求人普遍倾向选“紧急”，而影响范围更能反映业务后果。用两维组合形成级别，判定结果写入工单，便于复核。
| 影响范围 | 阻塞工作 | 影响效率 | 可延后 |
|---|---|---|---|
| 全公司或多部门 | P1 | P2 | P3 |
| 本团队 | P2 | P3 | P4 |
| 仅本人 | P3 | P4 | P4 |
常见请求类型可预设默认分诊去向：账号权限类转系统管理员，设备故障类转桌面支持，网络问题转网络组，系统使用咨询优先引导至知识库或自助说明。默认去向只是起点，受理台在信息完整时仍可调整。
分级误判的复核方式有两种：一是受理台在派单前对 P1、P2 请求做二次确认，核对影响范围描述是否与实际一致；二是每周抽查已关闭工单，比较初始级别与实际处理投入，偏差集中的类型回到规则中修正。复核记录本身也是后续调整分级阈值的依据。
角色分工与各环节交付物
受理链路涉及五类角色。职责边界清晰的关键是每个交接点都有明确的交付物，接收方凭交付物判断是否可以继续处理。
| 角色 | 职责边界 | 交付物 | 交接对象 |
|---|---|---|---|
| 请求人 | 通过统一入口提交，按要求补充信息，确认处理结果 | 信息完整的请求单、关闭确认 | 受理台 |
| 受理台（服务台） | 校验字段、判定级别、分诊派单、跟踪时限、处理升级 | 已分级并分派的工单、升级记录 | 一线支持 |
| 一线支持 | 首次响应、常规问题处理、判断是否需要转二线 | 处理记录、转派说明 | 请求人或二线支持 |
| 二线支持 | 处理一线无法解决的复杂问题，给出解决方案或根因说明 | 解决方案、处理结论 | 一线支持或受理台 |
| 审批或资产管理员 | 对涉及权限开通、资产领用的请求做审批或登记 | 审批结论、资产变更记录 | 受理台或一线支持 |
交接时需携带的信息包括：请求单编号、已确认的影响范围与级别、已尝试的处理动作、请求人联系方式。缺少这些信息时，接收方有权退回，退回动作本身也应记录在工单上。
升级与转派的触发条件建议写成可判断的规则：一线在响应时限内无法给出处理方案时转二线；请求影响范围扩大时由受理台提升级别并通知相关方；涉及权限或资产变更时先走审批再执行。职责重叠的情况常见于小团队中受理台与一线由同一人承担，此时应在工单上分别记录“分诊动作”和“处理动作”，保留时间戳，避免时限统计失真。
ONES Desk 支持自定义工作流来制定问题响应流程，工单可关联其他工作项，便于服务团队与研发团队在转派和升级时共享上下文。团队可集中管理工单状态、处理进度和责任分工，使交接信息随工单流转，减少重复沟通。
一个完整受理示例：从提交到关闭
以下为演示情景，用于说明各环节的实际形态，非真实案例。
背景与提交内容。某部门员工在统一入口提交请求：请求类型为“账号权限”，影响范围选“本团队”，紧急度选“阻塞工作”，期望完成时间为次日，描述为“新入职同事需要开通项目文档库的编辑权限，当前无法参与文档协作”，并附上入职通知截图。工单自动生成编号，请求人可在门户查看进度。
分级判定。受理台核对字段：影响范围为本团队、紧急度为阻塞工作，按判定表定为 P2。判定依据记录为“影响本团队协作，非全公司范围”。受理台确认描述与影响范围一致，无需退回补充。
派单与处理经过。按默认分诊规则，账号权限类请求派给系统管理员。系统管理员在响应时限内首次回复，确认权限范围后执行开通，并在工单中记录操作时间和授权依据。因涉及权限变更，审批记录一并附在工单上。处理完成后工单状态变为“待确认”。
关闭确认与记录内容。请求人收到通知，验证权限可用后确认关闭。工单归档内容包含：请求字段、分级依据、派单记录、审批记录、处理说明和关闭时间。这些记录可用于后续同类请求的快速处理，也可作为月度统计的数据来源。
可迁移的规律。这个示例体现三点：必填字段让受理台无需追问即可分级；默认分诊去向缩短派单时间；审批记录与处理记录留在同一工单上，关闭时信息完整。把这三点的做法复制到其他请求类型，链路即可稳定运行。
上线前的准备与完成检查
受理机制是否达到可运行状态，用一份检查清单逐项核对。全部通过后再扩大使用范围；未通过的阻断项应先修正。
| 检查项 | 通过标准 | 未通过时的处理 |
|---|---|---|
| 统一入口 | 只有一个提交入口，链接已发布到常用位置 | 阻断上线，先完成入口收敛 |
| 表单字段 | 必填字段可支撑分级，试填无歧义 | 阻断上线，调整字段后再试 |
| 分级规则 | 影响范围与紧急度组合表已确认，默认分诊去向已配置 | 阻断上线，规则缺失会导致派单随意 |
| 角色与责任人 | 每类请求都有明确接收组，交接物已约定 | 阻断上线，无接收方的请求会滞留 |
| 响应与解决时限 | 各级别时限已与责任人确认，升级触发条件可判断 | 阻断上线，时限缺失则无法考核与升级 |
| 关闭确认方式 | 请求人确认路径已明确，归档字段已定义 | 可先试运行，但需在上线前补齐 |
| 试运行 | 选取一个部门或一类请求试跑两周，记录问题并修正 | 未试运行不建议全量推广 |
运行指标用于判断机制是否真正跑通，建议至少观察四项：首次响应达标率、按级别统计的平均解决时长、升级或转派比例、关闭前请求人确认率。指标连续两周稳定在约定范围内，说明链路可运行；若某类请求的退回补充比例偏高，回到表单字段设计修正。
ONES Desk 提供多维度的数据统计与分析能力，可用于观察工单处理进度和分布；相关能力描述对应企业版，其他版本情况需另行确认。上线阶段建议先用最小闭环收集真实数据，再根据指标调整分级阈值和时限设置。
常见问题
请求人坚持选“紧急”，但实际影响范围很小，受理台该怎么处理？
按影响范围与紧急度组合表定级，而不是直接采纳请求人的自评。受理台在派单前核对描述，若影响范围仅为本人而紧急度选“阻塞工作”，可定为 P3 并在工单上写明判定依据。同时向请求人说明级别对应的时限，让其了解预期。若请求人确有业务上的时间压力，可在描述中补充原因，由受理台判断是否调整，调整记录一并保留。
小团队里受理台和一线支持是同一个人，时限统计会不会失真？
会。同一个人既做分诊又做处理时，两个动作的时间容易混在一起。建议在工单上分别记录“分诊完成时间”和“首次响应时间”，保留时间戳，统计时按动作分别计算。若团队人数允许，至少让分诊和处理由不同人复核一次，或在每周抽查中检查时间记录是否合理。
试运行期间应该选哪类请求先跑，跑多久比较合适？
优先选频次稳定、分诊去向清晰的类型，例如账号权限或软件安装，避免一开始就选跨部门、影响范围大的复杂请求。试运行两周通常能覆盖一个完整的提交、处理、关闭周期，也足以暴露字段歧义和派单错误。试运行期间记录退回补充比例和升级比例，作为调整表单与规则的依据。
关闭确认一定要请求人操作吗，能不能由支持人员直接关闭？
建议保留请求人确认这一步，因为它是判断问题是否真正解决的依据。若请求人长时间不响应，可设定自动关闭规则，例如通知后若干天无回复则关闭，并在工单上注明“未获确认自动关闭”。支持人员直接关闭适用于请求人明确表示已解决、或请求本身被判定为重复提交的情形，两种情况都应留下说明。
用工具承载受理流程时，哪些环节最需要先配置好？
先配置入口表单和分级字段，这两项决定请求能否被正确分诊；再配置分派规则和状态流转，让工单有唯一责任人和可见进度。ONES Desk 通过统一门户集中接收工单，支持自定义处理流程与字段配置，并集中管理工单状态、处理进度和责任分工，可对应上述环节。时限与升级规则的具体配置方式需结合所选版本确认，建议在试运行阶段一并验证。
