内部支持协调要跑起来，关键在三件事：请求统一从一个入口进来，每类请求有明确的唯一责任人和交接规则，处理过程用一张工单留痕。本文按受理、分级、派单、交接、协调、验收的顺序，给出可直接套用的入口清单、优先级判定表、角色分工表、工单字段模板和协调节奏表，适用于内部服务与 IT 支持场景。
要点总览（TL;DR）
- 内部支持协调从统一受理入口开始：把群聊、邮件、口头请求都收拢到同一套工单记录，再按影响范围与紧急度划分 P1–P4。
- 每类请求指定唯一处理人作为闭环责任人，交接时必须补齐已完成动作、当前判断、所需交付物和期望时间四项信息。
- 工单字段覆盖请求人、影响范围、优先级、责任人、依赖方、当前状态、处理记录与关闭结论，跨团队依赖作为独立字段挂到工单上。
- 协调节奏由每日站会、每周协调会、看板巡检和卡点上报组成，看板至少保留按状态和按优先级两个视图。
- 机制运行四到六周后，用各优先级实际处理时长、等待依赖停留时间、重复请求类型占比三类数据判断是否调整。
先定受理入口与请求分级
协调混乱通常从入口开始：有人在群里喊一句，有人私聊，有人发邮件，结果同一件事被重复处理，或者谁都没接。第一步是把请求收拢到有限入口，并给每个入口规定适用请求类型。
统一受理入口的三种形态与取舍
| 入口形态 | 适用情况 | 优点 | 需要配套的条件 |
|---|---|---|---|
| 服务台门户或工单表单 | 请求量大、类型稳定，需要统计与追溯 | 字段统一，自动生成工单编号，便于查询和复盘 | 表单按请求类型分版，填写项控制在必要范围 |
| 群内固定指令或机器人 | 请求零散、提交人习惯在即时通讯工具里提问 | 提交门槛低，响应快 | 指令格式固定，能自动转成工单并回填编号 |
| 邮件转工单 | 对外接口或习惯邮件沟通的部门 | 不改变提交人习惯 | 指定收件地址，由受理人统一录入或自动转入 |
三种形态可以并存，但必须约定：任何入口最终都落到同一套工单记录里，群内口头请求也要补录。入口清单要写清每个入口负责哪类请求、由谁值守、非工作时间的请求如何处理。
按影响范围与紧急度划分优先级
优先级用两个维度判断，避免“谁喊得响谁先处理”。影响范围看受影响的用户数、业务是否中断、是否有合规或安全风险；紧急度看是否已有可接受的替代方案、时间窗口有多紧。
| 优先级 | 影响范围 | 紧急度 | 判定示例 |
|---|---|---|---|
| P1 | 多部门业务中断，或涉及安全与合规风险 | 无替代方案，须立即处理 | 办公区网络整体不可用，财务月结无法进行 |
| P2 | 单个部门或关键岗位受影响 | 当天内需要恢复 | 某部门共享盘无法访问，影响合同归档 |
| P3 | 个别用户受影响，有替代方案 | 可在约定工作日内处理 | 单个员工申请软件安装权限 |
| P4 | 咨询、建议或体验优化类 | 无明确时限 | 询问某系统报表字段含义 |
分级由一线受理人初判，处理人可以在接单后调整并注明理由。本文范围是请求的受理、协调与交接；已经发生的服务中断如何恢复、故障根因如何治理，属于事件与问题管理流程，应在请求分级后转入对应流程，不在本文展开。
责任人与交接规则怎么定
“谁都在管、谁都不闭环”的根源是角色不清。每类请求至少要有三个角色：一线受理人负责接单、初判和派发；处理人负责实际解决并给出关闭结论；审批人只在涉及权限、费用或跨部门资源时介入。
按请求类型指定角色
| 请求类型 | 一线受理人 | 处理人 | 审批人 |
|---|---|---|---|
| 账号与权限 | IT 服务台值班 | 对应系统管理员 | 申请人的部门负责人 |
| 办公设备与软件 | IT 服务台值班 | 桌面支持工程师 | 通常无需审批，超标准配置时由 IT 负责人审批 |
| 业务系统使用咨询 | 服务台按系统分派 | 系统归属团队的业务支持人 | 无需审批 |
| 跨部门数据或流程配合 | 发起方服务台 | 牵头部门指定负责人 | 双方部门负责人 |
每类请求只设一个处理人作为闭环责任人，协作方可以多人，但工单上必须能看出谁对结果负责。
交接的触发条件与必带信息
交接发生在三种情况：请求超出当前处理人职责范围、需要其他团队提供依赖、处理人休假或离岗。触发交接时，工单上必须补齐四项信息：已完成的排查或处理动作、当前判断、需要对方交付的具体内容、期望完成时间。缺少这四项的交接视为无效，接收方可以退回。
升级路径与时限
升级分两级：处理人无法在承诺时间内完成时，升级到其直属负责人协调资源；跨团队依赖超过约定时限未响应时，升级到双方负责人在协调会上处理。时限按优先级设定，例如 P1 在 30 分钟内升级，P2 在 4 小时内升级，P3 在 2 个工作日内升级。这些时限是实践建议，需要结合团队值班安排确定，并在上线后按实际数据调整。
工单字段与处理流程模板
工单是协调的记录载体，字段设计的目标是让接手的人不用再问一遍。以下字段结构可以直接套用。
必备字段
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 请求人及所属部门 | 提交时必填 | 确认身份与影响范围 |
| 请求描述 | 现象、发生时间、已尝试的操作 | 减少来回追问 |
| 影响范围 | 受影响人数、业务是否中断 | 优先级判定依据 |
| 优先级 | P1–P4，附判定理由 | 排期与升级依据 |
| 责任人 | 当前处理人，唯一 | 闭环责任 |
| 依赖方 | 需要配合的团队、对接人、所需交付物 | 跨团队协调显性化 |
| 当前状态 | 按阶段流转 | 进度可见 |
| 处理记录 | 按时间追加动作与结论 | 交接与复盘依据 |
| 关闭结论 | 解决方式、遗留事项、请求人确认 | 验收与知识沉淀 |
处理阶段与进出条件
| 阶段 | 进入条件 | 退出条件 |
|---|---|---|
| 待受理 | 请求已提交 | 受理人完成初判并填写优先级 |
| 处理中 | 已指定处理人 | 问题解决，或需要依赖方介入 |
| 等待依赖 | 已记录依赖方与所需交付物 | 依赖方交付，或触发升级 |
| 待确认 | 处理人给出解决方案 | 请求人确认结果 |
| 已关闭 | 请求人确认，关闭结论填写完整 | — |
跨团队依赖不要写在处理记录的正文里，而是作为独立字段挂到工单上，注明对接人和期望时间，这样在看板上能直接筛出“等待依赖”的工单。ONES Desk 面向内部支持与跨团队协作场景，支持统一受理、自定义字段与处理流程，工单可集中管理状态、处理进度和责任分工；当请求需要研发团队跟进时，工单还能关联到 ONES Project 的工作项持续跟踪，处理经验可沉淀到 ONES Wiki。字段的具体配置按团队实际请求类型设计。
协调节奏：例会、看板与卡点处理
规则定好之后，需要固定动作让协调持续发生。节奏表包含三类动作：例会、看板巡检、卡点上报。
| 动作 | 频率 | 主持人 | 看什么 | 输出 |
|---|---|---|---|---|
| 每日站会 | 每工作日 15 分钟 | 服务台负责人 | P1/P2 工单进展、当日到期事项、新出现的依赖 | 当日处理安排与升级名单 |
| 每周协调会 | 每周一次，30–45 分钟 | IT 或服务负责人 | 等待依赖超过时限的工单、积压趋势、重复出现的请求类型 | 跨团队协调结论与责任人 |
| 看板巡检 | 每日或隔日 | 值班受理人 | 按状态和优先级分组的工单列表 | 超时工单提醒与重新派单 |
| 卡点上报 | 随时触发 | 处理人发起 | 依赖方超时未响应、需要资源调配 | 升级记录与临时协调安排 |
看板分组建议至少保留两个视图：按状态分组，用于发现积压在哪一阶段；按优先级分组，用于确认高优先级请求是否都在推进。卡点上报的触发条件写进规则，例如依赖方超过约定时限未响应、同一请求被退回两次以上，触发后由受理人在协调会上提出，避免在群里反复催促。
一个完整示例：跨部门账号权限请求
以下为演示情景，用于说明各字段与角色如何组合使用。
市场部员工需要开通某业务系统的数据导出权限。请求通过服务台表单提交，填写请求人、所属部门、目标系统、所需权限范围和用途。受理人初判：影响范围为单人、有临时替代方案，定为 P3；因涉及数据权限，审批人为市场部负责人。
受理人将工单派给该系统管理员，状态进入“处理中”。系统管理员核查后发现导出权限依赖数据平台侧的账号开通，于是在依赖方字段填写数据平台对接人和所需交付物，状态转为“等待依赖”。约定时限内数据平台未响应，工单触发升级，在每周协调会上由双方负责人确认开通时间。
数据平台完成开通后，系统管理员在工单上追加处理记录，给出关闭结论：已开通导出权限，权限范围与申请一致，有效期按季度复核。状态转为“待确认”，请求人确认可用后工单关闭。整个过程在工单上留下受理、分级、派单、依赖、升级、关闭的完整记录，后续同类请求可以直接参照处理。
上线前的准备与完成检查
机制上线前，先确认四件事：入口清单已发布且每个入口有人值守；每类请求的角色分工表已确认到人；工单字段与阶段流转已配置完成；提交人和处理人做过一次填写与流转的说明。培训不必做成大课，用一条示例工单走一遍流程即可。
完成检查表
| 检查项 | 可观察的完成标志 |
|---|---|
| 请求单入口 | 抽查一周内的请求，均能在工单系统中找到对应记录，群内口头请求已补录 |
| 分级有依据 | 工单优先级字段附有判定理由，P1/P2 的判定与影响范围描述一致 |
| 责任唯一 | 每张进行中的工单只有一个当前处理人 |
| 交接留痕 | 发生交接的工单包含已完成动作、当前判断、所需交付物和期望时间 |
| 积压可见 | 看板能按状态筛出等待依赖和超时工单，协调会有对应议题 |
| 关闭有结论 | 已关闭工单均填写关闭结论，并有请求人确认记录 |
机制运行四到六周后，用三类数据判断是否需要调整：各优先级的实际处理时长与约定时限的差距、等待依赖阶段的平均停留时间、重复出现的请求类型占比。处理时长普遍超出时限，说明分级标准或值班安排需要调整；等待依赖停留时间过长，说明依赖方约定或升级时限需要收紧；某类请求反复出现，可以考虑转为自助指引或标准化流程。调整时同步更新入口清单和角色分工表，保持规则与工单配置一致。
常见问题
内部支持请求量不大，还需要专门的服务台工具吗？
请求量小的时候，可以先从表单加固定收件地址起步，关键是保证所有请求最终落到同一套记录里，能查到谁在处理、卡在哪一步。当请求类型变多、跨团队依赖频繁、需要按优先级排期时，再考虑引入工单系统承载字段配置、状态流转和看板视图。判断依据是协调成本：如果受理人每天要花大量时间在群里追问进度、手工汇总，就说明记录载体需要升级。
一线受理人初判的优先级，处理人不认同怎么办？
处理人可以在接单后调整优先级，但要在工单上注明调整理由，例如补充了影响范围信息或发现了替代方案。调整记录保留在原工单中，便于后续复盘分级标准是否合理。如果同一类请求反复出现初判与调整不一致，说明判定表需要补充示例，而不是靠个人经验临时判断。
跨团队依赖的对方一直不响应，除了升级还有别的办法吗？
升级是兜底手段，日常更有效的是把依赖显性化：在工单上写明对接人、所需交付物和期望时间，让等待依赖的工单在看板上直接可见。协调会上只讨论超时未响应的依赖，避免变成逐条催办。如果某类依赖长期超时，需要回到规则层面，重新约定该团队的响应时限或调整请求分流方式。
工单关闭后，同类请求还会反复出现，怎么处理？
先统计重复出现的请求类型占比。占比高的类型通常有两种处理方向：一是转为自助指引或标准化操作说明，让请求人自行完成；二是把处理经验沉淀到知识库，受理时直接引用。ONES Desk 的工单可关联到 ONES Wiki 页面记录和沉淀服务经验，具体做法按团队的知识管理习惯安排。
协调机制上线后，怎么判断分级标准定得合不合理？
看各优先级的实际处理时长与约定时限的差距。如果 P1、P2 普遍超时，可能是分级过宽或值班资源不足；如果 P3、P4 长期积压，可能是低优先级请求缺少批量处理安排。等待依赖阶段的平均停留时间也是重要指标，停留过长说明依赖方约定或升级时限需要收紧。调整时同步更新判定表和工单配置，保持规则一致。
