设计SLA规则表，核心是把服务承诺拆成可判定的条件与可计量的时限：先按服务对象和影响范围划分优先级，再为每个优先级定义响应、处理、解决三类时限与计时口径，最后补齐暂停、升级、例外和复核字段。这样形成的规则表才能被工单系统直接执行，也便于一线人员一致判断。
要点总览（TL;DR）
- SLA规则表按“判定字段+承诺字段”分列组织：规则编号、适用服务/工单类型、优先级、判定条件负责定级，响应/处理/解决时限、计时口径、暂停条件、升级路径负责承诺，一行对应一条可执行规则。
- 优先级用影响范围与紧急程度两个维度组合判定，条件写成可观察事实，边界情况设兜底优先级和人工复核入口；缺陷严重程度不在本表重复定义。
- 三类时限分别写明对应动作与起止时点，计时口径统一起算时间、工作日历、节假日与跨时区处理，暂停条件限定情形与时长上限并规定恢复计时判定。
- 规则表由服务负责人起草、处理团队负责人确认可行性、复核人检查可核对性后审批发布，变更记录版本号、原因、生效日期与审批人。
- 上线前用历史工单回放检验判定一致率，上线后按周期复核达成率、暂停频率与升级次数，异常时优先修订判定条件表述。
一张可执行的SLA规则表包含哪些字段
SLA规则表需要同时承载两类信息：判断“这张工单属于哪一级”的判定字段，以及承诺“在多长时间内做到什么”的承诺字段。两类信息混写在同一段文字里，执行时容易产生歧义，建议在表结构中分列呈现。
最小字段集可以按以下清单组织：
| 字段 | 类型 | 用途 |
|---|---|---|
| 规则编号 | 标识 | 唯一标识一行规则，便于引用、变更和审计 |
| 适用服务/工单类型 | 判定 | 限定规则生效的对象范围，如某系统、某类请求 |
| 优先级 | 判定 | 该行规则对应的服务等级 |
| 判定条件 | 判定 | 可观察、可核对的事实描述，用于确定工单落入该优先级 |
| 响应时限 | 承诺 | 从起算时点到首次有效回应的最长时长 |
| 处理时限 | 承诺 | 从受理到进入处理动作或阶段目标完成的时长 |
| 解决时限 | 承诺 | 从起算时点到服务恢复或问题关闭的时长 |
| 计时口径 | 承诺 | 起算时间、工作日历、工作时段、跨时区与节假日处理方式 |
| 暂停条件 | 承诺 | 允许停止计时的情形及暂停时长上限 |
| 升级路径 | 承诺 | 临近或超出时限时的通知对象与升级层级 |
| 生效范围与版本 | 管理 | 适用组织、生效日期、版本号与变更记录 |
填写粒度上，建议一行对应一条可执行承诺，即“一个适用服务/工单类型 + 一个优先级 + 一组时限”。同一服务类型下有四个优先级，就写四行，而不是把多个优先级塞进一行用分号隔开。这样系统匹配时只需命中一行，考核时也能按行统计达成率。
优先级如何判定：把紧急性写成可核对的条件下
优先级判定建议用两个维度组合：影响范围与紧急程度。影响范围回答“多少人、多少业务受影响”，紧急程度回答“业务是否还能继续”。两个维度交叉后，优先级就有了相对稳定的落点。
| 影响范围 | 业务可继续 | 业务不可继续 |
|---|---|---|
| 整体服务中断 | P2 | P1 |
| 多用户受影响 | P3 | P2 |
| 单用户受影响 | P4 | P3 |
判定条件要写成可观察、可核对的事实，例如“核心业务系统登录入口不可用，且当前为工作时段”“某部门5名以上用户无法提交报销单”。避免使用“非常紧急”“影响较大”这类主观形容词，否则不同受理人会对同一张工单给出不同优先级。
边界情况需要兜底规则：当影响范围或紧急程度无法当场确认时，先按可观察到的较高影响范围暂定优先级，同时标记“待复核”，由服务负责人或值班负责人在约定时间内确认或调整。人工复核入口要写进规则表，而不是留在口头约定里。
需要说明的是，软件缺陷的严重程度属于缺陷分类与分级范畴，由缺陷管理流程定义；SLA规则表只引用工单的紧急性和影响范围，不重复定义缺陷等级，避免两套标准互相冲突。
响应、处理、解决时限怎么设与怎么计时
三类时限对应三个不同动作，起止时点必须分别写清，否则考核时无法对齐。
| 时限类型 | 对应动作 | 起算时点 | 截止时点 |
|---|---|---|---|
| 响应时限 | 受理人首次有效回应，告知已受理并说明下一步 | 工单提交时间或受理时间（需在规则表中二选一并统一） | 首次有效回应记录时间 |
| 处理时限 | 进入实际处理动作，如排查、修复、协调资源 | 受理时间 | 处理动作开始或阶段目标完成 |
| 解决时限 | 服务恢复、问题关闭或给出经确认的解决方案 | 工单提交时间 | 关闭时间或恢复确认时间 |
计时口径要覆盖四件事：起算时间统一用提交还是受理；工作日历采用哪种（7×24、5×8 或自定义班次）；工作时段之外的提交如何顺延；跨时区和节假日如何处理。口径不统一，同样的时限在不同班次会算出不同结果。
暂停条件要限定情形和上限，例如“等待用户补充信息”“等待第三方厂商回复”可暂停计时，单次暂停不超过约定时长，超时自动恢复计时并计入总时长。恢复计时的判定标准要写成可操作的动作，如“用户补充信息提交成功即恢复”。
时限数值不宜凭主观拍定，可参考三个依据：服务等级分层（不同等级客户或不同业务系统的承诺差异）、历史工单的实际处理时长分布、业务方可接受的中断时间。三者结合后，再留出合理缓冲。
规则表落地到工单系统时，判定字段和时限字段需要有承载位置。ONES Desk 支持自定义工单属性与工单内容配置，可用于承载适用服务、影响范围、紧急程度等判定字段；支持评估和定义工单优先级；工作流可灵活调整，用于承载受理、处理、关闭等状态流转；工单分析报表可汇总处理情况，供管理者查看进度。SLA时限的自动计时、暂停与超时升级是否由系统直接承担，选型时需向厂商确认，规则表本身应先把这些口径定义清楚。
角色分工与规则表的交付物
规则表要有人定义、有人审批、有人执行、有人复核，职责不清时最容易出现“表写了但没人按表执行”。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 服务负责人 | 确定服务范围、优先级框架与时限目标，组织规则表编写 | 规则表初稿、时限设定依据说明 |
| 一线受理人 | 按判定条件为工单定级，记录判定依据，触发升级 | 工单优先级判定记录、升级记录 |
| 处理团队负责人 | 确认处理时限可达性，安排资源，处理超时工单 | 处理进度记录、超时原因说明 |
| 质量或运营复核人 | 抽样检查判定一致性，统计达成率，提出调整建议 | 复核报告、达成率统计、变更建议 |
审批与发布流程建议为：服务负责人起草→处理团队负责人确认时限可行性→质量或运营复核人检查判定条件可核对性→负责人审批发布。每次变更记录版本号、变更内容、变更原因、生效日期和审批人，旧版本保留可查。
执行侧需要留下的记录包括：每张工单的优先级判定依据（命中了哪条规则、依据什么事实）、各时限的达成情况、暂停起止时间与原因、升级触发时间与接收人。这些记录既是考核依据，也是后续调整规则表的输入。
示例：一张填好的SLA规则表片段
以下为演示情景，取值仅用于说明填写方式，实际数值需按自身业务调整。
| 规则编号 | 适用服务 | 优先级 | 判定条件 | 响应时限 | 处理时限 | 解决时限 | 计时口径 | 暂停条件 | 升级路径 |
|---|---|---|---|---|---|---|---|---|---|
| SLA-001 | 核心业务系统 | P1 | 整体服务中断，或工作时段内业务不可继续且影响多部门 | 15分钟 | 30分钟内启动处理 | 4小时 | 7×24，提交即起算 | 不设暂停 | 超响应时限通知值班负责人；超解决时限升级至服务负责人 |
| SLA-002 | 核心业务系统 | P2 | 多用户受影响但业务可继续，或单用户业务不可继续 | 30分钟 | 2小时内启动处理 | 1个工作日 | 5×8工作时段，非工作时段顺延 | 等待用户补充信息，单次不超过4小时 | 超解决时限50%通知团队负责人 |
| SLA-003 | 办公支持类 | P4 | 单用户受影响且业务可继续 | 4小时 | 1个工作日内启动处理 | 3个工作日 | 5×8工作时段 | 等待用户确认，单次不超过1个工作日 | 超解决时限通知受理人所在团队 |
取值理由：P1对应业务不可继续且影响面大，采用7×24计时并压缩响应窗口；P2覆盖“影响面大但可继续”和“影响面小但不可继续”两类，用工作日历平衡资源；P4为常规支持，时限放宽并允许等待用户确认。可迁移的规律是“影响越大、业务越不可继续，时限越短、计时越连续”；需要按自身调整的是具体分钟数、工作日历和升级接收人。
上线前的完成检查与后续维护
规则表发布前，逐项核对以下检查项：
- 每条判定条件都能用可观察事实核对，不依赖主观判断；
- 所有优先级都有对应的时限行，没有遗漏等级；
- 计时口径写明起算时间、工作日历、节假日与跨时区处理，无歧义；
- 暂停条件有明确情形和时长上限，恢复计时判定可操作；
- 每条升级路径都有具体接收角色，路径可达；
- 例外情形有审批入口和记录方式；
- 版本号、生效日期、审批人齐全。
试运行阶段可用历史工单回放：抽取一批已关闭工单，让受理人按新规则重新定级，统计与原定级的一致率，并检查时限达成情况是否与预期分布相符。一致率偏低时，优先修订判定条件的表述，而不是直接调整时限数值。
上线后建立固定复核周期，例如每月查看各优先级达成率、暂停使用频率和升级触发次数。出现达成率持续异常、争议集中在某条判定条件、或业务范围发生变化时，触发规则表调整。每次调整保留变更记录，并在工单系统中同步更新对应字段与流程配置，确保规则表与实际执行一致。
常见问题
SLA规则表里的时限数值应该怎么定，有没有参考依据？
时限数值可以结合三个依据来定：服务等级分层（不同等级客户或不同业务系统的承诺差异）、历史工单的实际处理时长分布、业务方可接受的中断时间。三者结合后再留出合理缓冲。不建议凭主观拍定，也不建议直接照搬其他团队的分钟数，因为工作日历、人员配置和业务节奏不同，同样的时限会产生不同的达成结果。
工单提交后影响范围一时确认不了，优先级怎么定？
规则表里需要写兜底规则：当影响范围或紧急程度无法当场确认时，先按可观察到的较高影响范围暂定优先级，同时标记“待复核”，由服务负责人或值班负责人在约定时间内确认或调整。人工复核入口要写进规则表，而不是留在口头约定里，这样受理人遇到边界情况时有明确动作可执行。
暂停计时用得太频繁怎么办？
暂停条件要限定情形和时长上限，例如“等待用户补充信息”“等待第三方厂商回复”可暂停，单次暂停不超过约定时长，超时自动恢复计时并计入总时长。复核时把暂停使用频率作为观察指标，如果某类暂停频繁出现，先检查是不是判定条件或信息收集环节有问题，再决定是否收紧暂停范围。
规则表上线后，什么情况下需要调整？
出现以下信号时触发调整：各优先级达成率持续异常、争议集中在某条判定条件、业务范围或服务对象发生变化。调整时保留变更记录，并在工单系统中同步更新对应字段与流程配置。如果历史工单回放的一致率偏低，优先修订判定条件的表述，而不是直接调整时限数值。
SLA规则表和缺陷严重程度分级是什么关系？
两者分属不同范畴。软件缺陷的严重程度由缺陷分类与分级流程定义，SLA规则表只引用工单的紧急性和影响范围来确定服务承诺，不重复定义缺陷等级。这样避免两套标准互相冲突，也避免同一张工单出现两个不同来源的等级判断。
