内部服务范围约定的核心，是把“谁可以提、提什么、由谁接、按什么标准交付”写成一份可执行的边界文件，并让请求入口、工单字段和角色职责与这份文件保持一致。本文给出范围约定应包含的字段、从盘点到发布的起草步骤、各角色的交付物，以及一份可直接参照改写的示例和发布前检查清单。
要点总览（TL;DR）
- 内部服务范围约定要写清五类内容：服务对象、可受理服务项、请求入口、责任角色与交付口径、例外处理，其中不纳入事项必须写明转交去向。
- 起草按盘点请求、归并服务目录、确认责任与交付标准、划定不纳入事项、评审发布五步推进，每步都有明确输入和输出。
- 服务负责人对边界完整性负责，受理角色负责判断与转交，交付团队负责人确认交付可行性，请求方代表在试运行中反馈条目是否可识别。
- 约定生效的关键是入口选项、工单字段与服务目录保持一致，并通过固定复审和例外记录持续修订。
- 发布前用五项检查逐条核对，任何一项不通过都先修正再公布。
先定边界：内部服务范围约定要写清哪几类内容
一份能直接执行的范围约定，需要让请求方在提交前就能判断“这件事该不该找这个团队”，也让受理方在收到请求时能快速判断“接还是不接、接下来交给谁”。围绕这个目标，约定至少要覆盖五类内容：服务对象、可受理事项、请求入口、责任与交付口径、例外处理。
把这些内容组织成字段清单，比写成一段描述性文字更便于逐项核对和后续维护。建议的字段结构如下：
| 字段 | 要回答的问题 | 填写要求 |
|---|---|---|
| 服务对象与请求方范围 | 哪些部门、岗位或人员可以提出请求 | 写明覆盖范围与不在范围内的群体，避免口头默认 |
| 可受理服务项 | 具体能受理哪些事项 | 逐条列出并命名，粒度到请求方可以自行对号入座 |
| 不纳入事项 | 哪些请求不在本团队职责内 | 每条写明转交去向或建议渠道，避免只写“不受理” |
| 受理渠道与请求入口 | 通过什么方式提出请求 | 与服务项一一对应，明确唯一主入口 |
| 责任角色 | 每项由谁受理、谁交付、谁审批 | 写到岗位或角色，不写具体人名 |
| 交付口径 | 交付什么、达到什么标准算完成 | 用可观察的产物或状态描述，如开通完成、设备可用 |
| 响应与升级 | 多久响应、卡住时找谁 | 区分常规响应与升级路径，写明触发条件 |
| 例外条款 | 特殊情况如何处理 | 写明谁可以批准例外、例外如何记录 |
其中“不纳入事项”最容易被忽略，却直接决定约定是否好用。只写可受理范围，请求方遇到边界情况仍会凭感觉提交，受理方则要反复解释。把常见的不属于本团队的事项连同转交去向一起写出来，边界才完整。
交付口径要避免“及时处理”“尽快解决”这类无法判断的表述。可用的写法是描述完成状态，例如“账号开通并通知申请人可登录”“设备更换完成并完成旧设备回收登记”。响应时限如果暂时无法统一，可以先按服务项分组给出区间，并在试运行后修正。
从零起草的五个步骤
起草不必一次写全，可以按“先盘点、再归并、后定责、划边界、再发布”的顺序推进。每一步都有明确输入和输出，完成后即可进入下一步。
第一步：盘点现有请求来源与高频事项
输入是近一段时间内实际收到的请求记录，来源包括聊天群、邮件、电话、当面提出和已有工单系统。动作是把请求逐条摘出，按事项类型做初步归类，统计出现频次和提出方。输出是一张原始请求清单，完成标志是清单覆盖了主要来源渠道，且高频事项已经能看出大致分布。这一步的价值在于让范围约定建立在真实请求上，而不是凭印象罗列。
第二步：归并成服务目录条目并命名
输入是上一步的原始清单。动作是合并同类项，把表述不同但实质相同的请求归为一个服务项，并为每项起一个请求方看得懂的名称，例如“新员工账号开通”“办公电脑故障报修”“共享盘权限申请”。输出是服务目录初稿。完成标志是每个条目都能对应到具体请求，且条目之间没有明显重叠。命名时优先使用业务语言，避免内部术语。
第三步：逐项确认责任角色与交付标准
输入是服务目录初稿。动作是逐条与相关团队确认：谁受理、谁执行、交付什么、什么状态算完成、卡住时升级给谁。输出是带责任角色和交付口径的服务项表。完成标志是每个服务项都有明确的受理角色和交付角色，且交付标准可以被请求方判断。遇到无人认领的条目，要么指定角色，要么移入不纳入事项。
第四步：确定不纳入事项及转交去向
输入是盘点中识别出的、不属于本团队职责的请求，以及试运行中反复出现的边界争议。动作是逐条写明不纳入的原因和转交对象，例如转交行政、财务、信息安全或外部供应商。输出是不纳入事项清单。完成标志是每条不纳入事项都有可执行的下一步，请求方看到后知道该找谁。
第五步：评审发布并设定复审周期
输入是前三步形成的完整草案。动作是组织服务负责人、交付团队负责人和主要请求方代表评审，确认字段完整、口径一致，然后发布到请求方容易找到的位置。输出是正式发布的范围约定和版本记录。完成标志是评审意见已处理、发布位置已通知、复审周期和责任人已确定。复审周期可以按季度或半年设定，业务变化快的团队可缩短。
角色与交付物分工表
范围约定既是文件也是协作机制，需要明确谁写、谁用、谁维护。角色划分不必复杂，但要保证每个环节都有唯一责任人。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 服务负责人 | 牵头起草与发布，裁决服务项归属，主持复审 | 范围约定正式版本、版本记录、复审结论 |
| 服务台或受理角色 | 按约定接收请求，判断是否在范围内，完成分派或转交 | 受理记录、超范围请求的转交说明 |
| 交付团队负责人 | 确认本团队服务项的交付标准与责任角色，保障执行资源 | 服务项交付口径确认、升级路径联系人 |
| 请求方与业务对接人 | 按入口提交请求，反馈条目是否可识别、口径是否清楚 | 试运行反馈、边界争议案例 |
| 例外与升级裁决角色 | 处理超出约定或存在争议的请求，批准例外并记录 | 例外审批记录、约定修订建议 |
服务负责人和交付团队负责人可以是同一人兼任，但在条目较多的团队里分开更利于制衡：前者对边界完整性负责，后者对交付可行性负责。例外裁决角色建议由服务负责人的上一级或跨团队协调人担任，避免受理方既当执行者又当规则解释者。
请求方代表的参与常被低估。范围约定最终是给请求方用的，如果条目名称他们看不懂、入口他们找不到，约定就只是内部文档。试运行阶段收集请求方的反馈，比发布后再解释成本低得多。
示例：一份内部 IT 支持范围约定的片段
以下片段为演示情景，用于说明字段如何落到具体条目，实际填写时按本团队情况调整。
账号与权限类服务项
| 服务项 | 服务对象 | 受理渠道 | 责任角色 | 交付口径 |
|---|---|---|---|---|
| 新员工账号开通 | 已办理入职手续的正式员工 | 服务门户提交申请，附入职单号 | 服务台受理，系统管理员执行 | 账号创建完成并通知申请人首次登录方式 |
| 共享盘权限申请 | 本部门员工 | 服务门户提交，需直属主管审批 | 服务台受理，存储管理员执行 | 权限配置完成并通知申请人访问路径 |
办公设备类服务项的边界写法
设备类事项容易和资产管理、采购混在一起，写法上要把“支持动作”和“资产动作”分开。例如“办公电脑故障报修”的交付口径可写为“完成故障判断并恢复可用；需更换硬件的，登记更换需求并告知预计时间”，而设备采购、资产调拨则列入不纳入事项，转交行政部门。这样请求方知道报修找 IT，买新设备找行政。
不纳入事项及转交说明
- 办公用品领用：转交行政服务台。
- 软件采购合同审批：转交采购与法务流程。
- 个人手机及非公司设备维修：不纳入，建议联系设备厂商。
- 跨部门数据导出审批：转交信息安全归口角色。
例外情形的处理写法
例外条款要写明触发条件、批准人和记录方式。例如：“因业务紧急需要在非受理时段开通账号的，由申请人直属主管向服务负责人提出，服务负责人批准后执行，并在工单中记录例外原因与批准人。”例外记录本身就是后续修订约定的依据，出现频次高的例外应考虑转为正式服务项。
让约定真正生效：入口、工单字段与评审机制
范围约定发布后最常见的失效方式，是请求仍然从聊天群和私信涌入，工单字段里看不出请求属于哪个服务项。要让约定生效，需要把文件里的条目和日常请求处理对齐。
请求入口与服务目录条目一一对应
每个服务项应有明确的提交入口，入口名称与服务项名称保持一致。请求方在门户上看到的选项，应当就是服务目录里的条目，避免出现“其他”这类兜底选项被大量使用。兜底选项过多，说明服务目录还没有覆盖真实请求，应回到盘点环节补充。
工单必填字段承载服务项与责任角色
工单中至少要有服务项、请求方、所属部门、期望完成时间等字段，服务项字段决定后续分派给哪个责任角色。字段设计要服务于判断，而不是越多越好：请求方填写的信息用于识别范围，受理方补充的信息用于记录处理过程。范围约定中的交付口径可以转化为工单的完成标准或关闭条件，让“完成”有统一判断依据。
在工具层面，ONES Desk 可用于内部支持等场景的工单统一受理、分派与跟踪，支持自定义工单属性与工单内容以适配不同收集场景，并提供统一门户集中接收工单。范围约定中的服务项和请求方信息，可以对应到工单字段中承载；当请求需要研发侧处理时，工单可关联到 ONES Project 的需求或缺陷工作项持续跟踪，处理经验也可关联 ONES Wiki 页面沉淀。服务目录条目本身的结构化维护是否由工具承担，选型时可作为核验点向厂商确认。
超范围请求的识别与转交动作
受理角色需要一套简单判断：请求是否对应某个服务项；不对应时，是否属于不纳入清单；两者都不符合，按例外处理。转交时要记录转交对象和时间，并回复请求方下一步找谁。定期统计超范围请求的类型，出现集中的新需求时，评估是否新增服务项。
定期评审与版本更新的触发条件
除了固定的复审周期，以下情况应触发临时修订：某类超范围请求连续出现、例外审批频次明显上升、组织调整导致责任角色变化、入口或工单字段发生变更。每次修订保留版本号和变更说明，并同步更新门户入口和工单选项，避免文件与实际入口脱节。
完成检查：这份约定是否可以发布
发布前逐项核对以下条目，全部通过再对外公布。任何一项不通过，都应视为阻断项，先修正再发布。
| 检查项 | 判断标准 | 不通过时的处理 |
|---|---|---|
| 服务项可被请求方识别 | 请一位非本团队的同事阅读条目，能说出自己遇到的情况对应哪一项 | 调整命名或补充说明，必要时拆分条目 |
| 每项都有责任角色与交付口径 | 逐条检查，无空白、无“待定” | 与交付团队确认后再发布 |
| 不纳入事项写明转交去向 | 每条都有具体转交对象或渠道 | 补充转交信息，删除无法转交的条目 |
| 入口与工单字段已同步 | 门户选项与工单字段和服务目录一致 | 先更新入口和字段，再发布文件 |
| 复审周期与责任人已确定 | 有明确周期、责任人和版本记录方式 | 指定责任人并写入文件 |
检查通过后，发布动作本身也要落实：通知主要请求方、在入口页面放置约定链接、向受理角色说明判断口径。约定不是一次性文档，试运行一个月后回看超范围请求和例外记录，通常就能发现需要补充的条目。把这次回看固定进复审机制，范围约定才能随业务变化保持可用。
常见问题
服务项暂时定不下交付时限，还能先发布范围约定吗？
可以先发布，但要把口径写清楚。交付时限无法统一时，按服务项分组给出区间，并在条目中注明“试运行后修正”。交付口径本身仍要描述完成状态，例如账号开通完成并通知申请人，避免用“尽快处理”这类无法判断的表述。试运行一个月后回看实际处理记录，再收紧时限。
业务部门坚持从聊天群提请求，范围约定怎么落地？
先保证入口足够省事：门户上的服务项名称与请求方日常说法一致，提交步骤尽量少。受理角色收到群里的请求时，统一回复入口链接并代为登记，让请求方感受到走入口不会更慢。同时统计群内请求的类型分布，如果集中在少数几项，说明入口设计或条目命名还有改进空间，应回到服务目录调整，而不是反复强调规定。
例外请求出现频繁，应该放宽范围还是新增服务项？
看例外记录的性质。同一类例外连续出现、且交付动作稳定，说明它已经是实际存在的服务需求，应评估转为正式服务项，补齐责任角色和交付口径。例外分散在不同事项、每次都需要单独协调的，更适合保留在例外通道，由裁决角色审批并记录。无论哪种处理，例外原因和批准人都要留痕，作为下一轮复审的依据。
范围约定和事件管理、问题管理的边界怎么区分？
范围约定回答的是“哪些请求由这个团队受理、按什么口径交付”，属于事前边界。请求进入处理流程后，事件恢复处置和根因治理由事件管理与问题管理机制负责，不在范围约定里展开。写法上可以在服务项中说明交付到“恢复可用”为止，把根因排查、长期改进作为后续流程衔接，避免两份文件互相覆盖。
用工具承载服务目录和工单字段时，选型要看什么？
重点看三件事：门户入口能否按服务项组织并让请求方直接对号入座；工单字段能否自定义并承载服务项、请求方、责任角色等信息；请求需要研发侧处理时能否关联到工作项持续跟踪。ONES Desk 可用于内部支持等场景的工单统一受理、分派与跟踪，支持自定义工单属性与工单内容，并提供统一门户集中接收工单；工单可关联 ONES Project 的需求或缺陷工作项，处理经验也可关联 ONES Wiki 页面沉淀。服务目录条目本身能否结构化维护，建议在选型时向厂商确认。
