SLA 是对客户的承诺；OLA 则确保你的内部团队能够兑现。使用 Trupeer，你可以从免费的运营级别协议（OLA）模板开始，结合你的 品牌规范 进行定制，并将 OLA 转换为视频演练，让每个内部团队都围绕共同的服务标准达成一致，从而节省编写 OLA 的数小时工作量。

运营级别协议模板是什么？

运营级别协议（operational level agreement，简称 OLA）是同一组织内团队之间达成的内部协议，它支撑着对组织外部某一方所作出的承诺。服务台承诺企业：重大事件的解决时间为四小时。只有当网络团队、应用团队以及链条中的其他相关方都在已知时间内各司其职，这项承诺才成立。

OLA 就是把这些内部环节写下来。它不是合同；也没有人向任何人付款；执行完全由管理层推动——这既是它的弱点，也是它能以合同无法做到的方式保持坦诚的原因。

运营级别协议模板是一套可复用的结构：当事方、覆盖的服务、承诺内容、衡量方式以及复审安排。模板很容易找到。大多数模板会让你写出“看似完全合规”的 OLA，但最终仍然失败——而本页其余内容正是围绕这一点展开。

OLA vs SLA：两者各自到底承诺了什么

这一家族里有三份文件，混用它们会带来真正的问题。

服务级别协议（service level agreement） 是对客户或业务方的承诺。它以客户的口径撰写，通常是端到端的视角，并且会被上报给交付链条之外的人。

运营级别协议（operational level agreement） 是内部协议，存在于同一组织内、向同一组织汇报的团队之间。它的唯一目的，是让 SLA 变得可实现，并且绝不应包含 SLA 不需要的任何承诺。

支撑合同（underpinning contract） 是与第三方、供应商或外包提供方签订的商业协议，用于支撑同一条交付链。它具有法律效力，而 OLA 不具备；同时它通常也是三者中灵活性最低的，因此应当在 SLA 之前达成，而不是之后。

实际后果是一条顺序规则：先敲定支撑合同，再基于这些合同允许的范围制定 SLA，最后用 OLA 填补剩余部分。那些按相反顺序做事的组织，往往会向业务承诺一些供应商从未同意交付的内容。

如何在 Trupeer 中自定义此模板

步骤 1：打开模板（Templates）部分

从主导航进入“Templates（模板）”部分。

步骤 2：选择并打开模板

点击任意你想要处理的模板，将其打开。

步骤 3：展开模板视图

如有需要，展开模板视图以清晰查看完整布局和细节。

步骤 4：编辑模板

点击“Edit（编辑）”开始修改所选模板。

在编辑器中，你可以：

• 添加新的章节

• 定义或更新格式规则

• 添加徽标，并调整其位置及相关设置

步骤 5：保存你的自定义模板

完成所有必要更改后，点击“Save（保存）”，将更新后的模板保存为你的版本。

步骤 6：预览并微调模板

当你想查看自定义模板的效果时，打开“Preview（预览）”。

在预览界面中，如有需要，你还可以继续直接进行调整，确保模板呈现得完全符合你的预期。

使用运营级别协议模板，你可以：

• 节省编写时间：跳过空白页，直接使用为 OLA 构建的结构。

• 让内部团队对齐：内置字段确保每个团队都清楚自己的职责。

• 保持品牌一致：使用 Trupeer 的品牌套件应用你的徽标、字体和颜色。

• 保护客户 SLA：强有力的 OLA 能防止内部交接破坏外部承诺。

• 跨服务标准化：为每一份内部协议使用同一套 OLA 模板。

• 覆盖全球团队：一键将 OLA 翻译为 65+ 种语言。

为什么每个团队都能达成 OLA，但 SLA 仍会违约

这是服务管理中最常见的模式，看起来像是矛盾。

每个团队都显示为绿色。网络团队在一个小时内响应。应用团队在两小时内完成。服务台在三十分钟内完成初步分诊。月度 OLA 合规报告读起来很舒服。而客户的 SLA 却在三分之一的重大事件中发生违约。

原因在于：OLA 衡量的是团队内部的用时，而 SLA 衡量的是端到端的用时。这两个数字之间的差值就是“传递时间”：工单在重新分配后仍停留在队列中等待被接手，或因需要更多信息而被退回。

这段时间属于任何人吗？不属于。它不在任何人的 OLA 里，也不会在任何地方被上报，而且往往比所有实际工作时间加起来还要更长。

这意味着失败是结构性的，而不是绩效问题。对团队施压去达成他们现有的数字并不会有帮助，因为他们已经在达成。

OLA 管理的是交接，而不是工作本身

解决这一问题的关键转变很小，但它会改变文件的用途。

按通常方式撰写的 OLA，会让团队承诺“自身工作需要多久”。这部分由团队掌控，因此团队愿意签下；但它也是最没用的承诺，因为它从来都不是变量。

写得更好的 OLA，会让团队承诺“彼此之间的接口”。也就是：工单在交接前必须包含哪些内容；接收团队需要多久才能开始处理；当工单不完整时会发生什么；在交接空档期内工单由谁负责。

一旦交接成为主题，这两个缺失字段就会变得显而易见：进入条件（entry criteria），即接收团队的计时开始前必须满足什么；以及对“传递时间”本身进行明确分配——这样团队之间的空档就变成某个人的数字，而不是“没人负责”的空白。

OLA 模板里的其他内容都属于管理性信息。这两项才是文件的核心。

进入条件：计时开始前必须成立的事实

多团队链条中最具破坏性的行为只有一种：退回（bouncing）。工单在信息不足的情况下到达，接收团队退回，随后他们的计时又被重置。

从接收团队的角度看，退回完全是理性的。他们无法开展工单工作，而他们的合规性又以“自身解决时间”来衡量，因此退回能同时保护双方。退回也是大量已耗时长的来源，并且在所有“分别衡量团队”的报告中都看不见。

进入条件通过把责任上移来修复它。每一条 OLA 记录都会列出：该团队要接手工作，必须填充哪些具体字段。对于网络交接，可能包括设备名称、站点代码、精确的错误文本、首次观察到的时间，以及是否影响其他用户。对于应用交接，可能包括用户、交易引用、复现步骤以及一张截图。

然后，发送团队的承诺措辞也会改变：不再是“在三十分钟内完成分诊”，而是“在三十分钟内交付一份满足进入条件的工单”。计时相同，但义务不同；激励也会落到真正能够收集到这些信息的团队身上。

接收团队仍保留拒绝接手的权利，而且应当是一个范围很窄的权利：只有在明确的进入条件确实缺失时，拒绝才有效；并且每一次拒绝都必须记录原因。记录机制会把“退回”从一种看不见的习惯变成一个必须有人解释的数字。

免费运营级别协议模板：可直接复制的结构

从这里复制。带星号（*）标记的字段是标准模板通常会省略的。

页眉。 OLA 参考编号与版本。双方（parties），即以名称标注的两个团队。该 OLA 支撑的 SLA 或服务。生效日期、复审日期，以及双方各自指定的负责人。

范围。覆盖哪些服务、系统或请求类型，并明确说明不覆盖哪些内容。

服务时间。每一方的覆盖范围，包括非工作时间安排及其差异。处于同一条链条中的两个团队如果服务时间不匹配，是一种常见且悄无声息但致命的缺口。

承诺表。按请求类型或优先级各一行，并包含：触发条件、进入条件、响应时间、解决或交还时间、已分配的传递时间以及升级节点。

升级。每个阶段由谁被联系、通过什么路径联系、以及经过多久后升级。包含非工作时间路径。

依赖关系。本团队需要从其他方获得什么，包括与第三方的任何支撑合同，并标注各自的时间，以便可以核对计算结果。

衡量。衡量什么、来自哪个系统、由谁来衡量、以及多久上报一次。除响应与解决外，还要包含 退回率（bounce rate），因为它能揭示进入条件是否真正发挥作用。

例外情况。已达成一致的情形：例如在已宣布的重大事件期间，或在变更冻结期间，承诺不适用。

复审。日期，以及触发非周期复审的条件。

从这里复制。控制在两到三页内。OLA 太长，需要读两遍以上的内容，在事件发生时不会被查阅；而事件发生时，恰恰最需要它。

如何检查 OLA 是否真正加总到 SLA

在签署任何内容之前，先做加总计算。这只需要十五分钟，但几乎总是被跳过，因为 OLA 是在不同日期、与不同团队逐一协商出来的。

两条规则让这件事变得有用。传递时间必须单独列出，因为这正是关键点。并且每条链都需要缓冲（headroom），因为如果链条的总和刚好等于 SLA，那么只要任何地方稍有偏差就会违约。10% 到 15% 是一个合理的余量。

如果总和超过 SLA，你有三种“诚实”的选择：重新谈判 SLA、通过某些方式减少某个团队的用时以使其可行，或取消某次交接。你不能做的是：签署一份保证违约的 OLA，然后再用它来对团队绩效进行管理——而令人惊讶的是，很多服务台都处在这种立场。

那家“把传递时间用得比工作时间还长”的零售商

Rendlesham Group 运营多家零售品牌，员工约六千人，并设有一个内部 IT 服务台，为门店和总部提供支持。

其对业务方的 P2 事件 SLA（解决时限）为四小时。P2 的违约率在两年内一直维持在约 38%。每个团队的 OLA 合规情况按月上报，且每个团队都显示为绿色。

直到有人终于为 120 起已违约的 P2 事件逐一记录了每个状态变更的时间戳。

中位数的总耗时为 6 小时 51 分。其中，3 小时 12 分是在团队内部积极处理工单的时间。3 小时 39 分是传递时间：在重新分配后停留在队列中等待被接手，或被退回。

在这起违约事件的总耗时中，超过一半的时间属于“无人负责”，也没有任何地方被记录。

最大的单一贡献来自退回（bouncing）。在这 120 份工单中，有 41 份至少被接收团队退回过一次，原因是信息不足；每一次退回都会使中位数增加 1 小时 20 分，并重置接收团队的计时。最常见的两类原因是：没有附上错误文本或截图，以及没有确认该事件影响的是哪家门店。

改动范围很窄。每一条 OLA 记录都写入了进入条件。服务台的承诺从“30 分钟内完成分诊”改写为“30 分钟内交付一份满足进入条件的工单”。每次交接分配 15 分钟的传递时间，并在接收团队满足进入条件后计入其时间。每一次退回都记录原因。

在接下来的两个季度里，退回率从 P2 的 34% 降至 9%。中位数传递时间从 3 小时 39 分降至 1 小时 6 分。P2 的违约率从 38% 降至 11%。

没有任何团队的内部解决时间发生实质性变化。没有人变得更快。原本属于“无人负责”的时间只是被分配给了某个团队。

如何一步步起草运营级别协议

从 SLA 开始，而不是从模板开始。把客户被承诺的内容端到端写下来，并明确其计时定义。

梳理交付链条。按顺序列出所有会接触该类型请求的团队，包括任何第三方。把交接画成独立的步骤，而不是用箭头表示。

对每一次交接，向接收团队只问一个问题：你需要工单里有什么信息，才能开始工作而不需要再把它退回给我们？把这个答案写下来，就是你的进入条件。团队通常能回答得很快也很准确，但大多数情况下他们从未被问过。

接下来，统一约定时间：在上述加总逻辑下进行，而不是逐个团队分别拍脑袋。把所有人放在同一场对话里完成，通常只需要一小时，并且能从根本上避免“加总不对”的问题。

明确分配传递时间，并决定由谁负责。每次交接 15 分钟是一个合理的起点，并且应当计入接收团队的时间。

再约定衡量方式，包括退回率，以及数据来源。若你的工具无法生成这些数据，那么在签署之前知道这一点就很有价值，而不是等到第一次复审时才发现。

然后先运行一个季度，再正式定稿。第一版通常在一两处会出错；在签署之前修正会更容易。

常见 OLA 失误，以及每一种会带来什么代价

只衡量团队，而不是衡量整条链。大家都显示绿色，但 SLA 仍然违约。这是最常见的失败方式，也是本页讨论的主题。

没有进入条件。退回会变成接收团队的“合理防御”，而已耗时长会在不知不觉中不断膨胀。

时间无法加总。这套 OLA 的设定保证会违约，但从来没有人把它加总过。

服务时间不匹配。一个团队覆盖到 6 点，另一个团队覆盖到 5 点。5 点之后到达的所有内容都会在夜间堆积，而没有任何报告能显示这一点，因为两个团队都在各自的服务时间范围内。

把 SLA 的措辞直接复制到 OLA。处罚、抵扣以及法律表述不属于这里；把它们导入后，团队会以防御姿态谈判，而不是坦诚协作。

在 OLA 中写入第三方。如果涉及资金流转，这就属于支撑合同，需要采购与法务参与，而不是模板。我们的 IT 采购政策模板 覆盖了审批路径。

签署与归档。一份没有人复核的 OLA，会描述一条大约在一年后就不再存在的服务链。

当 OLA 已经存在后，如何管理与复审

汇报整条链，而不是各个组件。只有一个数字重要：端到端相对 SLA 的表现；而 OLA 指标的存在，是为了帮助解释它，而不是让它独立存在。

每季度复审一次，所有相关方都在场。双边复审会复现最初的问题，因为“缺口”存在于那些从未在同一场对话中出现的双方之间。

关注三件事。按交接点统计退回率，它告诉你进入条件哪里需要改进。按交接点统计传递时间，它告诉你队列在哪里正在形成。以及那些走了 OLA 未描述路径的事件占比，它告诉你这份文件已经偏离现实。

当发生以下情况时触发非周期复审：某个团队重组、系统在团队之间迁移、新的第三方进入交付链，或 SLA 发生变化。以上四类情况发生的频率通常比年度复审周期假设的要高。

OLA、SLA 还是支撑合同：你需要哪一个？

如果承诺对象是交付组织之外的人——无论是外部客户，还是正在被服务的内部业务单元——那么这就是 SLA。

如果承诺对象是同一组织内的两个团队之间，且没有资金流转，那么这就是 OLA。

如果承诺对象是基于商业安排的供应商，那么这属于支撑合同，需要法务与采购参与，而不是使用此模板。

尴尬的情况是共享服务中心，或采用成本分摊（chargeback）模式的内部团队，它处在 OLA 与 SLA 之间。实际的做法是把它写成 OLA，并删除任何关于处罚的措辞，因为内部处罚机制会稳定地产生防御行为，且带来更差的服务。

对于所有这些之上、面向客户的定义与响应措辞，我们的 help desk response template 和 ticket and resolution template 覆盖了终端用户真正会看到的那一层。

我可以用 Word 或 Excel 获取 OLA 模板吗？

Word 适用于协议本身，因为范围、例外情况和复审章节是段落文本，且文件会被流转用于签署确认。

Excel 适用于两个部分。承诺表：你希望在可排序可核对的列中填写进入条件、时间与传递分配。以及加总核对表：每条链都要与其 SLA 相加，并标记任何缺少缓冲（headroom）的情况。第二张表通常更值得优先构建，因为它往往会改变你原本打算协商的内容。

PDF 适用于签署版本：从源文件导出。保留可编辑的工作版本，因为在第一个季度结束后，进入条件几乎总需要根据真实退回情况进行调整。

如何让 OLA 与现实保持同步

OLA 描述的是一条不断变化的工作链。团队会重组，系统会迁移，工具会更换，而文件往往是最后一个被任何人更新的东西。

最先过时的部分是进入条件，因为它们描述工单必须包含什么；而工单必须包含什么，又取决于当前工具与当前流程实际如何运作。

Trupeer AI 通过让底层流程的维护成本更低，帮助你保持其最新状态。只需记录一次分诊或交接流程，你就会得到一份包含步骤与界面截图的书面流程，服务台可以照着执行，并且能清楚展示正在收集哪些信息。当工具发生变化时，重新录制即可，不必重写。

记录它。打造它。翻译它。Trupeer 它。

SOP creator 覆盖 OLA 所依赖的流程；我们的 IT SOP template 则说明如何决定哪些流程值得持续维护。Documentation 会把协议与流程放在一起，设置说明在 document template setup guide 中。

常见问题解答

Word 里有免费的运营级别协议模板吗？

上面的结构可以直接粘贴到 Word 或 Google Docs 中，包括标准模板通常会省略的进入条件与传递分配字段。没有门槛下载，也没有表单。把承诺表保留在电子表格中并进行引用，因为这部分需要排序与加总。

PDF 里有免费的运营级别协议模板吗？

当双方达成一致后，将签署版本导出为 PDF，并保留可编辑的工作副本。进入条件几乎总需要在第一个季度之后进行调整，因为你终于能看到工单实际是因为什么被退回的。

Excel 里有免费的运营级别协议模板吗？

Excel 是承诺表与加总核对的最佳载体。用一张表：每次交接一行，并在 SLA 旁边设置累计值，同时标记任何缺少 10% 缓冲的链条。在你谈判之前先搭好这张表，往往会改变你最终要谈判的内容。

我在哪里可以找到运营级别协议 PDF 示例？

一些 ITSM 供应商与政府机构会以文档形式发布 OLA 和 SLA 模板，它们在结构上是合理的。你可以阅读它们的章节结构而不是具体内容，因为任何公开示例里的承诺都属于别人的交付链，而这些时间在脱离其所支撑的 SLA 之外就没有意义。

谁来签署运营级别协议？

由双方各自指定的负责人签署；该负责人应当是对该团队交付结果负责的经理，而不是服务管理职能部门。只有服务管理部门签署的 OLA 更像是一种愿景，因为需要投入资源的人并不在场。

服务台需要多少份 OLA？

通常比大多数团队预期的要少。每一对会定期交换工作的团队各一份，且在同一张承诺表中覆盖所有请求类型，而不是每个服务各一份。超过大约十几份之后，维护就会成为约束条件，文件也会比复审更快过期。

运营级别协议需要包含处罚吗？

不需要。因为没有可执行的法律关系，而内部处罚机制往往会产生防御行为：团队会拒绝接手工作，争论计时从何时开始，并为了自己的数字而优化，而不是为了结果。请改为端到端汇报整条链，这样共享的后果会变得可见，而不需要任何人被罚款。

OLA 应该多久复审一次？

每季度一次，所有相关方都在场；此外，当发生以下情况时也要进行非周期复审：某个团队重组、系统在团队之间迁移、新的第三方进入交付链，或底层 SLA 发生变化。按季度的节奏可以捕捉偏离，而触发条件则能捕捉那些会让文件在隔夜之间变得不正确的变化。