制定SLA暂停规则，核心是回答“哪些等待时间不计入服务承诺”。可执行的做法是先划定可暂停的等待类型，再为每类定义触发条件、证据、审批人、暂停上限和恢复动作，把字段固化到工单状态与计时逻辑中，最后用暂停时长占比、超限次数等指标定期复核。规则落地的产物是一张暂停类型表加一份审批与恢复流程，单写一句“客户原因可暂停”无法支撑执行。
要点总览（TL;DR）
- SLA暂停规则只覆盖本团队不可控的外部等待，如等客户补充信息、等第三方厂商、等变更窗口、等依赖团队交付；内部排期、审批拖延、人员不足和缺陷修复耗时计入SLA。
- 规则需要拆成五组字段：触发条件、审批、暂停上限、恢复条件和计时口径，每类暂停都要有证据要求和指定审批人。
- 操作流程按识别等待、提交申请、审批挂起、恢复计时、归档复盘五步执行，暂停中的工单要按预计恢复时间设置提醒，超限进入升级清单。
- 上线前用历史工单回放做抽样验证，重点检查暂停期间客户回复、审批驳回后重新提交、超限后继续暂停等边界情况。
- 启用后第一个复核周期重点观察暂停时长占比与超限次数，据此调整单次上限和审批时限。
先定暂停范围：哪些等待时间可以从SLA里扣除
暂停范围的判定原则只有一条：暂停只针对本团队不可控的外部等待，并且这种等待要能留下可核查的证据。内部排期、内部审批拖延、人员不足、缺陷修复本身的耗时，都属于团队可控或应计入服务成本的部分，不进入暂停范围。把这条原则写清楚，后续字段设计和审批才有依据。
可暂停的等待通常集中在四类：等客户补充信息（日志、截图、账号权限、业务确认）、等第三方厂商处理（硬件返修、上游接口故障、外部供应商交付）、等变更窗口（生产变更审批排期、停机窗口）、等依赖团队交付（跨团队接口、数据或环境准备）。这四类的共同点是本团队无法单方面推进，等待时长取决于外部主体的响应节奏。
不可暂停的情形需要在规则中正面列出，避免执行时被“客户原因”这类模糊说法扩大解释：内部排期等待、内部审批流转、人员不足导致的排队、缺陷修复本身的开发与测试耗时、团队自行安排的计划性工作。这些时间反映的是团队交付能力，计入SLA才能暴露真实的服务水平。
判定时还要注意证据要求。可暂停不等于口头说明即可暂停，每类等待都要有可留痕的证据，例如客户沟通记录、第三方工单号、变更单链接、依赖团队的交付确认。没有证据的暂停申请应被驳回，否则暂停规则会变成规避SLA的工具。
完成范围判定后，输出一张暂停类型表，作为规则的第一份交付物：
| 暂停类型 | 适用工单范围 | 证据要求 | 是否可暂停 |
|---|---|---|---|
| 等客户补充信息 | 所有需客户提供日志、截图、权限或业务确认的工单 | 客户沟通记录、待补充事项清单 | 可暂停 |
| 等第三方厂商 | 依赖外部供应商、上游接口或硬件返修的工单 | 第三方工单号、厂商回复记录 | 可暂停 |
| 等变更窗口 | 需生产变更、停机窗口或审批排期的工单 | 变更单编号、计划窗口时间 | 可暂停 |
| 等依赖团队交付 | 跨团队接口、数据或环境准备类工单 | 依赖方交付确认、交接记录 | 可暂停 |
| 内部排期与审批 | 全部工单 | — | 不可暂停 |
| 人员不足排队 | 全部工单 | — | 不可暂停 |
| 缺陷修复耗时 | 缺陷类工单 | — | 不可暂停 |
暂停规则的字段设计：触发、审批、上限与恢复
范围确定后，要把规则拆成可配置、可填写的字段。字段设计的目标是让每一次暂停都有明确的发起人、审批人、时限和结束条件，减少执行时的自由裁量。以下五组字段构成暂停规则的结构化表达。
触发条件字段规定由谁在什么状态下发起暂停。通常由工单当前处理人在工单进入“等待外部”状态时发起，触发的前提是已具备对应类型的证据。字段应记录发起人、发起时间、工单当前状态，避免在工单尚未进入等待状态时提前挂起计时。
审批字段规定审批人角色、审批时限和驳回后的处理。审批人一般为服务台主管或SLA管理员，审批时限可设为工作时间内若干小时，超时未审批按驳回处理或自动升级。驳回时需填写原因，工单保持原计时状态，发起人补充证据后可重新提交。
暂停上限字段约束暂停的滥用。单次最长暂停时长按类型分别设定，例如等客户回复可设较长上限，等变更窗口按计划窗口加缓冲设定；同时设定累计暂停次数或总时长上限，超过上限的工单触发升级，由主管决定是否继续暂停或调整承诺。
恢复条件字段定义什么事件结束暂停并恢复计时。恢复事件应与暂停类型一一对应：客户回复、第三方交付、变更完成、依赖团队交接完成。恢复可由系统事件自动触发，也可由处理人手动确认，规则中要写明哪种方式为主、哪种为兜底。
计时口径字段说明暂停期间与恢复后的计算方式。常见做法是暂停期间停止SLA计时，恢复后继续累计剩余时限，响应时限与解决时限分别按各自已消耗时间续算。是否重新计算时限需要明确写死，避免同一工单在不同处理人手中出现两种算法。
| 字段名 | 取值 | 必填性 | 填写人 |
|---|---|---|---|
| 暂停类型 | 取自暂停类型表 | 必填 | 发起人 |
| 发起时间 | 系统时间 | 自动 | 系统 |
| 证据附件或链接 | 沟通记录、第三方工单号、变更单号 | 必填 | 发起人 |
| 预计恢复时间 | 日期时间 | 必填 | 发起人 |
| 审批人 | 主管或SLA管理员 | 自动带出 | 系统 |
| 审批结果 | 通过／驳回（附原因） | 必填 | 审批人 |
| 单次暂停上限 | 按类型预设时长 | 自动 | 系统 |
| 累计暂停上限 | 次数或总时长 | 自动 | 系统 |
| 恢复事件 | 客户回复／第三方交付／变更完成／依赖交接 | 必填 | 处理人或系统 |
| 实际暂停时长 | 恢复时间减暂停时间 | 自动 | 系统 |
操作步骤：从发起到恢复的完整流程
字段定义清楚后，按固定顺序执行暂停操作。每一步都要有输入、动作、输出和完成标志，便于培训和审计。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、识别等待并选择类型 | 工单当前进展、外部等待事实 | 对照暂停类型表判断是否属于可暂停范围，收集证据 | 暂停类型与证据材料 | 证据可被他人核查 |
| 二、提交暂停申请 | 暂停类型、证据、预计恢复时间 | 在工单中发起暂停，填写字段并提交 | 待审批的暂停申请 | 申请进入审批队列 |
| 三、审批与计时挂起 | 暂停申请 | 审批人核对类型与证据，通过后工单进入暂停状态 | 暂停中的工单，计时挂起 | 工单状态显示暂停，计时停止 |
| 四、恢复事件与恢复计时 | 客户回复、第三方交付等恢复信号 | 确认恢复事件，结束暂停，恢复计时 | 恢复计时的工单 | 计时重新累计，状态回到处理中 |
| 五、归档与复盘统计 | 暂停记录、实际暂停时长 | 归档暂停记录，纳入统计口径 | 暂停台账与统计报表 | 记录可查询、可汇总 |
第三步到第四步之间是风险最集中的区间。暂停中的工单容易失去跟踪，规则应要求处理人按预计恢复时间设置提醒，到期未恢复的工单进入超限清单，由主管跟进。恢复事件发生时，优先由系统事件自动恢复计时，人工确认作为兜底，减少漏恢复导致的计时错误。
在工单系统里承载这套流程时，可以把暂停类型做成可选字段，把审批、计时挂起与恢复做成状态流转。ONES 的工单管理支持自定义工作项类型、状态流与字段配置，可将暂停类型、证据、预计恢复时间设为必填项，并通过状态变更触发计时规则；暂停记录随工单留存，便于后续按类型统计暂停时长。规则设计完成后，这些配置动作与字段表一一对应，减少线下表格与系统记录两套口径。
角色分工与交付物：谁发起、谁审批、谁复核
暂停流程涉及四类角色，每类角色有明确的动作和交付物。职责写清楚，审批才不会流于形式，复核才有数据来源。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 一线工程师 | 识别外部等待、发起暂停、提供证据、跟踪恢复事件 | 暂停申请、证据材料、恢复确认 | 提交申请时交接给审批人；恢复时交接给计时系统 |
| 服务台主管或SLA管理员 | 审批暂停、处理超限与争议、维护暂停台账 | 审批记录、超限处理结论 | 审批完成后交接给处理人；超限时交接给流程负责人 |
| 客户或第三方对接人 | 提供恢复所需信息或交付物 | 客户回复、第三方交付确认 | 恢复事件发生时交接给处理人 |
| 流程负责人 | 定期复核暂停数据、调整类型与上限、组织抽样验证 | 复核报告、规则修订记录 | 按周期交接给服务台团队 |
交接节点是职责落地的关键。发起人提交申请后，责任转移到审批人；审批通过后，跟踪恢复的责任回到处理人；恢复完成后，记录进入流程负责人的复核范围。每个节点都应有时间要求，避免工单在角色之间停留过久。
示例：一次等客户回复的暂停如何走完
以下为演示情景，用于说明字段填写与状态流转，不代表真实工单数据。
场景设定：一张应用报错工单进入排查阶段，工程师判断需要客户提供完整日志才能继续定位，工单进入等待客户补充日志的状态。
暂停申请内容：暂停类型选择“等客户补充信息”；证据附上工程师向客户发出的日志收集说明与客户确认收到的沟通记录；预计恢复时间填写客户承诺的回复时间；发起人填写当前处理工程师。
审批与状态变化：主管核对类型属于可暂停范围、证据完整，审批通过。工单状态标记为“暂停—等待客户”，SLA计时挂起，响应与解决时限均停止累计，暂停台账记录开始时间。
恢复与结果：客户在预计时间内回复并上传日志，系统识别到客户回复事件，结束暂停并恢复计时，工单状态回到处理中。实际暂停时长按恢复时间减暂停时间自动计算并记入工单。若客户超过预计恢复时间未回复，工单进入超限清单，由主管决定是否延长暂停或按现有信息推进。
从这个示例可以提炼几条可迁移的填写要点：暂停类型必须与证据匹配；预计恢复时间要写具体时间点而非“尽快”；恢复事件优先由系统识别，减少人工漏操作；实际暂停时长要自动留痕，作为复核数据。
完成检查：规则上线前要验证的几件事
规则写完后，用一份检查清单逐项核对，判断是否具备执行条件。以下条目可按团队实际情况增删，但每项都应有明确的通过标准。
- 暂停类型覆盖了主要外部等待，且内部排期、审批拖延、人员不足、缺陷修复耗时没有被混入可暂停范围。
- 每个暂停类型都有明确的证据要求和指定的审批人角色，不存在“口头说明即可暂停”的通道。
- 单次暂停上限与累计上限均已设置，超限后有明确的升级路径和责任人。
- 每类暂停的恢复条件都能被系统事件或人工动作可靠触发，恢复后计时口径唯一且写死。
- 暂停数据可按类型、时长、超限次数统计，能够支撑定期复核。
- 抽样验证：选取若干历史工单回放，按新规则重新计算暂停与计时结果，与预期一致；重点检查边界情况，如暂停期间客户回复、审批驳回后重新提交、超限后继续暂停。
抽样验证是上线前最有价值的一步。用历史工单回放能暴露字段缺失、恢复条件不可触发、计时口径歧义等问题，这些问题在规则文本阶段往往看不出来。验证通过后再正式启用，并在启用后的第一个复核周期内重点观察暂停时长占比与超限次数，据此微调上限和审批时限。
常见问题
客户一直不回复，暂停可以无限期延长吗？
不建议无限期延长。规则中应为“等客户补充信息”设置单次最长暂停时长和累计暂停上限，客户超过预计恢复时间未回复时，工单进入超限清单，由主管决定延长暂停、按现有信息推进或调整服务承诺。延长暂停需要重新审批并记录原因，避免暂停变成长期挂起。
暂停期间客户突然回复了，计时怎么处理？
客户回复属于恢复事件，应结束暂停并恢复计时。规则要写明恢复方式：优先由系统识别客户回复事件自动恢复，人工确认作为兜底。恢复后按暂停前已消耗的时间继续累计剩余时限，响应时限与解决时限分别续算，不重新计算整个时限。若客户回复发生在审批通过之前，暂停申请应撤回或驳回，工单保持原计时状态。
审批人不在或审批超时，工单会一直挂着吗？
审批字段需要设置审批时限和超时处理方式。常见做法是工作时间内若干小时未审批按驳回处理，或自动升级到上一级主管。驳回时工单保持原计时状态，发起人补充证据后可重新提交。规则中要明确超时未审批期间工单是否继续计时，避免审批环节本身成为暂停漏洞。
暂停规则上线后，怎么判断它有没有被滥用？
用暂停数据做定期复核。按暂停类型统计暂停时长占比、暂停次数、超限次数和驳回率，观察是否存在某一类型暂停占比异常偏高、同一工单反复暂停、证据缺失仍被审批通过等情况。抽样回放历史工单，核对计时结果与预期是否一致。发现异常时调整类型范围、证据要求或上限设置，而不是直接取消暂停机制。
等变更窗口的暂停，上限应该按什么口径设置？
等变更窗口的暂停上限通常按计划窗口时间加缓冲来设定，而不是套用等客户回复的固定时长。规则中要记录变更单编号和计划窗口时间，暂停截止时间与计划窗口对齐；变更因审批或排期推迟时，需要重新提交暂停申请并附新的窗口时间，不能沿用原申请自动延长。这样暂停时长与实际变更排期挂钩，便于复核时判断等待是否合理。
