把服务承诺写成一张可执行的SLA规则表，团队才能判断某张工单该在多久内响应、多久内解决，以及超时后找谁处理。本文先给一张可直接复制的空白表，再逐字段说明含义与取值，标注必填与选填，附一行完整填写示例，最后说明规则增删和定期复核的方法。内容聚焦服务承诺与紧急性判定，缺陷严重程度分级、派单路由和商务赔偿条款不在本文展开。
要点总览（TL;DR）
- SLA规则表把服务承诺拆成可执行的行：每条规则写明适用工单类型、优先级或影响范围、响应与解决时限、计时日历和超时提醒对象。
- 建表最低可用字段包括规则编号与名称、适用工单类型、优先级/影响范围、响应时限、解决时限、计时单位、服务日历、超时提醒对象、生效日期和生效状态；多服务线、多级升级时再补选填字段。
- 填写时最容易出错的是时限起点和计时口径：响应与解决时限的起算点要统一，工作日单位应配工作日日历。
- 规则修改采用递增版本加新生效日期的方式，旧版本保留可追溯；停用规则改状态并填失效日期，不直接删行。
- 规则表定稿后需在工单系统中落地为可执行配置，表格版本与系统配置同步更新，避免两处口径不一致。
可复制空白SLA规则表
下面这张表可以直接复制到Excel、在线表格或工单系统中使用。每行代表一条独立规则，规则之间通过“适用工单类型+优先级或影响范围+适用服务对象”区分，避免同一张工单同时命中多条规则。表头下方保留一行空行，方便对照格式逐行填写。
| 规则编号 | 规则名称 | 版本 | 适用工单类型 | 优先级/影响范围 | 适用服务对象 | 响应时限 | 解决时限 | 计时单位 | 服务日历 | 暂停/挂起条件 | 超时提醒对象 | 升级层级 | 生效日期 | 失效日期 | 责任人 | 复核周期 | 生效状态 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
复制到表格软件后，建议先做三件事：把“响应时限”“解决时限”两列设为数值格式并统一单位；把“生效状态”列做成下拉选项，取值限定为“草稿、生效、停用”；冻结表头行，方便规则数量增加后仍能对照列名填写。如果规则较多，可以按“适用工单类型”排序，让同类规则集中在一起，便于检查是否重叠。
每个字段管什么：SLA规则表字段说明
字段可以分成五组：规则标识、触发条件、承诺时限、计时口径和处置衔接，再加一组治理字段。理解每组字段回答的问题，填写时就不容易漏项或写错口径。
| 字段组 | 字段 | 含义与取值口径 | 常见写法 |
|---|---|---|---|
| 规则标识 | 规则编号 | 规则的唯一标识，便于引用和变更记录 | SLA-001、SLA-INC-01 |
| 规则标识 | 规则名称 | 用一句话说明这条规则管什么 | 高优故障工单响应与解决 |
| 规则标识 | 版本 | 规则修订次数，修改时限或日历后递增 | V1.0、V1.1 |
| 触发条件 | 适用工单类型 | 规则命中的工单类别，取值来自工单分类体系 | 故障报修、服务请求、咨询 |
| 触发条件 | 优先级/影响范围 | 按优先级或影响范围限定触发条件，二选一或组合使用 | P1；影响多个部门 |
| 触发条件 | 适用服务对象 | 规则覆盖的用户群体、服务线或合同类型 | 内部员工、VIP客户 |
| 承诺时限 | 响应时限 | 从计时起点到首次有效响应的时间上限 | 30分钟、4小时 |
| 承诺时限 | 解决时限 | 从计时起点到工单关闭或恢复服务的时间上限 | 8小时、2个工作日 |
| 承诺时限 | 计时单位 | 时限的计量单位，需与数值配套 | 分钟、小时、工作日 |
| 计时口径 | 服务日历 | 计时所依据的工作时间安排，决定非工作时段是否计入 | 7×24、工作日9:00–18:00 |
| 计时口径 | 暂停/挂起条件 | 计时可以中止的情形，需写明恢复条件 | 等待用户补充信息、等待第三方厂商 |
| 处置衔接 | 超时提醒对象 | 临近或超过时限时接收提醒的角色或岗位 | 当班处理人、值班主管 |
| 处置衔接 | 升级层级 | 超时后逐级上报的对象与顺序 | 一线组长→服务经理→部门负责人 |
| 治理 | 生效日期 | 规则开始执行的日期 | 2025-03-01 |
| 治理 | 失效日期 | 规则停止执行的日期，长期有效可留空 | 2025-12-31 |
| 治理 | 责任人 | 负责该规则内容准确与及时更新的人 | 服务台主管 |
| 治理 | 复核周期 | 规则定期检查的间隔 | 每季度、每半年 |
| 治理 | 生效状态 | 规则当前所处阶段 | 草稿、生效、停用 |
填写时有两个口径容易出错。一是“响应时限”和“解决时限”的起点要统一，通常都从工单创建或受理时刻起算，如果两者起点不同，应在规则名称或备注中写明。二是“计时单位”与“服务日历”要配套：写“2个工作日”却配7×24日历，实际计时会与预期不符，建议工作日单位只配工作日日历。
哪些必填、哪些选填
判断一个字段是否必填，看它是否影响两件事：能否判定计时起止，能否找到超时后的责任对象。缺了就无法执行或无法判定超时的字段应设为必填，其余按服务复杂度补充。
| 类别 | 字段 | 必填理由或适用场景 |
|---|---|---|
| 必填 | 规则编号、规则名称 | 没有标识就无法引用、变更和排查冲突 |
| 必填 | 适用工单类型 | 决定规则命中哪类工单，缺失则规则无法触发 |
| 必填 | 优先级/影响范围 | 区分同一工单类型下的不同承诺水平 |
| 必填 | 响应时限、解决时限、计时单位 | 构成承诺本身，缺一项就无法判定是否超时 |
| 必填 | 服务日历 | 决定非工作时段是否计入，直接影响超时判定 |
| 必填 | 超时提醒对象 | 超时后需要有人收到信号，否则规则只停留在纸面 |
| 必填 | 生效日期、生效状态 | 区分草稿与执行中的规则，避免误用 |
| 选填 | 适用服务对象 | 存在多服务线、多客户等级时补充，单一服务对象可省略 |
| 选填 | 暂停/挂起条件 | 存在等待用户或第三方的情形时填写，否则计时连续计算 |
| 选填 | 升级层级 | 需要多级上报时填写，只有单一提醒对象时可省略 |
| 选填 | 版本、失效日期、责任人、复核周期 | 规则数量多、需要长期治理时补充；规则少且稳定时可先简化 |
一个实用的取舍是：先按必填字段建出最小可用规则表，让每条规则都能独立判定超时并找到提醒对象；等出现多时区、多服务线或多级升级的实际需求，再补选填字段。这样规则表不会因为列太多而无人维护，也不会因为缺关键字段而无法执行。
一行完整填写示例
下面是一条已填好的规则，场景为某公司内部IT服务台对高优先级故障工单的承诺。示例中的时限、日历和人员均为演示设定，实际填写时按本团队的服务能力替换。
| 字段 | 示例取值 | 取值理由 |
|---|---|---|
| 规则编号 | SLA-INC-01 | 按工单类型缩写加序号，便于与故障类规则归组 |
| 规则名称 | P1故障工单响应与解决 | 名称直接点明优先级和适用类型 |
| 版本 | V1.0 | 首次发布 |
| 适用工单类型 | 故障报修 | 与工单分类体系中的类别一致 |
| 优先级/影响范围 | P1 | 只覆盖最高优先级，其他优先级另设规则 |
| 适用服务对象 | 内部员工 | 当前服务台只面向内部，暂不区分客户等级 |
| 响应时限 | 30 | 高优故障需要快速确认，30分钟内首次响应 |
| 解决时限 | 8 | 按工作时段计，一个工作日内恢复服务 |
| 计时单位 | 分钟/小时 | 响应以分钟计，解决以小时计，与数值配套 |
| 服务日历 | 工作日9:00–18:00 | 非工作时段不计入，与解决时限的工作日口径一致 |
| 暂停/挂起条件 | 等待用户补充信息 | 信息不全时计时中止，用户回复后恢复 |
| 超时提醒对象 | 当班处理人、值班主管 | 处理人先收到提醒，主管同步知悉 |
| 升级层级 | 值班主管→服务经理 | 超时30分钟升主管，超时2小时升服务经理 |
| 生效日期 | 2025-03-01 | 与新版服务目录同步上线 |
| 失效日期 | 留空 | 长期有效，后续修订时再填 |
| 责任人 | 服务台主管 | 负责规则内容与人员名单的准确性 |
| 复核周期 | 每季度 | 故障量和服务能力变化较快，季度复核 |
| 生效状态 | 生效 | 已审批并上线执行 |
这条示例与空白表的列一一对应，填写其余规则时可以照此结构替换取值。需要留意的是，示例中“响应时限30分钟”配的是工作日日历，意味着夜间创建的工单从次日上班开始计时；如果团队提供7×24值守，应把服务日历改为7×24，并重新评估30分钟是否仍可达成。
规则表定稿后，需要在工单系统中落地为可执行的规则：按工单类型和优先级匹配对应时限，按服务日历计算剩余时间，临近或超过时限时向提醒对象发出通知，并按升级层级逐级上报。ONES 工单管理支持为工单设置优先级与SLA规则，并在接近或超出时限时提醒相关处理人，规则表中的时限、日历和提醒对象可以直接对应到系统配置中，减少人工盯单。规则调整时，系统内的配置与表格版本应同步更新，避免两处口径不一致。
规则表的调整与维护方法
规则表上线后，服务能力、人员和组织结构都会变化，需要一套固定的增删改流程，让表格始终反映当前承诺。
新增规则
出现新的工单类型、新的服务对象或现有规则无法覆盖的场景时新增规则。新增前先检查是否与已有规则重叠：同一工单类型、同一优先级、同一服务对象只应命中一条规则。新增规则以“草稿”状态提交，由责任人确认时限可达成、提醒对象和升级层级有人承接后，再改为“生效”并填写生效日期。
修改时限或日历
修改承诺时限或服务日历时，不直接覆盖原值，而是递增版本号并填写新的生效日期，保留旧版本记录。这样在追溯某张历史工单为何按某个时限判定时，能找到当时生效的规则。若修改影响面较大，可先在小范围工单类型上试运行一个复核周期，再推广到全部规则。
定期复核
按规则表填写的复核周期执行检查，重点看四项：时限是否仍可达成，可对照近期工单的实际响应和解决数据；提醒对象和升级人员是否在职或岗位已调整；规则之间是否存在重叠或空档，例如某优先级没有任何规则覆盖；暂停条件是否被滥用，导致计时长期中止。复核结果记录在规则表的版本和责任人字段中，形成可查的变更轨迹。
停用与归档
规则不再适用时，把生效状态改为“停用”并填写失效日期，而不是直接删除行。停用规则保留在原表中或移入归档区，便于回答“过去某段时间适用什么承诺”这类问题。归档时同步清理系统中对应的规则配置，避免已停用的规则继续触发提醒。
常见问题
同一张工单同时满足两条SLA规则时怎么处理？
这通常说明规则设计存在重叠。建表阶段可以用“适用工单类型+优先级或影响范围+适用服务对象”三项组合来区分规则，保证同一组合只对应一条生效规则。如果实际业务中确实存在交叉，例如某类VIP客户的故障工单既符合通用P1规则又符合客户专属规则，应在规则表中明确优先顺序，常见做法是专属规则优先于通用规则，并把这一约定写进规则名称或备注。上线前用几条典型工单做命中测试，比事后排查冲突更省事。
服务日历怎么选，7×24和工作日计时能混用吗？
服务日历取决于团队实际的值守安排。提供全天候值守的服务台可以用7×24日历，非工作时段也计入时限；只在工作时段处理工单的团队用工作日日历，夜间和周末创建的工单从下一个工作时段开始计时。同一张规则表里不同规则可以使用不同日历，例如故障类用7×24、咨询类用工作日，但每条规则的时限数值要与所选日历匹配。写“2个工作日”却配7×24日历，实际计时会短于预期，这是填写中最常见的口径错配。
暂停计时会不会被滥用，怎么控制？
暂停条件本意是处理“等待用户补充信息”“等待第三方厂商”这类团队无法推进的情形，但条件写得太宽会让计时长期中止，SLA形同虚设。控制方法有三点：暂停条件逐条列明，不用“其他情况”兜底；写明恢复计时的触发动作，例如用户回复后自动恢复；在定期复核时统计暂停时长占比，占比异常偏高的规则需要重新审视条件设置。规则表中保留暂停条件字段，正是为了让这类检查有据可依。
规则表建好后，怎么保证系统里的配置和表格一致？
把规则表当作唯一事实来源，系统配置按表执行。每次修改时限、日历或提醒对象时，先更新表格并递增版本、填写生效日期，再同步调整系统配置，两处使用同一个版本号便于核对。定期复核时增加一项对照检查：抽取几条生效规则，比对表格中的时限、日历、提醒对象与系统配置是否一致。ONES 工单管理支持为工单设置优先级与SLA规则，并在接近或超出时限时提醒相关处理人，规则表中的关键字段可以直接对应到系统配置中。
规则数量多了以后，表格怎么组织才不至于混乱？
可以按“适用工单类型”分组排序，让同类规则集中排列，便于发现重叠和空档；规则编号采用“类型缩写+序号”的规则，例如故障类统一用INC前缀，查找和引用都更快。已停用的规则移入单独的归档区或归档表，主表只保留草稿和生效状态的规则，日常维护时视线更清晰。如果规则数量持续增长，可以考虑把规则表放到支持多人协作和版本记录的文档工具中管理，减少多人同时编辑造成的覆盖。
