本文给出一份虚构但完整的SLA计时规则示例，把服务承诺拆成优先级、响应时限、解决时限、计时日历、暂停与恢复条件等可计算字段，并附逐项填写说明和一张工单的计时演算。示例数值仅用于演示，读者可参照结构改成自己团队的版本；ONES Desk可用于承载工单优先级、自定义属性与流程流转，文中在相关环节自然衔接。
要点总览（TL;DR）
- SLA计时规则示例的核心字段包括：优先级、响应时限、解决时限、计时日历、起算时点、暂停与恢复条件、超时升级动作，缺一项就会在结算时产生争议。
- 示例用四档优先级对应四类紧急性，P1采用7×24日历、15分钟响应、4小时解决，P2–P4按工作时间日历折算，非工作时间创建的工单起算点顺延。
- 暂停计时需同时满足状态变为“等待客户回复”和记录具体问题两个要件，恢复后从暂停点继续累计，而非重新起算。
- 迁移到自有团队时，档位数量、时限取值、日历口径、暂停最长时限和升级路径都需按历史工单数据与服务能力重新确定，示例数值不构成行业标准。
- 缺陷严重程度分级、人员派单与路由、跨时区多供应商场景不在本示例覆盖范围内，需另行设计。
示例目标：这份SLA计时规则要解决什么
这份示例面向一个虚构的IT服务台团队，设定为工作日9:00–18:00提供支持，周末与法定节假日不排班。团队每天收到来自内部员工的账号、网络、办公软件、硬件报修等工单，希望用一套明确的计时规则回答三个问题：一张工单从提交到首次响应允许等多久，从提交到解决允许等多久，等待客户补充信息的时间是否计入承诺时长。示例中的团队规模、工单量和时限数值均为演示取值，不代表任何真实客户案例。
示例覆盖的计时要素包括：优先级档位及其对应的响应时限与解决时限、计时日历的选择、计时起算时点、暂停条件与恢复条件、超时后的升级动作。这些要素共同构成一条可执行、可核对的计时链路，缺一项就会在结算时产生争议。例如只写“4小时内解决”而不写日历和起算点，遇到下班前提交的工单就无法判断4小时是自然时间还是工作时间。
需要说明范围：本示例聚焦服务承诺与紧急性，即“多快响应、多快解决”。软件缺陷的严重程度分级（如致命、严重、一般）属于缺陷分类主题，人员派单与工单路由策略属于工单分派主题，本文均不展开。示例也不涉及具体产品的SLA功能对比、价格或行业认证级别的时限基准。
完整示例：一张填好的SLA计时规则表
下表是示例团队填写完成的SLA计时规则表。四个优先级对应四档承诺强度，P1最紧急，P4为一般咨询。响应时限指从起算时点到首次有效响应的时间，解决时限指从起算时点到工单关闭或标记解决的时间。所有时限均按“工作时间”日历折算，P1在非工作时间提交时按7×24日历计算，以体现紧急事件的连续性。
| 优先级 | 适用工单类型 | 响应时限 | 解决时限 | 计时日历 | 起算时点 |
|---|---|---|---|---|---|
| P1 紧急 | 核心业务系统不可用、大范围网络中断、影响多人办公的账号故障 | 15分钟 | 4小时 | 7×24 | 工单创建时间 |
| P2 高 | 单人无法办公、关键软件无法登录、打印机等共用设备故障 | 1小时 | 8小时（1个工作日） | 工作时间 | 工单创建时间，非工作时间顺延至下一个工作时段开始 |
| P3 中 | 功能异常但有替代方案、非关键软件报错、权限申请 | 4小时 | 2个工作日 | 工作时间 | 同上 |
| P4 低 | 使用咨询、操作指引、优化建议 | 1个工作日 | 5个工作日 | 工作时间 | 同上 |
暂停与恢复条件、超时升级动作单独填写如下，适用于全部优先级：
| 规则项 | 填写内容 |
|---|---|
| 暂停条件 | 工单状态置为“等待客户回复”，且处理人在工单中记录了已发出的具体问题或所需材料 |
| 恢复条件 | 客户在工单中回复，或客户补充的材料已上传，工单状态回到“处理中” |
| 暂停期间计时 | 响应与解决计时同时暂停，恢复后从暂停时点继续累计 |
| 临近超时提醒 | 剩余时限达到总时限的20%时，向处理人和组长发送提醒 |
| 超时升级动作 | 响应超时：自动通知组长；解决超时：升级至服务台负责人，并在每日站会中列为待处理事项 |
这张表的关键在于每一行都能被独立核对：给定一张工单的优先级、创建时间和状态变更记录，任何人都能算出它当前已消耗多少承诺时间、是否超时。表格本身不解释取值理由，下一节逐项说明。
逐项解释：每个字段为什么这样填
优先级如何对应紧急性与承诺强度
示例用四档优先级，是因为团队日常工单大致可分为“业务中断、单人受阻、有替代方案、纯咨询”四类，档位再多会让一线人员在受理时难以快速判断，档位再少则无法区分P1与P2的承诺差异。P1的响应时限压到15分钟，目的是让紧急事件在第一时间有人接手并给出处置方向；解决时限4小时则对应“当天恢复核心业务”的运营要求。P4给到1个工作日响应、5个工作日解决，承认咨询类工单可以排队处理。档位数量与时限取值都应来自团队实际服务能力，示例数值不构成行业标准。
响应时限与解决时限的区别及起算时点
响应时限考核的是“有没有人接”，解决时限考核的是“问题有没有处理完”，两者分开设置可以避免一种常见偏差：处理人先回复一句“已收到”把响应指标做漂亮，实际问题仍长时间悬置。起算时点统一设为工单创建时间，是为了让承诺从客户提交那一刻开始计算，而不是从分派给某个人开始。对非工作时间创建的P2–P4工单，起算点顺延到下一个工作时段开始，这样客户在深夜提交的工单不会因为无人值班而天然超时。
计时日历选择对实际耗时的影响
计时日历决定“1小时”是自然时间还是工作时间。示例中P2的解决时限写8小时，按工作时间日历折算，周五17:00创建的P2工单，剩余1小时工作时间在当天18:00用尽，其余7小时顺延到周一，实际自然时间跨度接近3天。如果对外承诺写的是“8小时内解决”，客户很可能理解为自然时间，因此规则表必须与对外服务说明使用同一口径。P1采用7×24日历，是因为核心业务中断不分工作日，按工作时间计算会掩盖夜间无人响应的问题。
暂停与恢复条件的填写要点
暂停条件最容易产生争议，填写时要同时满足两个要件：状态变为“等待客户回复”，且处理人已记录具体问题。只改状态不写问题，等于把计时暂停当成拖延工具。恢复条件对应客户回复或材料到位，状态回到“处理中”，计时从暂停点继续累计，而不是重新起算。示例还设置了剩余20%时限的提醒，让处理人在暂停前后都能感知时限压力。超时升级动作要落到具体角色和具体动作，写“通知相关人”无法执行，写“通知组长并在站会列为待处理事项”才能被核对。
计时过程演示：一张工单从创建到关闭
以下是一条虚构工单的完整计时过程，用于展示规则表如何落地计算。工单编号示例为TK-1024，优先级P2，类型为“关键软件无法登录”。
- 周一10:00，员工提交工单，状态“待受理”。起算时点为10:00，响应时限1小时，解决时限8个工作小时。
- 周一10:20，服务台受理并首次回复，响应耗时20分钟，响应时限达成，剩余解决时限7小时40分钟。
- 周一11:00，处理人排查后判断需要员工提供报错截图，状态改为“等待客户回复”，计时暂停。此时已消耗解决时间1小时。
- 周一15:30，员工上传截图并回复，状态回到“处理中”，计时恢复。暂停时长4小时30分钟不计入承诺时间。
- 周一15:30至18:00，处理人继续排查，消耗2小时30分钟，累计解决时间3小时30分钟，剩余4小时30分钟，顺延至周二工作时段。
- 周二9:00至13:30，问题定位并修复，工单关闭，消耗4小时30分钟。累计解决时间8小时，在时限内完成。
如果换一种情况：员工直到周三才回复，恢复计时后剩余4小时30分钟从周三开始计算，工单的实际自然时间跨度被拉长，但承诺时间并未超时。这正是暂停规则的意义——把等待客户的时间从承诺中剥离，同时要求处理人留下明确的等待记录。若周二13:30仍未解决，剩余时限触及20%提醒线，系统向处理人和组长发出提醒；若继续超时，则按规则表升级至服务台负责人。上述时间与编号均为演示数据。
在工具承载上，这类计时链路依赖工单上的优先级字段、创建与状态变更记录、自定义属性（如“暂停原因”“所需材料”）以及流程状态的规范流转。ONES Desk支持评估和定义工单优先级以优先处理紧急事件，支持自定义工单属性满足不同角色的信息收集需求，并可灵活调整工作流以适应不同工作方式；其工单分析报表可用于查看团队处理表现。团队可据此把上述字段和状态落到工单模板中，使计时所需的时间点有据可查。具体计时规则的配置方式需结合所选版本另行确认。
可迁移规律：换到你的团队怎么改
示例的价值在结构而非数值。迁移时可按以下清单逐项调整，每项都对应一个需要团队确认的决策：
- 优先级档位数量：工单量小、类型单一的团队可压缩为三档（紧急、常规、咨询）；面向多业务线的服务台可保留四到五档，但每档必须有可观察的判定条件，避免受理人凭感觉定级。
- 时限取值：先统计过去一个季度同类工单的实际响应与解决耗时分布，取团队能够稳定达成的水平作为起点，再逐步收紧。直接照搬示例的15分钟或4小时，可能造成大面积超时或承诺过松。
- 日历口径：对外承诺写“工作时间”还是“自然时间”，必须与规则表一致，并在服务说明中写明工作时段和节假日安排。跨时区团队需要为每个时区定义日历，或统一采用一个基准时区。
- 暂停条件：明确哪些状态算暂停、暂停需要留下什么记录、暂停是否有最长时限。缺少最长时限时，长期挂起的工单会掩盖真实的服务水平。
- 升级动作：每个优先级至少定义响应超时和解决超时两条升级路径，写明触发对象、通知方式和后续处理动作。
- 变更与版本管理：规则调整后保留旧版本及生效日期，历史工单按创建时适用的版本结算，避免用新规则追溯旧工单。对外承诺变更需提前通知客户或内部员工。
这套规律同样适用于把规则落到工具中：优先级字段、状态流转、自定义属性和报表口径需要一起调整，只改表格不改流程，计时结果仍会失真。
适用边界：这些情况不适用本示例
本示例适用于单一地点、固定工作时段、以内部员工为服务对象的IT服务台场景。以下情形需要另行设计，不能直接套用：
- 缺陷严重程度分级：软件缺陷按致命、严重、一般等等级划分并对应修复承诺，属于缺陷分类主题，其分级依据与SLA优先级不同，需单独设计。
- 人员派单与路由：按技能组、值班表或负载自动分派工单，属于工单分派主题，本文只讨论计时，不涉及由谁处理。
- 跨时区与多供应商：多个时区接力服务、外部供应商承担部分处理环节时，日历、暂停条件和责任边界都需要重新定义，可能还需要区分内部处理时间与供应商等待时间。
- 数值基准：示例中的15分钟、4小时、8小时等均为演示取值，不构成行业标准、认证要求或对客户的承诺基准，读者应结合自身服务能力确定。
在边界之内，读者可以按本文的表格结构填写一版初稿，用历史工单回算验证，再发布为团队正式规则。
常见问题
SLA计时规则中的响应时限和解决时限，能否只设一个？
可以只设一个，但会失去对“接单”和“处理完”两个环节的分别约束。只考核解决时限时，处理人可能长时间不回应，客户无法判断工单是否已被受理；只考核响应时限时，容易出现先回复“已收到”把指标做漂亮、实际问题仍悬置的情况。示例把两者分开设置，响应时限考核有没有人接，解决时限考核问题有没有处理完。若团队工单量很小、处理链路短，合并为一个时限也可行，但需在服务说明中写清该时限覆盖到哪一步。
工单在“等待客户回复”状态挂了两周，暂停计时有没有上限？
示例规则表未设置暂停最长时限，这是需要在迁移时补上的决策点。缺少上限时，长期挂起的工单会持续占用承诺时间之外的“暂停”状态，掩盖真实的服务水平。常见做法是设定暂停最长期限（如3个工作日或5个工作日），到期后自动恢复计时并提醒处理人跟进，或转为“待关闭”状态由客户确认。具体天数应结合业务节奏确定，并在对外服务说明中写明，避免客户认为提交后即进入无限期等待。
非工作时间提交的P1工单，起算时点怎么处理？
示例中P1采用7×24日历，起算时点就是工单创建时间，深夜提交也立即开始计时，响应时限15分钟照常计算。这样设置的前提是团队对P1有实际的值班安排；若夜间无人值守，规则表应如实反映，例如将P1起算点顺延至值班时段开始，或单独定义“夜间紧急事件”的响应路径。规则与实际值守能力不一致时，超时会集中出现在非工作时间，反而削弱规则的可信度。
规则调整后，历史工单按新规则还是旧规则结算？
建议按工单创建时适用的规则版本结算，并在规则表中保留旧版本及生效日期。用新规则追溯旧工单，会让已经达成的记录变成超时，或让原本超时的记录被“修正”，两类结果都会影响团队对规则的信任。对外承诺变更时，还需提前通知客户或内部员工，说明新规则的生效时间和适用范围。若工具中承载了时限字段，规则版本切换应与字段和流程的调整同步进行。
把示例规则落到工单系统里，需要准备哪些字段和记录？
计时链路依赖几类信息：工单优先级字段、创建时间与每次状态变更的时间记录、暂停原因与所需材料的自定义属性、以及规范的状态流转。ONES Desk支持评估和定义工单优先级以优先处理紧急事件，支持自定义工单属性满足不同角色的信息收集需求，并可灵活调整工作流以适应不同工作方式；其工单分析报表可用于查看团队处理表现。团队可据此把示例中的字段和状态落到工单模板中，使计时所需的时间点有据可查。具体计时规则的配置方式需结合所选版本另行确认。
