制定SLA计时规则，核心是把服务承诺拆成可计量的起止点、日历、暂停条件和达标口径，再按优先级设定响应与解决时限，最后用角色分工、工单字段和定期复核把规则落到日常运行。本文给出一份可执行的SLA计时规则表及其配套职责与检查清单，并说明这类规则如何借助ONES Desk的工单字段、状态流转与报表能力承载。
要点总览（TL;DR）
- SLA计时规则的最小要素包括计时起点、计时日历、暂停与恢复条件、停止计时与达标判定口径，以及按优先级区分的响应与解决时限。
- 制定顺序为：梳理服务目录与工单类型、确定优先级分级依据、设定分级时限、定义计时起点与日历、确定超时升级规则、评审发布并配置到工单系统。
- 暂停条件要写成可用是或否判定的事实，并指定确认人；超时升级路径要写明触发阈值、通知对象和通知方式。
- 规则落地依赖工单字段与状态流转，ONES Desk可承载优先级定义、自定义字段与工作流配置，计时与提醒机制需结合团队实际配置确认。
- 发布前逐项检查计时起点、暂停判定、时限对应、升级责任人和复核周期，运行后用超时分布与暂停占比检验时限合理性。
先定口径：SLA计时规则要写清哪些要素
一份能执行的SLA计时规则，必须让不同岗位的人对同一张工单得出相同的计时结论。做到这一点，规则表至少要覆盖五类要素，缺一项就会在争议时失去判定依据。
| 要素 | 要回答的问题 | 填写要求 |
|---|---|---|
| 计时起点 | 从哪一刻开始算时间 | 明确依据提交时间、受理时间、分派时间还是首次响应时间，并说明以系统哪个字段为准 |
| 计时日历 | 哪些时间段计入时长 | 选择7×24、工作日或约定服务窗口，写明时区、工作日范围和每日服务时段 |
| 暂停与恢复条件 | 什么情况下时钟停下、何时重新走 | 写成可核验的事实，如等待客户补充信息、等待第三方处理，并指定确认人 |
| 停止计时与达标判定 | 何时算完成、怎样算达标 | 明确以解决确认、关闭状态或首次响应为停止点，并说明达标是按单次还是按周期统计 |
| 分级时限 | 不同优先级分别允许多久 | 为每个优先级分别给出响应时限和解决时限，两者分开设定 |
这五项要素之间存在依赖关系：计时起点决定响应时限从何时起算，日历决定时限的实际长度，暂停条件决定已用时长是否连续。规则表按工单类型分行填写，同一类型内再按优先级分列，避免把不同业务的承诺混在一张表里比较。
按步骤制定SLA计时规则
制定过程按六个步骤推进，每一步都有明确输入和输出，前一步的输出是后一步的输入。完成标志是规则表通过评审并完成系统配置。
第一步：梳理服务目录与工单类型
输入是现有服务清单和历史工单记录。动作是按服务对象和请求性质归类，形成工单类型清单，例如账号权限、系统故障、数据查询、设备报修。输出是服务目录与工单类型对照表。完成标志是每类工单都能对应到唯一类型，且类型数量控制在可维护范围内。
第二步：确定优先级分级依据与紧急性判定
输入是业务影响范围和用户范围。动作是设定分级维度，常用维度包括影响人数、业务中断程度、是否有替代方案、是否临近关键业务节点。输出是优先级定义表，通常分为紧急、高、中、低四级，每级配一段可判定的描述。完成标志是一线人员能依据描述独立定级，不需要逐单请示。缺陷严重程度分级属于另一套口径，此处只处理服务请求的紧急性。
第三步：为每级设定响应与解决时限
输入是历史处理时长数据和对外承诺。动作是分别设定首次响应时限与解决时限，响应时限通常短于解决时限，高优先级差距更小。输出是分级时限表。完成标志是时限与团队实际处理能力匹配，且经过服务负责人确认。
第四步：定义计时起点、日历、暂停与恢复
输入是工单在系统中的状态流转路径。动作是为每类工单指定唯一起点，选定日历类型，列出暂停条件清单并指定判定人。输出是计时规则明细。完成标志是每条暂停条件都能用是或否回答，不存在“视情况而定”这类表述。
第五步：确定超时升级与通知规则
输入是时限表和岗位设置。动作是设定预警阈值，例如剩余时间达到一定比例时提醒，以及超时后的逐级通知对象和通知方式。输出是升级路径表。完成标志是每个阈值都对应到具体岗位，而非笼统的“相关领导”。
第六步：评审发布并纳入工单系统配置
输入是前五步的全部输出物。动作是组织服务负责人、一线代表和系统管理员评审，确认口径一致后发布，并把时限、日历、暂停条件转化为工单字段和状态规则。输出是正式发布的规则表与配置记录。完成标志是规则表版本可追溯，系统配置与文档一致。
角色分工与各环节交付物
规则停留在文档里，通常是因为没有人对判定和维护负责。以下分工把制定、判定、维护和复核落到具体角色。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 服务负责人 | 制定服务承诺与分级时限，确认对外口径 | 服务目录、优先级定义表、分级时限表 |
| 一线处理人 | 按规则判定暂停条件，发起暂停与恢复申请 | 暂停原因记录、补充信息请求记录 |
| 二线或技术负责人 | 确认技术类暂停与恢复，判断是否属于第三方等待 | 暂停确认意见、第三方处理凭证 |
| 工单管理员 | 维护工单字段、状态与计时配置，保证系统与规则一致 | 字段配置说明、状态流转配置记录 |
| 服务管理负责人 | 组织定期复核，处理规则争议 | 复核纪要、规则修订版本 |
暂停判定最容易产生分歧，建议采用双人确认：一线提出暂停原因，二线或工单管理员确认后生效，恢复时同样留痕。复核周期按月或按季度设定，复核内容包括超时集中出现的工单类型、暂停时长占比和分级是否被普遍上调。
示例：一张可用的SLA计时规则表
以下示例为演示情景，时限数值仅用于说明填写方式，实际取值应结合团队处理能力和对外承诺确定。
| 优先级 | 响应时限 | 解决时限 | 计时起点 | 计时日历 | 暂停条件 | 恢复条件 | 超时升级 |
|---|---|---|---|---|---|---|---|
| 紧急 | 15分钟 | 4小时 | 工单提交时间 | 7×24 | 等待客户补充必要信息；等待第三方厂商处理 | 客户回复或第三方反馈到达 | 超时即通知值班负责人与二线负责人 |
| 高 | 30分钟 | 8小时 | 工单提交时间 | 工作日9:00–18:00 | 等待客户补充必要信息 | 客户回复到达 | 剩余时间不足四分之一时预警，超时通知二线负责人 |
| 中 | 2小时 | 2个工作日 | 工单受理时间 | 工作日9:00–18:00 | 等待客户确认方案 | 客户确认或拒绝 | 超时通知工单管理员 |
| 低 | 1个工作日 | 5个工作日 | 工单受理时间 | 工作日9:00–18:00 | 等待客户确认方案 | 客户确认或拒绝 | 纳入周报汇总，不单独通知 |
填写时注意三点：紧急级别采用7×24日历，意味着夜间和周末同样计时，需要配套值班安排；中低级别以受理时间为起点，可以避免工单在队列中等待分派的时间被计入处理时长；暂停条件只保留可核验的两类，其他情况按正常计时处理，防止暂停被滥用。
规则落地到工单系统与协作流程
规则表发布后，需要在工单系统中变成可记录、可提醒、可统计的字段和状态，否则计时只能靠人工估算。
字段与状态配置
把优先级、工单类型、计时起点时间、暂停原因、暂停开始与恢复时间、响应完成时间、解决完成时间配置为工单字段。状态流转按“待受理—处理中—暂停—已解决—已关闭”设计，暂停状态与暂停原因字段联动，恢复时自动记录恢复时间。ONES Desk支持自定义工单属性并灵活调整工作流，可以把上述字段和状态纳入同一套配置，使不同角色的收集需求和处理路径在同一工单上体现。
提醒与升级触发
预警和超时提醒依赖系统对剩余时间的判断。通用做法是设置两级触发：剩余时间达到阈值时提醒当前处理人，超时后按升级路径通知上级岗位。ONES Desk可评估和定义工单优先级，优先解决紧急事件，为分级时限的执行提供入口；具体的计时与提醒机制需结合团队实际配置方式确认。
留痕与达标统计
计时记录要能回答三个问题：这张工单用了多久、暂停了多久、是否在时限内完成。管理者视角的工单处理情况汇总和分析报表可用于掌握处理进度与团队表现，达标率统计应事先约定按单次工单还是按周期汇总，避免同一数据出现两种口径。当工单需要研发侧配合时，可将工单关联到ONES Project的需求或缺陷工作项持续跟踪，使跨团队处理过程仍能回到原工单上核对时间。
完成检查：规则是否可执行
发布前逐项核对以下检查项，全部通过再进入系统配置和试运行。
- 每类工单都有明确的计时起点和停止条件，且起点对应到系统中的具体字段。
- 每条暂停条件都能用是或否判定，并写明由谁确认暂停与恢复。
- 每个优先级都同时具备响应时限和解决时限，时限与分级依据对应完整。
- 计时日历写明时区、工作日范围和服务时段，非服务时段的处理方式有说明。
- 超时升级路径写明触发阈值、通知对象和通知方式，每个环节有责任人。
- 达标判定口径统一，明确统计周期和数据来源。
- 规则表有版本号和复核周期，修订流程与责任人已确定。
- 系统配置与规则表逐条对应，试运行期间能导出计时记录用于验证。
检查中发现模糊表述，回到对应要素重新定义，而不是在运行阶段靠个案解释。规则投入运行后，用第一个复核周期的超时分布和暂停占比检验时限是否合理，再决定调整分级还是调整时限。
常见问题
工单在队列中等待分派的时间，应该计入SLA计时吗？
这取决于计时起点的选择，规则表里必须写明。以提交时间为起点时，排队等待分派的时间计入时长，适合对整体等待体验有承诺的场景；以受理时间为起点时，分派前的排队时间不计入处理时长，更适合处理资源有限、分派环节本身耗时较长的团队。
两种做法都可以用，关键是同一类工单只选一种起点，并在系统中对应到具体字段。如果高优先级用提交时间、低优先级用受理时间，需要在规则表中分行注明，避免统计时口径混用。
客户长时间不回复，暂停计时有没有上限？
建议为暂停设置上限，否则工单可能长期停留在暂停状态，既无法反映真实处理压力，也让达标率失真。常见做法是约定客户回复的等待期限，例如若干工作日，到期后自动恢复计时并通知处理人跟进；也可以到期后转为关闭或挂起，由服务负责人确认后续处理方式。
上限的具体取值属于团队约定，需与对外承诺保持一致，并在规则表中写明到期后的动作和责任人，避免暂停成为规避超时的手段。
规则运行一段时间后，发现大部分工单都超时，应该先调时限还是先查流程？
先看超时的分布再决定。如果超时集中在某一类工单或某个环节，通常说明流程存在瓶颈，例如分派环节等待过久、暂停条件被频繁触发，此时调整时限只是掩盖问题。如果超时均匀分布在各类工单，且处理时长普遍接近或略超时限，说明时限设定与团队实际能力不匹配，可以在复核周期内调整时限。
复核时同时关注暂停时长占比和分级是否被普遍上调，这两项指标能反映规则是否被绕开使用。
多个团队共同处理一张工单时，计时责任怎么划分？
计时以工单整体为单位，不因转交而重置，否则跨团队协作会不断刷新时钟。规则表需要明确工单在主责团队之间的流转是否触发暂停：如果转交属于正常处理流程，计时继续；如果必须等待另一团队排期且本团队无法推进，可以按第三方等待处理并记录暂停原因与确认人。
当工单需要研发侧配合时，可将其关联到ONES Project的需求或缺陷工作项持续跟踪，处理进展仍回到原工单上核对时间，避免两边记录不一致。
计时规则需要多久复核一次，复核看哪些数据？
复核周期按月或按季度设定均可，取决于工单量和业务变化速度。复核内容包括：超时集中出现的工单类型、暂停时长占总时长的比例、各优先级的实际分布是否与分级定义相符、升级通知是否按路径送达。
复核由服务管理负责人组织，形成纪要并更新规则版本。规则修订后同步调整系统配置，保证文档与配置一致，试运行期间可导出计时记录用于验证。
