内部IT请求受理要解决的是“请求从哪里进、按什么规则分流、由谁接住、请求人如何看到进展”。本文围绕受理环节展开，给出统一入口、必填字段、影响与紧急度分级、角色分工、完整示例和上线检查方法，帮助你把口头、私聊和邮件里的零散请求收进一条可跟踪的流程。
要点总览（TL;DR）
- 先统一受理入口，再定稿请求单必填字段；字段稳定后，分级和统计才有可靠口径。
- 优先级按影响范围与紧急度两个维度判断，分派规则与升级触发条件要同步明确。
- 服务台、一线支持、二线专业组和请求人各自有明确动作与交付物，任一时刻请求单只有一个当前责任人。
- 上线前先定类型目录与分级规则，再收敛渠道、配好值班与超时提醒，最后小范围试运行观察一个完整业务周期。
- 用受理及时率、一次解决率、退回率和平均首次响应时间检查运转情况，抽样复核字段完整性，发现绕开入口或长期挂起要回到对应环节修规则。
受理流程从哪一步开始：入口、字段与分级
受理流程的起点是统一入口。入口不统一，后续的登记、分级和统计都无从谈起。确定入口时，先盘点当前请求实际从哪些渠道进来，再决定哪些渠道保留、哪些渠道收口。常见做法是保留一个主入口，其他渠道只作为转单来源。
- 门户表单：适合作为主入口。请求人按固定字段填写，提交即生成请求单，字段完整度最高。
- 邮件转单：保留服务台邮箱，由受理岗把邮件内容录入或转为请求单，避免请求停留在个人收件箱。
- 电话登记：由受理岗代填，适合紧急或不便使用表单的请求人，登记后需向请求人复述关键信息。
- IM机器人：适合高频、标准化的小请求，机器人按模板收集字段后生成请求单。
入口确定后，需要定稿请求单的必填字段。字段一旦定稿应保持稳定，否则统计口径会随字段变化而失真。基础字段清单如下：
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 请求人 | 姓名与工号 | 识别身份、回访与确认 |
| 部门 | 所属组织 | 统计分布、成本归集 |
| 联系方式 | 电话或IM | 处理过程中的沟通 |
| 请求类型 | 从类型目录中选择 | 分派依据、知识沉淀分类 |
| 影响范围 | 单人、团队、部门、全公司 | 优先级判断 |
| 期望时间 | 请求人期望的完成时间 | 排期参考、期望管理 |
| 描述与附件 | 现象、报错信息、截图 | 初判与一次解决 |
优先级按影响范围与紧急度两个维度判断。影响范围回答“多少人、多少业务受影响”，紧急度回答“能否等到下一个工作日”。两个维度交叉后形成分级，示例：影响为全公司且紧急度为“业务中断”，定为最高级，立即分派并通知二线；影响为单人且紧急度为“可等待”，定为常规级，按排期处理；影响为团队且紧急度为“影响部分工作”，定为较高级，当班内响应。分级示例仅作演示，组织应结合自身业务定义每一档的具体含义。
请求单的状态流转建议保持简洁，每个状态都要有明确的完成标志：
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 受理 | 请求人提交的表单或转单信息 | 核对必填字段，补录缺失信息 | 字段完整的请求单 | 必填字段无空缺，请求类型已选定 |
| 分派 | 已受理的请求单 | 按类型与优先级确定处理人 | 已指派处理人的请求单 | 处理人已确认接单 |
| 处理 | 已分派的请求单 | 一线处理或转二线，记录处理动作 | 处理记录与解决方案 | 处理人提交解决说明 |
| 待确认 | 解决方案 | 请求人验证结果 | 确认或退回意见 | 请求人明确回复确认或退回 |
| 关闭 | 请求人确认 | 补充关闭原因与知识条目 | 已关闭请求单 | 关闭原因已填，可复用经验已记录 |
在工具层面，这套“登记—分派—处理—确认—关闭”的流转需要有承载请求单的载体。ONES Desk 面向企业服务与协作场景，提供统一门户集中接收工单，支持自定义字段与处理流程，可用于内部支持、IT 服务等场景。受理岗在门户中查看新请求、补齐字段并指派处理人，请求人则能通过工单对话了解处理进度，这与上述状态流转的落地方式一致。
谁来做：服务台、一线、二线与请求人的角色分工
流程能否跑通，取决于每个环节是否有人明确负责。角色划分的原则是：每个请求单在任一时刻只有一个当前责任人，转派时必须完成交接而不是简单丢单。
| 角色 | 职责 | 交付物 | 时限 |
|---|---|---|---|
| 服务台/受理岗 | 登记、初判、分派、跟踪、回访 | 字段完整的请求单、分派记录、回访记录 | 新请求当班内完成受理与分派 |
| 一线支持 | 处理常见请求，沉淀知识条目 | 处理记录、解决方案、知识条目 | 按优先级约定的响应与解决时限 |
| 二线专业组 | 接收超出范围的请求，说明退回理由 | 处理结论或带理由的退回单 | 接单确认与退回均需在约定时限内完成 |
| 请求人 | 补充信息、验收确认、关闭确认 | 补充说明、确认或退回意见 | 收到待确认通知后及时回复 |
服务台是受理环节的中枢。它不负责解决所有问题，但要保证每个请求都被登记、被分派、被跟踪。初判时，服务台依据请求类型和影响范围决定直接交一线还是转二线；对描述不清的请求，先联系请求人补齐信息再分派，避免处理人反复来回询问。
一线支持承担常见请求的直接处理。处理完成后，除了填写解决说明，还应判断这条经验是否值得沉淀为知识条目。可复用的判断标准是：同类请求是否重复出现、解决步骤是否稳定、是否需要特定权限或工具。满足其中两条以上，就应整理成条目，供后续受理时直接引用。
二线专业组接收超出一线范围的请求。接收时要确认请求单信息足以支撑判断；若信息不足或不属于本组范围，应带明确理由退回，而不是让请求单停留在无人处理的状态。退回理由要写清缺什么信息、应由哪个组接手，服务台据此重新分派。
请求人的动作同样影响流程效率。信息补充越及时，初判越准确；验收确认越明确，关闭越干脆。对长期不回复确认的请求单，应设定自动提醒和到期处理规则，避免请求单无限挂起。
升级与转派需要设定触发条件与时限。常见触发条件包括：超过约定响应时限仍未接单、处理中发现影响范围扩大、请求涉及多个专业组。转派时，原处理人需在请求单中写明已尝试的动作和转派原因，接收方确认接单后责任才转移。
一个完整受理示例：从提交到关闭
以下为演示情景，用于说明字段填写与分级判断，不代表任何真实组织的数据。
原始描述来自一条私聊消息：“财务共享中心的报表系统打不开了，月底结账要用，很急。”这条描述缺少部门、联系方式和影响范围，受理岗需要补齐。
补齐后的请求单字段：请求人为财务共享中心核算岗员工，部门为财务共享中心，联系方式为分机与IM；请求类型为“应用系统故障”；影响范围为“部门内约二十人无法生成报表”；期望时间为当天下午；描述补充了报错截图和访问地址；附件为截图。
分级判断：影响范围为部门级，紧急度为“影响月末结账的关键工作”，定为较高级，当班内响应并优先分派。分派对象为应用支持一线；一线复现后判断为权限配置问题，超出常见处理范围，转二线系统组，并在请求单中写明已尝试的排查动作。
二线系统组接单后修复权限配置，提交解决说明；请求人验证报表可正常生成，回复确认；受理岗关闭请求单，关闭原因填写“权限配置修复”，并将“报表系统权限异常的自查与修复步骤”整理为知识条目，供后续同类请求直接引用。
这个示例的关键在于：每个环节都留下了可查的记录，转派有理由，关闭有确认，经验有沉淀。缺少任何一环，请求单的可追溯性都会下降。
上线前准备与受理机制落地
流程设计完成后，落地需要按顺序完成以下准备事项。推进顺序建议先定规则、再收渠道、后配机制，最后小范围试运行。
| 事项 | 负责人 | 完成标志 |
|---|---|---|
| 请求类型目录与优先级规则定稿 | 服务台负责人 | 类型目录与分级说明经相关团队确认并发布 |
| 受理渠道收敛与对外告知 | 服务台负责人与内部沟通岗 | 全员收到新入口说明，旧渠道明确转单方式 |
| 值班表与分派规则设置 | 一线与二线各组负责人 | 值班表覆盖工作时段，分派规则可执行 |
| 超时提醒设置 | 服务台负责人 | 响应与处理超时均有提醒对象和提醒方式 |
| 试运行范围与观察周期确定 | 项目负责人 | 选定试点部门，明确观察周期与复盘时间 |
渠道收敛是最容易被低估的一步。旧渠道不能简单关停，要给出过渡期的转单方式，并反复告知。试运行阶段建议选择一个请求量适中、配合度较高的部门，观察周期覆盖至少一个完整业务周期，再根据实际数据调整字段和分级规则。
在承载方式上，ONES Desk 支持快速配置表单并分享填写链接，让请求人在门户提单，也支持按企业自身工作方式自定义工作流。对于希望把入口、字段和流转放在同一处的团队，可以先用表单和流程配置搭出试运行版本，再根据观察结果调整。
怎么判断受理做得好：指标与完成检查
受理机制是否真正运转，不能只看请求单数量，要看几个能反映流程健康度的指标。指标口径需组织自行定义并保持前后一致，以下为通用参考。
| 指标 | 口径说明 | 观察重点 |
|---|---|---|
| 受理及时率 | 在约定时限内完成受理与分派的请求单占比 | 入口是否畅通、受理岗是否够用 |
| 一次解决率 | 未经转派即由首个处理人解决的请求单占比 | 初判准确度与一线能力 |
| 退回率 | 被二线退回的请求单占比 | 分派规则与字段完整度 |
| 平均首次响应时间 | 从提交到首次有处理人回应的平均时长 | 请求人的实际等待感受 |
字段完整性通过抽样复核检查。方法是从各请求类型中随机抽取一定数量的请求单，逐项核对必填字段是否有空缺、描述是否足以支撑初判、附件是否与问题相关。抽样应覆盖不同受理岗和不同时间段，避免只看到表现最好的一面。
常见失效信号有三类：请求绕开入口，说明入口不便或旧渠道未真正收口；请求单长期挂起，说明待确认环节缺少提醒与到期规则；退回无理由，说明二线交接责任不清。发现这些信号时，应回到对应环节修正规则，而不是靠反复提醒维持。
完成检查清单与阻断项：
- 统一入口已发布，旧渠道有明确转单方式——未完成则阻断上线。
- 必填字段清单已定稿并写入表单——未完成则阻断上线。
- 优先级分级规则有示例且经相关团队确认——未完成则阻断上线。
- 四类角色的职责与时限已书面明确——未完成则阻断上线。
- 升级与转派触发条件已设定——未完成则暂缓试运行。
- 超时提醒与待确认到期规则已配置——未完成则暂缓试运行。
- 指标口径已定义并指定统计责任人——可在试运行期间补齐。
- 抽样复核方法与频次已确定——可在试运行期间补齐。
受理环节做扎实后，事件恢复与根因治理属于后续主题，可在请求单关闭后按需衔接。就受理本身而言，入口统一、字段稳定、分级清晰、责任到人、指标可查，这五点同时成立，流程才算真正运转起来。
常见问题
请求人一直不回复确认，请求单能直接关闭吗？
建议在流程中预设到期处理规则，而不是由受理岗临时决定。常见做法是：请求单进入待确认状态后按约定频次提醒请求人，超过约定时限仍未回复的，由受理岗在请求单中记录提醒次数与时间，按组织事先确认的规则处理，例如标记为“默认确认关闭”并注明依据。规则要提前告知全员，避免关闭动作引发争议。若请求涉及关键业务系统，可要求必须由请求人明确确认，不适用默认关闭。
二线退回请求单时，怎样写理由才能减少反复转派？
退回理由要回答三个问题：缺什么信息、为什么本组无法处理、建议由哪个组接手。例如写明“缺少报错截图与访问地址，无法判断故障范围；该请求属于网络权限配置，建议转网络组”。服务台据此补齐信息或重新分派，接收方也能提前判断是否接得住。只写“不属于本组”会让请求单在组间来回流转，退回率也会失去参考价值。
试运行期间发现请求仍然绕开新入口，应该先改流程还是先加强通知？
先判断绕开的原因。如果是入口本身不便，例如表单字段过多、提交路径太深，应优先简化表单和入口，再配合通知；如果入口可用但旧渠道没有真正收口，则需要明确旧渠道的转单方式并反复告知。两类原因常同时存在，建议在试运行复盘中分别统计绕开入口的请求来源，按来源占比决定先改哪一项，避免只靠反复提醒维持。
请求类型目录应该做多细？
以能支撑分派和统计为准。类型过粗，分派时仍需人工判断，统计也看不出问题集中在哪里；类型过细，请求人难以选择，受理岗还要频繁改分类。可先按业务对象和常见处理路径划分一级类型，例如账号与权限、应用系统、办公设备、网络访问，再在需要时补充二级类型。试运行一个完整业务周期后，根据实际请求分布和退回情况调整，类型目录的变更同样要同步更新统计口径。
用 ONES Desk 承载受理流程时，哪些环节可以直接配置，哪些仍需线下约定？
ONES Desk 提供统一门户集中接收工单，支持自定义字段与处理流程，也支持快速配置表单并分享填写链接，请求人可在门户提单，处理过程中可直接对话了解进度。受理岗的登记、分派、状态流转和请求人确认可以放在同一处承载。角色职责边界、升级触发条件、退回理由的写法以及指标口径，属于组织内部约定，需要在流程文件中明确，工具配置只是把这些约定固化下来。
