员工把IT请求发到群里、私聊或邮件，服务台往往要先追问一轮才能判断该由谁处理。解决这个问题需要三样东西：一套员工能快速选对的分类维度、一张写明受理条件与去向的范围表，以及清晰的角色分工。本文按“请求对象+影响范围”建立分类，逐类定义受理、转派和退回规则，并给出可直接填写的示例表与上线前检查清单。
要点总览（TL;DR）
- 先按请求对象（账号、设备、软件、网络、权限）做一级分类，再用影响范围（单人、多人、业务中断）做二级判断，一级分类控制在五到七个，让员工能独立选对。
- 受理范围表要逐类写明受理条件、必要信息、不受理情形和转出去向；转出去向写到具体岗位或入口，避免“转相关部门”这类无效描述。
- 服务请求与故障报修在分类阶段就分开，事件恢复和根因治理归服务事件与问题管理，本文只处理到受理判断为止。
- 请求人、服务台一线、二线支持各有明确交付物；受理判断留下分类、优先级、责任人和依据，退回统一说明缺什么、为什么、如何补。
- 上线前用检查清单验收：非IT同事试填看首次选对率，逐类核对受理人和去向，并设定复核周期随请求量和退回原因调整。
先定分类维度：按什么把IT请求分开
分类的第一目标是让员工在提交时能独立选对类型，第二目标才是方便服务台统计。因此维度要从员工能感知的信息出发，避免按组织架构或历史习惯切分。建议采用两级结构：一级看请求对象，二级看影响范围。
一级分类：按请求对象划分
请求对象是员工最清楚的信息，通常可以直接对应到五类：账号、设备、软件、网络、权限。每类下面可以再列少量常见事项，例如账号类包含开通、密码重置、离职停用；设备类包含领用、更换、故障报修；软件类包含安装、授权申请、版本升级；网络类包含接入、VPN、访问异常；权限类包含系统角色申请、数据访问授权、权限回收。
一级分类控制在五到七个，员工在提交页面上扫一眼就能定位。分类过多会迫使他们猜测，猜测错误又会把判断成本转回服务台。
二级判断：按影响范围定优先级
影响范围回答“这件事影响了谁、影响到什么程度”，建议分为三档：单人受影响、多人受影响、业务中断。单人受影响按常规排队处理；多人受影响需要提升优先级并通知相关团队；业务中断属于紧急情形，应立即进入应急响应通道，同时按故障报修流程处理。
影响范围由请求人初判、服务台复核。请求人容易把个人不便描述成业务中断，所以提交表单中应要求填写“受影响人数”和“当前是否有可用的替代方式”，服务台据此校正优先级。
服务请求与故障报修的边界
服务请求是“我想要某样东西或某项变更”，例如开通账号、安装软件、申请权限，处理结果是交付或变更完成。故障报修是“原本可用的东西不能用了”，例如电脑无法开机、网络断开、系统报错，处理结果是恢复可用。
两者在分类阶段就应分开，因为它们的时效要求、责任人和记录方式不同。同一类对象下可以同时存在两种请求，例如设备类既有“领用新设备”的服务请求，也有“设备故障”的报修，提交时用两个选项区分即可。事件恢复和根因治理属于服务事件与问题管理的范畴，本文只处理到受理判断为止。
明确受理范围：哪些受理、哪些转出
受理范围要回答三个问题：这类请求满足什么条件才受理、需要请求人提供什么信息、不满足条件时转给谁。只写“受理/不受理”而不写判断依据，服务台每次都要重新讨论，规则很快失效。
受理条件与必要信息
每类请求的受理条件应写成可核验的条目。例如账号开通的受理条件是：请求人已入职或有明确的业务需要、申请对象为本人或本团队成员、审批人已确认。必要信息包括姓名、所属部门、需要开通的系统、权限范围、生效时间。
必要信息缺失时，服务台应退回补充而不是直接受理。退回时说明缺哪一项、为什么需要，员工补齐后重新提交，避免同一请求反复往返。
不受理情形与转出去向
不受理不等于拒绝服务，多数情况是“不归这个入口”。常见情形包括：请求超出IT服务目录范围，转给对应业务部门；涉及采购预算的设备申请，转给行政或采购流程；涉及人事变动的账号处理，由HR发起后IT执行；属于设备维修技术教程范畴的操作指导，引导员工查阅知识库或由厂商支持处理。
每一条转出去向都要写到具体入口或角色，例如“转行政资产管理员”“由HR在入职流程中发起”。写“转相关部门”等于没有写。
| 类型 | 受理条件 | 必要信息 | 不受理情形 | 去向 |
|---|---|---|---|---|
| 账号开通 | 已入职或有业务需要，审批人确认 | 姓名、部门、系统、权限范围、生效时间 | 申请人非本人且无授权 | 退回补充授权说明 |
| 账号停用 | 离职、转岗或安全事件触发 | 人员、停用时间、涉及系统 | 无HR或主管确认 | 由HR流程发起后转回IT |
| 设备领用 | 在编制内且有库存或采购预算 | 设备类型、使用人、用途、交付时间 | 超出标准配置且无审批 | 转行政/采购审批 |
| 设备故障 | 设备在保或属公司资产 | 资产编号、故障现象、影响范围 | 个人设备维修 | 引导至厂商或个人处理 |
| 软件安装 | 软件在许可清单内 | 软件名称、版本、用途、使用人 | 未授权软件或存在合规风险 | 转信息安全评估 |
| 网络接入 | 办公场所内、设备合规 | 位置、设备、网络类型、故障现象 | 家庭网络问题 | 提供自助指引 |
| 权限申请 | 有岗位职责依据、数据 owner 审批 | 系统、角色、数据范围、期限 | 越权申请或缺少审批 | 退回并说明审批要求 |
角色与交付物：谁判断、谁受理、谁交接
受理流程涉及三类角色：请求人、服务台一线、二线支持人员。每个角色在每一步都有明确的输入和产出，交接时以记录为准，减少口头传递造成的信息丢失。
请求人：提交完整信息
请求人的交付物是一条信息完整的请求：选对分类、填写必要字段、说明影响范围、附上审批或截图等佐证。提交前对照表单提示自查一遍，可以显著减少退回次数。
服务台一线：判断受理与分派
一线的核心动作是依据受理范围表做三选一：受理、转派、退回。受理时记录分类、优先级、责任人；转派时写明转给谁、为什么转；退回时说明缺什么、如何补。一线的交付物是带有明确状态和判断依据的请求记录。
二线支持：接手条件与反馈
二线接手的条件是：请求已受理、必要信息齐全、责任人和优先级已确定。二线在处理过程中应更新状态，处理完成后填写结果和后续建议。若发现分类错误或信息不足，应退回一线并注明原因，而不是自行改分类后继续处理，否则统计数据会失真。
| 环节 | 责任角色 | 输入 | 交付物 |
|---|---|---|---|
| 提交 | 请求人 | 业务需要、审批、现象描述 | 分类正确、字段完整的请求 |
| 受理判断 | 服务台一线 | 请求内容、受理范围表 | 受理/转派/退回结论及依据 |
| 处理 | 二线支持 | 已受理的请求、责任人 | 处理结果、状态更新 |
| 交接 | 转出方与接手方 | 请求记录、判断依据 | 交接说明与新的责任人 |
操作步骤：从提交到受理判断的完整流程
下面按输入、动作、输出、完成标志描述受理流程，适用于服务台日常运转，也可作为工具配置的依据。
第一步：员工选择分类并填写字段
输入是员工的业务需要。动作是在提交入口选择一级分类和具体事项，填写影响范围、必要信息和佐证材料。输出是一条待判断的请求。完成标志是表单必填项全部填写、分类已选择。
第二步：服务台判断受理、转派或退回
输入是新提交的请求和受理范围表。动作是核对受理条件、检查必要信息、复核影响范围，然后做出三选一判断。输出是受理结论及依据。完成标志是请求状态从“待判断”变为“已受理”“已转派”或“已退回”。
第三步：受理后记录分类、优先级和责任人
输入是受理结论。动作是确认最终分类（必要时校正员工所选）、设定优先级、指定责任人。输出是一条可跟踪的工单记录。完成标志是分类、优先级、责任人三项齐全，请求进入处理队列。
第四步：退回或转出时告知下一步
输入是退回或转出结论。动作是向请求人说明原因、需要补充的内容或接手方，并给出预计响应时间。输出是一条对请求人可见的说明。完成标志是请求人知道下一步该做什么，请求状态与实际去向一致。
流程中的分类、状态、责任人和判断依据需要被稳定记录，才能支撑后续统计和规则调整。ONES Desk 面向企业服务与协作场景，可用于IT服务、内部支持等场景，支持通过统一门户集中接收工单、自定义工单属性与工作流，并可评估和定义工单优先级、汇总处理进度；当请求需要研发侧跟进时，工单可关联到 ONES Project 的需求或缺陷工作项继续跟踪。具体字段和工作流配置需结合企业实际流程验证。
示例：一张分类与受理范围表怎么填
以下示例选取账号权限、办公设备、软件安装三类，展示填写方式。示例中的审批角色和时限为演示设定，实际填写时替换为本企业的真实角色和口径。
账号权限类
受理条件：申请人为在职员工，申请对象为本人或本团队成员，数据 owner 或主管已审批。必要信息：系统名称、角色或数据范围、使用期限、审批记录。不受理情形：越权申请、缺少审批、申请对象已离职。去向：退回并说明审批要求；离职相关处理由HR流程发起后转回IT执行。
办公设备类
受理条件：设备属公司资产且在保，或申请在标准配置范围内。必要信息：资产编号、故障现象或设备型号、影响范围、是否有替代设备。不受理情形：个人设备维修、超出标准配置且无审批。去向：个人设备引导至厂商支持；超配申请转行政或采购审批。
软件安装类
受理条件：软件在许可清单内，使用用途与岗位相关。必要信息：软件名称与版本、用途、使用人、安装设备。不受理情形：未授权软件、存在安全合规风险。去向：转信息安全评估，评估通过后回到软件安装流程。
影响范围在示例中的体现：同一账号权限请求，若影响多人协作（如团队共享目录权限），优先级上调并通知相关成员；若仅影响单人且存在替代方式，按常规排队。退回时的沟通方式统一为三句话：说明缺什么、说明为什么需要、说明补齐后如何重新提交。
完成检查：分类和受理范围是否可用
规则上线前，用下面这份清单逐项核对。任何一项无法通过，都说明分类或受理范围还需要调整。
- 员工能否在少量选项中选对类型：找几位非IT岗位的同事试填，统计首次选对率；错误集中在哪一类，就拆分或改写那一类的描述。
- 每类请求是否有明确受理人和去向：逐类检查责任角色是否落实到岗位，转出去向是否写到具体入口，避免出现“待定”。
- 退回情形是否有统一说法：抽查退回记录，确认都包含缺什么、为什么、如何补三项内容。
- 分类与受理范围是否定期复核：设定复核周期，结合请求量、退回率和分类变更记录调整选项，新增系统或设备时同步更新范围表。
- 记录是否支持后续统计和调整：确认每条请求都留下分类、优先级、责任人、判断依据和处理结果，能够按类型统计受理量、退回原因和转出比例。
这套检查的目的不是追求一次设计到位，而是让分类和受理范围具备可修正的入口。运行一段时间后，退回原因分布和转出比例会直接指出哪些类型定义不清、哪些去向需要补充，据此迭代即可。
常见问题
员工提交时选错分类，服务台应该直接改掉还是退回重选？
建议分情况处理。若只是二级事项选偏、必要信息齐全，服务台可在受理时校正分类并记录原选项，避免员工反复提交；若选错导致必要信息缺失或走错入口，应退回并说明应选哪一类、需要补哪些字段。无论哪种方式，都要在记录中保留“员工所选分类”和“最终分类”两个值，否则后续统计无法看出哪类选项容易被误选，也就失去了优化分类描述的依据。
影响范围由员工自己判断，容易夸大或低估，怎么校正？
把影响范围设计成可核验的字段，而不是让员工自由描述。提交表单要求填写受影响人数、当前是否有替代方式、是否影响对外业务，服务台据此复核并调整优先级。对于被上调为多人受影响或业务中断的请求，服务台应回告请求人调整结果和响应安排；对于被下调的请求，说明排队依据。运行一段时间后，对比员工初判与服务台复核结果，若某类请求偏差集中，就改写该类的影响范围提示语。
转出去的请求如何避免变成“没人管”？
关键在于转出时写清三件事：转给哪个岗位或哪个流程入口、接手方需要什么信息、请求人下一步做什么。转出方在记录中更新状态和责任人，接手方确认接收后才算完成交接。对于跨部门转出（如设备采购转行政、账号停用由HR发起），建议约定确认时限，超时未确认的请求回到服务台跟进。定期统计各类转出比例和滞留时长，能发现哪些去向需要补充规则或调整入口。
分类和受理范围表多久复核一次比较合适？
没有统一周期，可按请求量和新系统上线节奏设定。常见做法是每季度做一次常规复核，新增系统、设备型号或组织调整时同步更新范围表。复核时重点看三项数据：各类请求的退回原因分布、转出比例、员工首次选对率。退回集中在某一类，说明受理条件或必要信息写得不清；转出比例异常升高，说明入口划分需要调整；选对率低的类型，优先改写选项描述。复核结论要落到具体条目修改，而不是只开会讨论。
用工具承载这套受理流程时，需要关注哪些配置点？
重点看四项：提交入口能否按一级分类组织表单并设置必填字段；工单属性能否记录员工所选分类、最终分类、影响范围和判断依据；工作流能否支持受理、转派、退回、处理等状态流转并保留操作记录；统计能否按类型汇总受理量、退回原因和转出比例。ONES Desk 面向企业服务与协作场景，可用于IT服务、内部支持等场景，支持通过统一门户集中接收工单、自定义工单属性与工作流，并可评估和定义工单优先级、汇总处理进度；当请求需要研发侧跟进时，工单可关联到 ONES Project 的需求或缺陷工作项继续跟踪。具体字段和工作流配置需结合企业实际流程验证。
