内部服务范围约定示例，是把“谁可以提、提什么、走哪条通道、由谁接、多久响应、什么情况退回或转出”写进一张可填写的约定表。本文以一家约300人公司的IT与行政共享服务为演示情景，给出一份已填好的约定表，逐项说明填写理由，并整理可迁移到其他组织的调整方法。示例为演示情景，非真实客户案例。
要点总览（TL;DR）
- 内部服务范围约定示例的核心，是把服务条目、服务对象、申请入口、责任角色、响应与处理时限、排除项与转出规则写进一张可填写的表。
- 示例以约300人公司的IT与行政共享服务为演示情景，覆盖账号权限、办公软件、网络接入、设备领用、会议室门禁与文印六类服务。
- 填写时先定服务对象再切分条目，时限按服务等级分层，排除项与转出规则成对出现，避免申请被拒后无人接手。
- 示例中的规模与时限均为演示设定，套用前需按自身人员配置和服务能力重新校准，并用实际请求数据定期回看覆盖情况。
- 事件恢复与根因治理属于事件与问题管理，不写进服务范围约定表，约定表只保留转出接口描述。
这份示例要解决什么问题
这份示例面向正在梳理内部服务范围的团队：服务提供方可能是IT、行政、人事或共享服务中心，服务对象是组织内的员工与部门。演示情景设定为一家约300人的公司，由IT与行政组成联合共享服务台，面向全体员工提供账号权限、办公软件、网络接入、设备领用、会议室与门禁等服务。选择这个规模，是因为它足以区分多条服务线，又不至于复杂到需要多层服务目录。
读者可以从本文获得三样产出：一张已填写的完整约定表，可以直接替换名称和数值后试用；一份字段级填写理由，帮助判断哪些内容需要按自身情况改写；一份可迁移的填写规律清单，用于组织评审和后续版本更新。约定表的作用是让申请方和受理方对“什么算在服务内、什么要转出去”形成同一份书面理解，减少反复询问和口头承诺。
本文聚焦内部服务范围约定本身。事件发生后的恢复处置与根因治理属于事件与问题管理主题，设备如何拆装维修属于技术操作教程，这两类内容不在本文展开。约定表只回答服务边界与受理规则，不替代后续的执行记录和处置流程。
完整示例：一份填好的内部服务范围约定表
下表为演示情景下的已填写示例。表中“响应时限”指受理方首次确认并告知申请人的时间，“处理时限”指给出结论、完成交付或明确转出的时间。时限数值为演示设定，实际使用时需按团队人员配置和服务能力重新校准。
| 服务条目 | 服务对象 | 申请入口 | 责任角色 | 响应时限 | 处理时限 | 排除项 | 转出规则 | 升级条件 |
|---|---|---|---|---|---|---|---|---|
| 账号开通与权限调整 | 全体正式员工；实习生由导师代提 | 服务台门户“账号权限”表单 | IT账号管理员 | 4工作小时内 | 1个工作日内完成或给出审批路径 | 涉及财务系统的高权限角色 | 转信息安全负责人审批，服务台保留工单并记录交接 | 超过1个工作日未完成，升级至IT主管 |
| 办公软件安装与授权 | 全体员工 | 服务台门户“软件服务”表单 | IT桌面支持 | 4工作小时内 | 2个工作日内完成安装或说明授权限制 | 未经采购审批的商业软件 | 转采购与法务评估，服务台回复申请人预计等待时间 | 涉及批量授权谈判，升级至IT主管与采购 |
| 网络接入与故障申报 | 全体员工；访客网络由接待人代提 | 服务台门户“网络”表单或服务台电话 | IT网络支持 | 30分钟内（工作时段） | 4工作小时内恢复或给出临时方案 | 员工自有设备的路由器配置 | 转申请人自行处理，服务台提供书面说明 | 影响整层或整栋办公，立即升级至IT负责人 |
| 办公设备领用与更换 | 全体正式员工；新入职员工随入职流程提交 | 服务台门户“设备领用”表单 | IT资产管理员 | 1个工作日内 | 3个工作日内完成发放或告知库存等待周期 | 非标准配置的设备型号 | 转部门负责人与IT主管联合审批 | 库存缺货超过5个工作日，升级至行政负责人 |
| 会议室预订与门禁权限 | 全体员工；外部访客由接待人申请 | 日历系统预订；门禁权限走服务台表单 | 行政服务专员 | 4工作小时内 | 1个工作日内生效 | 长期固定工位改造与装修改造 | 转行政设施管理另行立项 | 涉及跨楼层权限批量调整，升级至行政主管 |
| 打印与文印服务 | 全体员工 | 服务台门户“文印”表单 | 行政服务专员 | 4工作小时内 | 1个工作日内完成或说明耗材等待 | 大批量印刷与对外物料制作 | 转品牌或采购对接外部供应商 | 设备连续故障超过2个工作日，升级至行政主管 |
表格之外还需附三条通用规则，与上表配套使用。第一，退回规则：申请信息缺失、申请人不符合服务对象范围、事项落在排除项内，受理方在响应时限内退回并写明原因与建议去向。第二，转出交接：转出时原受理人保留工单，记录接收方与交接时间，接收方确认后才算完成交接。第三，优先级判定：影响多人或阻断办公的申请标为高，单人单次且不影响工作的标为普通，高优先级按表中响应时限执行，普通优先级可顺延但不超过处理时限。以上均为演示设定。
逐项解释：每个字段为什么这样填
服务条目的切分粒度，以“一个受理人能独立判断是否受理”为准。示例把账号开通与权限调整放在一条，因为两者由同一角色处理、判断依据相同；把网络接入与故障申报合并，是因为入口和责任人一致。条目过粗会让申请人不知道选哪一项，过细则增加维护成本。切分时可以先列出员工最常提的请求，再按受理角色归并。
服务对象与申请入口需要绑定填写。只写“全体员工”而不写入口，申请人会通过私聊、邮件、当面等多种方式提出，受理方难以统计和排序。示例中每条都指定了门户表单或电话通道，并对实习生、访客等特殊对象注明代提人，目的是让请求进入可追踪的队列，而不是散落在个人沟通记录里。
响应时限与处理时限分开写，是因为两者约束的动作不同。响应是“有人接、有人确认”，处理是“有结论、有交付”。只写一个总时限，容易出现受理方迟迟不确认、申请人无法判断进度的情况。示例中网络故障响应设为30分钟，是因为它直接阻断办公；账号权限响应设为4小时，是因为可以排队处理。时限按服务等级分层，比全表统一一个数值更贴近实际。
排除项要写到可判断的程度。“不处理复杂问题”这类表述无法执行，示例改为具体对象，例如“涉及财务系统的高权限角色”“未经采购审批的商业软件”。每条排除项后面紧跟转出规则，写明去向和交接方式，避免出现申请被拒后无人接手的空白地带。排除项与转出规则成对出现，是这张表能否被真正使用的关键。
升级条件的填写依据是“超时或影响扩大”。示例用两类触发：一类是超过处理时限仍未完成，一类是影响范围扩大到多人或多区域。升级对象写到角色而非个人姓名，便于人员变动后规则继续有效。优先级判定依据同样写在通用规则里，用影响范围和是否阻断工作作为判断标准，减少受理方与申请人之间的争议。
从示例到自用：可迁移的填写规律
改写这份示例时，建议按以下顺序推进，每一步都有明确的完成标志。
- 先定服务对象，再定条目。列出组织内的申请人类别（正式员工、实习生、外包人员、访客），完成标志是每类对象都能在表中找到对应的可提事项。
- 按受理能力切分条目。把现有请求按处理角色归类，合并同一角色、同一判断依据的事项，完成标志是每条服务条目都能指向一个明确的责任角色。
- 为每条目绑定唯一主入口。完成标志是申请人不需要询问就能找到提交位置，且请求能进入可统计的队列。
- 时限按服务等级分层。先区分阻断型、常规型、批量型，再分别设定响应与处理时限，完成标志是每条目两个时限都有数值和口径说明。
- 排除项与转出规则成对填写。完成标志是每条排除项后面都有接收方和交接方式，没有悬空事项。
- 补充退回与升级规则。完成标志是退回原因、升级触发条件和升级对象都以角色形式写明。
- 组织评审并确定版本节奏。由服务提供方与主要申请部门共同评审，约定每季度或每半年复核一次，人员或系统变动时触发临时修订。
不同组织的调整方向不同。小团队可以把六条服务合并为三到四条，时限适当放宽，责任角色由一人兼任多项，但排除项与转出规则不能省略，否则边界依然模糊。规模更大的组织需要把服务目录拆成两级，一级为服务线，二级为具体条目，并为每条服务线指定负责人；时限可以按部门或办公地点设置差异，但口径必须统一写在表头说明中。服务提供方从IT扩展为IT与行政联合时，要在责任角色一栏明确主责与协办，避免出现双方都以为对方在处理的交接空档。
约定表落地后需要有承载申请与流转的地方。ONES Desk 可用于IT服务、内部支持等场景，支持通过统一门户集中接收工单，并支持自定义处理流程与字段配置；其表单可配置并分享填写链接，让员工在门户提单，工单处理中可直接与申请人对话。示例表中的服务条目、申请入口、责任角色与状态流转，可以对应配置为工单类型、表单字段和处理流程，转出交接则可通过工单关联与状态记录留下痕迹。需要说明的是，响应与处理时限在产品侧的具体配置方式，本文未作核实，实际落地时需另行确认。
适用边界与常见误用
这份示例的数值和条目都来自演示情景，直接套用前需要按自身情况校准。组织规模、办公地点数量、是否有人值守服务台、外包人员的权限范围，都会影响条目划分和时限设定。示例中的“4工作小时”“1个工作日”只是演示口径，不能当作行业标准。
约定表适合承载服务边界与受理规则，不适合把事件恢复步骤和根因治理写进去。把“故障后如何回滚”“根因如何复盘”塞进服务范围约定，会让表格变成操作手册，既难以维护，也模糊了约定与执行的界限。这类内容应放在事件与问题管理的流程文档中，约定表只保留“什么情况转出、转给谁”的接口描述。
常见误用有四类。条目过粗，申请人无法判断该选哪一项，受理方也难以分派；时限缺失或只写一个总时限，进度无法判断；排除项空白，看似服务范围很大，实际遇到边界事项时只能临时协商；没有转出规则，申请被拒后无人接手。另一个容易被忽略的问题是约定表与执行记录脱节：表定好了，实际请求仍走私聊和邮件，表就失去了约束力。约定表需要与工单记录配合使用，定期用实际请求数据回看条目是否覆盖了主要事项。
涉及具体产品的版本差异、部署方式与合规认证，本文未作断言。若组织有等保、数据驻留或审计留痕要求，需要在选型和配置阶段单独查证，并将相关要求写入约定表的附注，而不是默认由示例覆盖。
常见问题
约定表里的响应时限和处理时限，小团队可以只写一个吗？
可以合并，但要接受一个后果：申请人无法区分“已受理”和“已处理完”两个阶段。响应时限约束的是受理方首次确认并告知申请人的动作，处理时限约束的是给出结论、完成交付或明确转出的动作。小团队人手少时，可以把两个时限写成同一数值，但建议在表头注明“首次确认与处理完成合并计时”，让申请人知道何时该追问。合并后仍需保留超时升级条件，否则时限只是纸面数字。
排除项写多少条才算够？
排除项的数量没有标准，判断依据是“实际发生过或可预见的边界请求是否都有去向”。可以从过去一个季度的请求记录里挑出被拒、被转走或反复协商的事项，逐条写成排除项，并在后面紧跟转出规则。示例中的六条服务各配一到两条排除项，属于演示规模。组织实际使用时，排除项会随业务变化增减，建议在每次版本复核时用实际数据补充，而不是一次写死。
约定表和工单系统是什么关系，表定好了还需要系统吗？
约定表规定边界与规则，工单系统承载申请入口、受理状态和转出交接记录，两者配合才能让规则被执行。表定好后如果请求仍通过私聊和邮件提出，受理方难以统计和排序，时限也无法核对。ONES Desk 可用于IT服务、内部支持等场景，支持通过统一门户集中接收工单，并支持自定义处理流程与字段配置，表单可配置并分享填写链接。示例表中的服务条目、责任角色与状态流转，可以对应配置为工单类型、表单字段和处理流程。响应与处理时限在产品侧的具体配置方式，本文未作核实，落地时需另行确认。
组织规模变大后，这张表要怎么改？
规模扩大后，主要变化在条目层级和责任分工。可以把服务目录拆成两级，一级为服务线，二级为具体条目，每条服务线指定负责人；时限可以按部门或办公地点设置差异，但口径要统一写在表头说明中。如果服务提供方从单一IT扩展为IT与行政联合，责任角色一栏要区分主责与协办，避免双方都以为对方在处理。条目数量增加时，申请入口也要相应细化，让申请人不需要询问就能找到提交位置。
约定表需要多久更新一次？
常见做法是每季度或每半年复核一次，并在人员变动、系统更换、办公地点调整时触发临时修订。复核时重点看三件事：实际请求是否集中在表内条目、排除项是否仍准确、转出交接是否出现过无人接手的情况。修订后保留版本记录，注明生效日期和主要变化，让申请方和受理方都使用同一版本。版本节奏由服务提供方与主要申请部门共同约定，规模小的组织可以适当拉长间隔。
