内部服务范围约定要解决的是“谁可以提、提什么、由谁接、多久回应、做到什么程度、什么不做”这些具体问题。制定时先划定服务对象与请求类型，再为每类服务写明受理条件、交付内容、响应与解决时限、责任角色和排除项，经服务提供方与业务方共同评审后发布，并约定复核周期。本文给出可执行的制定步骤、条目字段表、角色分工和发布前检查清单。
要点总览（TL;DR）
- 制定内部服务范围约定按五步推进：划定服务对象与请求入口、划分服务类别、逐条编写服务条目、组织评审与发布、设定复核与变更机制。
- 每条服务写清九个字段：服务名称、适用对象、请求方式、受理条件、交付内容、响应时限、解决时限、责任角色、排除项；受理条件写正向可判定条件，排除项写明确不纳入的事项。
- 服务提供方起草条目，业务方代表补充场景与优先级，服务台校验入口与受理条件，双方负责人对时限调整、范围扩大等分歧事项共同批准。
- 发布前逐项核对条目完整性、受理条件可判定、时限可执行、责任角色落到岗位、双方达成一致、版本与渠道确定、复核与变更入口写明。
- 范围约定发布后需要承载服务条目、请求流转与变更记录，ONES Desk 支持自定义工单属性与工单内容、灵活调整工作流，可用于 IT 服务与内部支持场景。
范围约定先定哪几件事：核心答案与操作步骤
制定内部服务范围约定，整体路径可以概括为五步：划定服务对象与请求入口、划分服务类别、逐条编写服务条目、组织评审与发布、设定复核与变更机制。每一步都有明确的输入、动作和输出，完成标志是下一步能够直接使用上一步的产物。按这个顺序推进，可以避免先写细节后补框架导致的返工。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 划定服务对象与请求入口 | 组织架构、现有服务受理记录、各部门常见请求 | 列出服务覆盖的人群范围（如全员、某事业部、某办公区），确认请求从哪些入口提交（门户、表单、邮件、服务台电话） | 服务对象清单与请求入口说明 | 每个服务对象都能对应到至少一个明确入口 |
| 2. 划分服务类别 | 服务对象清单、历史请求数据 | 把请求归并为若干服务类别（如账号与权限、办公设备、软件与工具、网络接入），每类下设具体服务条目 | 服务类别目录 | 类别之间边界清晰，历史请求能归入某一类 |
| 3. 编写服务条目 | 服务类别目录、现有处理经验 | 按统一字段为每条服务填写受理条件、交付内容、响应与解决时限、责任角色、排除项 | 服务条目表 | 每条服务字段齐全，受理条件可判定 |
| 4. 评审与发布 | 服务条目表草稿 | 组织服务提供方与业务方共同评审，处理分歧，确定版本号与发布渠道 | 评审通过的正式版本 | 双方确认签字或书面认可，版本可追溯 |
| 5. 复核与变更 | 正式版本、运行中的请求数据与反馈 | 按约定周期复核条目有效性，记录变更触发条件与变更入口 | 复核记录与更新版本 | 复核周期、责任人、变更入口均已写明 |
五步中，第1步和第2步决定约定的覆盖面，第3步决定约定的可执行程度，第4步决定约定是否被双方认可，第5步决定约定能否长期有效。实际推进时，第1、2步可以合并为一次工作坊完成，第3步通常需要服务提供方先出草稿，再交业务方补充需求侧信息。
服务条目怎么写：字段与判定规则
服务条目写到什么颗粒度，取决于读者能否据此判断“这件事归不归我提、提了之后会发生什么”。一条服务对应一个可独立受理和交付的事项，不要把多个动作打包成一条，也不要把一条服务拆成只有内部才理解的细碎步骤。建议统一使用以下字段。
| 字段 | 填写要求 | 示例写法 |
|---|---|---|
| 服务名称 | 用业务方看得懂的动作描述，避免内部术语 | 新员工账号开通 |
| 适用对象 | 写明人群范围或部门范围 | 入职当天的正式员工 |
| 请求方式 | 写明入口与需要提交的信息 | 通过服务门户提交，附入职通知单编号 |
| 受理条件 | 写成可判定的正向条件，满足即受理 | 已办理入职手续且提交信息完整 |
| 交付内容 | 写明交付物或交付结果 | 域账号、邮箱、办公系统基础权限开通并通知本人 |
| 响应时限 | 从受理到首次回应的时长 | 受理后4个工作小时内确认 |
| 解决时限 | 从受理到交付完成的时长 | 受理后1个工作日内完成开通 |
| 责任角色 | 落到具体岗位，不写部门名称了事 | IT 服务台受理，系统管理员执行 |
| 排除项 | 写明明确不纳入本条目的事项 | 特殊业务系统的权限申请不在本条范围内 |
受理条件与排除项的区别需要特别注意。受理条件回答“满足什么就能提”，写成正向、可核对的判断句；排除项回答“哪些情况不归这条服务管”，写成明确的否定范围。两者不能互相替代：只写排除项而不写受理条件，业务方无法判断自己是否符合；只写受理条件而不写排除项，边界事项会被反复提交。
时限要按响应与解决分开表述。响应时限约束的是服务方多快给出第一次明确回应，解决时限约束的是多快完成交付。两者混为一条“X 小时内处理”，会让业务方误以为 X 小时内一定完成，也会让服务方在需要排期时缺少说明依据。对于依赖外部供应商或需要多部门配合的服务，可以在解决时限后补充前置条件说明。
常见歧义及消解方式：服务名称过于笼统（如“IT 支持”），应拆到可受理的具体事项；适用对象写“全体员工”但实际只覆盖部分办公区，应写明范围；交付内容写“处理完成”，应改为可观察的结果；责任角色写“IT 部门”，应落到受理岗与执行岗。填写时可以让一位不熟悉该服务的同事试读，若其无法判断能否提交，说明条目还需要细化。
谁定、谁审、谁维护：角色及交付物
范围约定不宜由单一部门拍板。服务提供方最了解交付能力与约束，业务方最了解请求场景与优先级，受理角色掌握实际请求分布。三方共同参与，约定才既有约束力又贴近使用。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 服务提供方（如 IT 运维负责人） | 起草服务条目，确认交付能力、时限可行性与排除项 | 服务条目草稿、时限测算依据 |
| 业务方代表（如各部门接口人） | 补充请求场景、提出优先级与覆盖范围意见，确认条目可理解 | 需求侧意见清单、评审确认记录 |
| 服务台或受理角色 | 提供历史请求分布，校验请求入口与受理条件是否可操作 | 请求分类统计、入口与表单说明 |
| 评审决策方（如双方负责人） | 对分歧事项作出决定，批准发布 | 评审结论、发布批准记录 |
| 约定维护人 | 按周期组织复核，受理变更申请，维护版本记录 | 复核记录、变更日志、更新版本 |
评审决策方式建议在约定中写明：常规条目由服务提供方与业务方代表确认即可，涉及时限调整、范围扩大或排除项变化的条目，由双方负责人共同批准。发布后的维护责任应落到具体岗位，变更触发条件可以包括：服务内容或交付方式发生变化、请求量或请求类型明显变化、复核周期到期、出现反复争议的边界事项。每次变更保留版本号和生效日期，便于回溯。
示例：一份内部 IT 支持范围约定如何落地
以下为演示情景，用于说明字段填写与边界划分方式，不代表任何真实组织的实际约定。
| 字段 | 账号与权限 | 办公设备 | 软件安装 |
|---|---|---|---|
| 服务名称 | 新员工账号开通 | 办公电脑领用与更换 | 标准办公软件安装 |
| 适用对象 | 入职当天的正式员工 | 在职员工及经批准的实习生 | 在职员工 |
| 请求方式 | 服务门户提交，附入职通知单编号 | 服务门户提交，说明使用场景与设备类型 | 服务门户提交，注明软件名称与版本 |
| 受理条件 | 已办理入职手续，提交信息完整 | 现有设备故障无法修复，或岗位需要新增设备 | 所申请软件在标准软件清单内 |
| 交付内容 | 域账号、邮箱、基础办公系统权限开通并通知本人 | 设备发放、基础系统安装并完成领用登记 | 软件安装完成并可正常启动 |
| 响应时限 | 受理后4个工作小时内确认 | 受理后1个工作日内确认方案 | 受理后4个工作小时内确认 |
| 解决时限 | 受理后1个工作日内完成 | 有库存时2个工作日内发放；无库存时告知预计到货时间 | 受理后1个工作日内完成 |
| 责任角色 | 服务台受理，系统管理员执行 | 服务台受理，设备管理员执行 | 服务台受理，桌面支持岗执行 |
| 排除项 | 特殊业务系统权限、跨组织账号不在本条范围 | 设备硬件维修的技术处置不纳入本条，按维修流程另行处理 | 清单外软件、需要采购授权的商业软件不在本条范围 |
从示例可以归纳几条可迁移的规律：交付内容写成可观察的结果，而不是“处理完成”；解决时限遇到资源约束时，把约束条件写进条目，而不是模糊承诺；排除项指向另一条明确流程，让业务方知道下一步去哪里，而不是简单拒绝。设备维修这类技术处置事项，在范围约定中标注为不纳入，并说明其归属流程，可以避免服务台与维修岗之间的反复转交。
范围约定发布后，服务条目、请求流转和变更记录需要有承载方式。ONES Desk 可用于 IT 服务、内部支持等场景，支持自定义工单属性与工单内容以适配不同角色的收集需求，并可灵活调整工作流；团队可以在其中集中管理工单状态、处理进度和责任分工。将约定中的服务条目对应为可提交的请求类型，把受理条件写进表单必填项，把响应与解决时限作为跟踪依据，能够让约定从文档变成日常可核对的动作。
发布前的完成检查
范围约定达到可发布状态，需要逐项核对以下内容。建议由维护人对照清单自查，再由业务方代表抽查确认。
- 条目完整性：每条服务均填写服务名称、适用对象、请求方式、受理条件、交付内容、响应时限、解决时限、责任角色、排除项，无空缺字段。
- 受理条件可判定：受理条件为正向判断句，业务方据此能自行判断是否符合，不依赖内部解释。
- 排除项明确：每条服务的排除项写明不纳入的事项，并尽可能指向对应的处理流程。
- 时限可执行：响应时限与解决时限分开填写，时限值与实际处理能力匹配，资源约束已在前置条件中说明。
- 责任角色落到岗位：受理岗与执行岗分别写明，不出现只有部门名称的情况。
- 双方达成一致：服务提供方与业务方代表完成评审，分歧事项已有结论并记录。
- 版本与渠道确定：版本号、生效日期、发布渠道（门户、内网文档、邮件通知）均已明确。
- 复核与变更入口写明：复核周期、维护责任人、变更申请入口在约定中可见。
清单全部通过后即可发布。发布后按约定周期复核，重点检查请求分布是否与条目划分匹配、时限是否频繁触发前置条件说明、排除项是否出现反复争议。复核结果形成更新版本，旧版本保留备查，范围约定才能随着服务内容变化持续有效。
常见问题
范围约定发布后，业务方仍然反复提交排除项里的请求，怎么处理？
先检查排除项是否写清了归属流程。只写“不纳入本条范围”，业务方无法判断下一步去哪里，容易反复提交。可以在排除项后补充指向的处理入口，例如“设备硬件维修的技术处置不纳入本条，按维修流程另行处理”。同时核对请求入口的选项设置，把排除事项对应的请求类型放在显眼位置，减少误选。若某类排除事项持续高频出现，说明它可能已经成为实际服务需求，应在复核时评估是否新增为正式服务条目。
响应时限和解决时限在实际执行中经常被混用，约定里怎么避免？
在字段定义中把两者分开表述：响应时限约束从受理到首次明确回应的时长，解决时限约束从受理到交付完成的时长。条目里分别填写，不合并成“X 小时内处理”。对于依赖外部供应商或多部门配合的服务，在解决时限后补充前置条件说明，例如库存、审批或排期依赖。发布后统计时也分开记录首次回应时间和交付完成时间，用数据判断是响应环节还是交付环节需要调整。
服务条目应该拆到多细？拆得太细维护成本高，太粗又无法判定。
判断标准是业务方能否据此决定“这件事归不归我提、提了之后会发生什么”。一条服务对应一个可独立受理和交付的事项。像“IT 支持”这类笼统名称应拆到可受理的具体事项，例如账号开通、设备领用、软件安装；而只有内部才理解的细碎操作步骤不必单列。可以用试读法检验：让一位不熟悉该服务的同事阅读条目，若其无法判断能否提交，说明还需要细化；若多条服务共用同一套受理条件和交付方式，可以考虑合并。
范围约定的复核周期怎么定，复核时重点看什么？
复核周期按服务变化频率设定，变化快的服务类别缩短周期，稳定的类别可以放长。复核时重点看三件事：请求分布是否与条目划分匹配，是否存在大量请求落在条目之外；时限是否频繁触发前置条件说明，说明时限值与实际能力不匹配；排除项是否出现反复争议的边界事项。复核结果形成更新版本，保留版本号和生效日期，旧版本备查。变更触发条件也可以写进约定，例如服务内容变化、请求类型明显变化、复核周期到期。
范围约定和事件恢复、根因治理是什么关系，边界怎么划？
范围约定回答的是“哪些事项纳入服务、由谁受理、按什么条件交付”，属于服务目录层面的约定；事件恢复和根因治理属于事件发生后的处理流程，关注如何尽快恢复以及如何消除根因。两者在文档上可以衔接：范围约定中的排除项指向对应流程，服务条目中的解决时限作为事件处理的跟踪依据。本文聚焦范围约定的制定方法，事件恢复流程与根因治理不在本文展开。
