一、ISO/IEC 20000-1:2018 8.3.3 标准原文
条款要求：组织应与顾客就服务级别达成一致，建立、评审并保持服务级别协议和相关支持协议，对服务级别进行监视、测量和报告，并在需要时采取措施处理未达成的情况。
二、标准条款解读说明
2.1 服务级别管理要素表
| 要素 | 说明 | 常见产物 |
|---|---|---|
| 协商与定义 | 将客户需求转化为可量化、可验证的服务级别 | SLA、服务说明 |
| 支撑分解 | 将外部承诺分解为内部和外部支撑要求 | OLA、UC、值班规则 |
| 监视与报告 | 持续跟踪是否达标并向相关方反馈 | 月度服务报告、偏差分析 |
| 评审与改进 | 根据业务变化和履约情况调整级别 | 协议修订、改进计划 |
2.2 核心理解
服务级别管理是服务管理体系中最容易被看见、也最容易做偏的条款。做浅了，SLA会变成几项抽象指标，无法指导运行；做过了，组织又可能承诺超出能力边界，最终频繁失约。8.3.3的目标，是让服务承诺既符合客户价值，也符合组织能力。
成熟的服务级别管理包含两条线：一条是面向客户的承诺管理，一条是面向内部和供应链的支撑管理。比如客户要求关键故障2小时恢复，那么内部可能需要15分钟升级、30分钟专家介入、供应商1小时响应和完整回退机制。只签客户SLA，不拆到内部和供应商，服务级别管理就不会真正落地。
2.3 服务级别管理最怕“数字完整、逻辑空心”
很多组织的SLA看起来条款很多、指标很多，但真正执行时依然问题不断，原因通常不在于数字不够，而在于逻辑没打通。比如可用率定义了，但没有说明计划停机如何处理；响应时限定义了，但没有写清何时开始计时、何时暂停计时；恢复目标写了，但内部和供应商并没有对应承接动作。这样的SLA很容易在报告和争议处理中暴露短板。
因此，SLA的成熟度不在于格式是否复杂，而在于客户、服务商、服务台、技术团队和供应商是否都能围绕同一套规则理解服务承诺。只要这点成立，SLA才会成为治理工具，而不是只在签约或审核时被拿出来展示的文档。
三、实施要点
3.1 从需求出发设计SLA
- 基于业务影响、服务重要性和客户可接受程度设计差异化服务级别。
- 不要把所有客户或所有服务都套用同一套级别。
3.2 做好内部支撑分解
- 将对客户的承诺拆解为服务台、二线、运维、开发和供应商的内部要求。
- 对无法支撑的承诺，必须在签订前调整或补齐资源。
3.3 建立统计与报告规则
- 明确统计口径、时间窗口、豁免条件和异常处理规则，防止数据争议。
- 定期输出SLA报告，对未达成情况做原因分析和改进跟踪。
3.4 定期评审服务级别适宜性
- 业务变化、服务模式调整、投诉上升时，应复审服务级别。
- 通过客户反馈、实际履约表现和成本分析判断是否调整。
3.5 让SLA真正驱动管理动作
- 将未达标项分为偶发偏差和结构性偏差，后者必须进入问题分析或改进计划。
- 对关键SLA建立内部预警阈值，而不是等月报出来才知道已经失约。
- 在签订或调整SLA前，要求内部支撑团队和供应商同步确认承接能力，避免“客户协议先签、内部能力后补”。
- 对长期无效或已失去管理意义的指标进行清理，保持SLA聚焦真正重要的服务承诺。
四、常用工具与实施方法
| 工具/方法 | 用途 | 输出 |
|---|---|---|
| SLA模板 | 标准化定义服务级别 | SLA文档 |
| OLA/UC映射表 | 分解内部和供应商支撑要求 | 支撑协议清单 |
| SLA仪表盘 | 监控履约情况 | 达成率看板 |
| 月度服务评审 | 与客户评审服务表现 | 评审纪要和改进项 |
| 偏差根因分析 | 处理持续未达标项目 | 改进计划 |
五、典型案例
案例一：SLA签得漂亮却无法兑现
某服务商为了争取客户，承诺所有P1故障1小时恢复，但内部没有24小时专家支持，供应商响应也无法匹配，结果频繁违约。按8.3.3重新梳理后，组织将SLA分级并同步建立内部支撑协议，履约率明显改善。
案例二：通过统计口径统一减少争议
某集团经常与业务部门争论“工单到底算不算超时”，原因是暂停等待客户反馈的时间是否计入没有统一规则。组织补充SLA统计口径和例外说明后，报告争议明显减少，沟通也更聚焦在改进本身。
案例三：预警机制比月报更有价值
某服务商早期每月都能按时输出SLA报告，但往往报告出来时偏差已无法挽回。后来组织在8.3.3下新增周度预警机制，对重点SLA设预警阈值和责任人，月中就能看到哪些指标可能失约。这样一来，很多偏差能在正式月报前被提前纠正，SLA开始真正发挥治理作用，而不只是事后统计作用。
写作时把这一点讲清楚，读者会更容易理解8.3.3为什么不是一份协议条文，而是一套持续监视和持续纠偏机制。
从服务治理视角看，SLA 真正厉害的地方并不是把客户要求数字化，而是把这些数字背后的支撑责任和预警机制也一并建立起来。只要组织开始围绕这些信号做提前干预，服务级别管理才算真正进入管理层面。
这也是为什么一些组织表面上有完整SLA文件，却仍被客户认为“服务不透明”。问题往往不在协议文本本身，而在协议没有持续转化成可见的报告、可解释的偏差分析和可执行的提前措施。
从长期运行角度看，服务级别管理成熟后，组织会越来越少地把SLA看作“月底算账工具”，而会越来越多地把它看作日常预警工具和资源校准工具。这个思路变化，往往是服务级别管理从初级走向成熟的关键标志。
也就是说，8.3.3 最终想建立的，并不是一套漂亮的协议文本，而是一种围绕承诺持续监控、持续解释、持续调整的经营性节奏。
审核8.3.3时，最有价值的证据通常不是一份格式漂亮的SLA，而是一条完整的履约证据链：客户需求如何被转化为指标，内部如何承接，月度如何统计，偏差如何解释，长期未达标又如何进入改进。这条链路一旦闭合，服务级别管理就不再是纸面承诺，而是真正进入管理运行。
因此，服务级别管理的成熟标志从来不是协议页数多少，而是组织能否持续把客户期望、资源能力和风险现实放在同一张桌子上讨论，并据此做出及时调整。
成熟组织还会把SLA与客户体验信号结合起来看。因为有些指标虽然达标，但客户感知并不好；有些偶发偏差虽然存在，却并未真正影响业务。把达标率和客户价值放在一起评估，SLA 才不会变成脱离业务现实的机械计分表。
因此，8.3.3 最终要求组织形成的是一种“既讲规则、也讲价值”的承诺管理能力。只有这样，服务级别管理才能既守住边界，又真正服务于业务结果。
六、成文信息管理要求
- 保留SLA、OLA、UC及其版本修订和批准记录。
- 保留SLA监测数据、服务报告、偏差分析、例会纪要和改进记录。
- 对协议调整、例外批准和客户争议处理，应保留完整证据链。
七、常见误区及踩坑提醒
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 只签SLA不建支撑协议 | 客户承诺高，内部无人负责支撑 | 同步建立OLA和供应商支撑要求 |
| 指标设计脱离业务 | 看起来精细，但无法反映客户真正感知 | 围绕业务影响设计服务级别 |
| 统计口径不统一 | 报告经常引发争议 | 明确规则、豁免条件和数据来源 |
| 未达标只解释不改进 | 报告月月红灯，问题却持续存在 | 对持续偏差开展根因分析和改进行动 |