工单进入“已受理”或“响应开始”的时点，通常是SLA计时的起点，但真正决定起算的是服务承诺里约定的触发事件。常见起点包括工单创建、首次响应、受理确认和进入处理中状态，不同起点会直接影响响应时长与解决时长的考核结果。本文围绕国内服务日历与工单暂停恢复场景，说明计时边界、暂停恢复机制，以及优先级、严重程度与计时起点的区别。
要点总览（TL;DR）
- SLA计时的起点由服务承诺条款约定，常见触发事件有工单创建、首次响应、受理确认和进入处理中状态，系统配置只是把约定落地。
- 计时按自然日还是工作时间累计由服务日历决定；国内场景要处理法定节假日与调休，日历不准会让承诺余量与实际服务能力错位。
- 暂停只调整计时状态，恢复后从挂起时的已用时长继续累计；暂停期间是否计入承诺时长、暂停是否有上限，都要在条款中写明。
- 优先级影响承诺目标的高低，一般不改变起算事件；缺陷严重程度属于缺陷分级范畴，派单路由只转移处理责任，都不直接定义计时起点。
- 把起算事件、服务日历、暂停恢复条件和终止事件四项写进同一份承诺，并在工单流程中设置对应状态节点与操作记录，计时结果才可复核。
SLA计时起点由哪个事件触发
SLA计时的起点，是服务承诺中约定的那个“开始计算承诺时长”的事件。它由承诺条款定义，系统配置只是把这个约定落地。判断起点是否合理，先看承诺文本写的是哪个事件，再看工单状态流转能否稳定对应这个事件。
常见的四类起点含义不同，适用的服务场景也不同：
| 起点类型 | 含义 | 常见适用场景 | 对指标的影响 |
|---|---|---|---|
| 工单创建 | 用户提交工单、系统生成记录即开始计时 | 自助报障、门户提交、邮件转工单 | 响应时长包含受理前的排队时间，对服务方压力较大 |
| 首次响应 | 服务人员第一次有效回复客户时开始计时 | 以响应速度为核心承诺的支持服务 | 响应时长从首次回复起算，解决时长通常另设起点 |
| 受理确认 | 工单被接单、分派或确认属于服务范围时开始计时 | 需要先做范围判断或责任归属确认的场景 | 起算前的时间不计入承诺，需明确受理时限以免无限延后 |
| 进入处理中 | 工单状态变为“处理中”、实际投入处理时开始计时 | 解决时长考核为主、处理动作清晰的场景 | 解决时长从处理开始累计，排队与等待期被排除 |
起点选择会改变两类指标的算法。响应时长关注“多久给出第一次有效回应”，解决时长关注“多久把问题处理完”。如果响应时长以工单创建为起点，排队时间就被计入响应考核；如果解决时长以进入处理中为起点，受理前的等待就不进入解决时长。两类指标可以各自设定起点，不必共用同一个事件。
实践中容易出现的问题是承诺文本写“受理后开始计时”，但工单状态里没有独立的“已受理”节点，受理动作和开始处理混在一起，导致起算时点无法稳定判定。解决办法是把承诺中的触发事件映射到明确的状态节点，并规定该节点的操作人和操作要求。
SLA计时的边界：哪些时间算、哪些不算
确定起点之后，还要确定计时按什么时间口径累计。同样一段真实经过的时间，按自然日计算和按工作时间计算，得到的承诺余量差别很大。服务日历就是用来定义哪些时段属于服务时间、哪些时段不计入的规则集合。
| 时间类型 | 是否计入承诺时长 | 说明 |
|---|---|---|
| 服务日历内的工作时间 | 计入 | 按承诺条款约定的工作日、工作时段累计 |
| 非工作时间（夜间、周末） | 通常不计入，需条款明确 | 按工作时间口径计时时跳过；按自然日口径计时则计入 |
| 法定节假日与调休 | 依服务日历配置 | 国内场景需处理调休上班日，日历应能体现实际作息 |
| 暂停时段 | 依暂停规则约定 | 等待客户补充信息、等待第三方处理等情形可挂起 |
| 暂停结束后的恢复时段 | 计入 | 恢复后继续累计剩余承诺时长 |
自然日口径适合7×24小时服务或对连续时长有要求的承诺；工作时间口径适合只在工作时段提供支持的服务团队。两种口径都要求服务日历本身准确，尤其是国内常见的调休安排：如果日历没有同步调休，按工作时间计算的承诺余量就会与实际服务能力错位。
暂停时段是否计入承诺时长，取决于暂停规则怎么写。常见写法是暂停期间不计入承诺时长，恢复后继续累计；也有承诺把某些等待期仍然计入，以约束服务方主动推动。无论哪种写法，都应在条款中列明可暂停的情形、暂停的发起与确认方式，以及暂停时长是否有上限。暂停是一种计时状态调整，不自动构成责任豁免，超时与否仍要看恢复后的累计结果。
计时机制：从起算到暂停、恢复与停止
SLA计时可以理解为一条随工单状态变化而累计、挂起、恢复和终止的时间线。它的运行依赖三个要素：起算事件、暂停与恢复条件、终止事件。三者都应在承诺条款和工单流程中同时定义。
计时状态的基本流转如下：
- 待起算：工单已创建，但约定的起算事件尚未发生，此时不累计承诺时长。
- 计时中：起算事件发生，按服务日历累计已用时长，并与承诺目标比较。
- 已挂起：满足暂停条件，计时停止累计，工单保留当前已用时长。
- 恢复计时：暂停条件解除，从挂起时的已用时长继续累计。
- 计时终止：达到承诺的完成事件，计时停止，据此判定是否超时。
暂停的触发条件需要具体到可操作的动作。常见情形包括：等待客户补充必要信息、等待第三方厂商处理、等待客户确认处理方案、客户侧环境暂不可用。触发方式可以是服务人员发起并记录原因，也可以是工单状态切换到约定的挂起状态。恢复条件与暂停条件对应：客户补充信息、第三方返回结果、客户确认方案后，工单回到处理中状态并恢复计时。
计时终止的判定时点同样要写清楚。响应时长的终止事件通常是首次有效响应发出；解决时长的终止事件通常是工单标记为已解决或已关闭。如果以“客户确认解决”为终止，那么客户长时间不确认的时段如何处理，也需要在条款中约定，例如设置自动确认期限。
在国内服务日历场景下，暂停与恢复还要与工作时间口径配合。例如工单在周五下班前进入暂停，周一上班后客户补充信息并恢复计时，中间周末时段按工作时间口径本就不计入，暂停与日历规则叠加后，实际累计的承诺时长只包含有效服务时间。这类叠加规则应在条款中说明，避免双方对剩余时长产生分歧。
当工单状态、暂停原因和计时结果需要在同一处被团队看到时，可以把这些动作放到工单管理工具中承载。ONES Desk 支持灵活调整工作流以适应不同企业的工作方式，也支持集中管理工单状态、处理进度和责任分工，便于把起算、挂起、恢复对应的状态节点固定下来，减少信息分散带来的判定争议；具体计时与日历配置能力以产品实际配置和厂商说明为准。
SLA计时与优先级、严重程度的区别
优先级和严重程度经常与SLA一起出现，但它们回答的是不同问题。优先级决定“先处理谁、承诺多快”，严重程度描述“问题本身有多重”，计时起点回答“从哪个事件开始算”。把三者混为一谈，容易出现“高优先级所以提前计时”或“严重缺陷所以暂停不算”的错误推论。
| 概念 | 回答的问题 | 与计时起点的关系 |
|---|---|---|
| 优先级 | 工单处理顺序与承诺目标高低 | 影响承诺目标（如响应时限长短），一般不改变起算事件 |
| 缺陷严重程度 | 软件缺陷对业务的影响等级 | 属于缺陷分级范畴，不直接定义SLA计时起点 |
| 派单路由 | 工单分给哪个团队或人员 | 影响受理与处理动作由谁完成，不改变承诺约定的起算事件 |
| SLA计时起点 | 承诺时长从何时开始累计 | 由服务承诺条款约定，与优先级、严重程度分属不同维度 |
优先级与SLA的常见配合方式是：不同优先级对应不同的响应时限和解决时限，例如高优先级承诺更短的响应时间。这里变化的是承诺目标值，起算事件仍按条款统一执行。ONES Desk 支持评估和定义工单优先级，优先解决紧急事件，这类能力用于处理顺序管理，计时起点仍需按承诺条款单独约定。
派单路由与计时起点的关系也常被误解。工单被分派给某个团队，只是处理责任的转移；如果承诺以“受理确认”为起点，那么分派动作可能同时构成受理，也可能只是路由动作，取决于流程定义。把路由节点误当作起算节点，会让计时提前或延后，因此需要在流程设计时明确哪个节点对应承诺中的触发事件。
具体例子与常见误解
下面用一个演示情景说明含暂停恢复的完整计时过程。情景设定为工作时间口径：服务时间为工作日9:00至18:00，中午12:00至13:00为休息时段，承诺解决时长为8个服务小时，起算事件为受理确认，暂停情形为等待客户补充信息。
- 周一10:00，工单创建，尚未受理，不计时。
- 周一10:30，服务人员受理确认，计时开始，已用0小时。
- 周一11:30，已用1小时；服务人员发现缺少日志，发起暂停并记录原因，计时挂起。
- 周一12:00至13:00为休息时段，不计入服务时间。
- 周一14:00，客户补充日志，工单恢复计时，从已用1小时继续累计。
- 周一18:00，当日服务时间结束，累计至5小时。
- 周二9:00恢复累计，10:00累计至6小时，11:00累计至7小时，12:00累计至8小时，达到承诺目标。
这个例子中，暂停期间和休息时段都没有计入承诺时长，恢复后从挂起时的已用时长继续累计。如果暂停规则约定暂停时长有上限，或某些等待期仍计入，结果会相应变化，因此条款必须写清。
常见误解主要有三类：
- 创建即计时：认为工单一旦创建就开始计算承诺时长。实际起算事件由承诺约定，可能是创建，也可能是受理确认或首次响应。
- 暂停即免责：认为只要工单进入暂停，超时责任就自动免除。暂停只调整计时状态，是否超时仍看恢复后的累计结果，且暂停需符合约定条件并有记录。
- 优先级决定起点：认为高优先级工单会更早开始计时。优先级通常改变承诺目标值，起算事件仍按条款统一执行。
把起算事件、服务日历、暂停恢复条件和终止事件四项写进同一份服务承诺，并在工单流程中设置对应的状态节点与操作记录，计时结果才具备可复核性。团队还可以借助工单处理情况的汇总视图了解进度把控情况，定期核对暂停记录与超时判定是否一致，及时修正条款与流程之间的偏差。
常见问题
工单创建后一直没人受理，这段时间算不算SLA计时？
取决于承诺约定的起算事件。如果条款写明以工单创建为起点，排队等待受理的时间就计入承诺时长；如果以受理确认或首次响应为起点，受理前的等待不计入。
以受理确认为起点时，需要同时约定受理时限，否则工单可能长期停留在待受理状态而承诺计时尚未开始。实践中可以把受理时限作为单独指标管理，避免起算规则被用来延后计时。
暂停期间客户一直不回复，工单会无限期挂起吗？
条款可以约定暂停时长上限，或规定客户在约定期限内未回复时按自动恢复计时、自动关闭等方式处理。没有这类约定时，挂起状态容易长期保留，承诺时长无法得出最终判定结果。
建议在暂停规则中写明可暂停情形、发起与确认方式、单次与累计暂停上限，以及超限后的处理动作，让暂停有明确的退出路径。
按工作时间口径计时，遇到国内调休上班日怎么处理？
调休上班日是否计入服务时间，取决于服务日历的配置。日历应体现企业实际作息：调休上班的周六按工作日处理，法定节假日按非服务时间处理。
如果日历没有同步调休安排，按工作时间计算的承诺余量会与实际服务能力错位，可能出现服务方在岗但系统不计时，或休息日被计入承诺的情况。上线前应核对全年节假日与调休安排。
响应时长和解决时长可以设不同的计时起点吗？
可以。两类指标考核的对象不同：响应时长关注多久给出第一次有效回应，解决时长关注多久把问题处理完，各自设定起点更贴合实际。
例如响应时长以工单创建为起点，解决时长以受理确认为起点。需要分别写清各自的起算事件、暂停规则和终止事件，避免两个指标共用一套规则导致判定口径混乱。
用ONES Desk管理工单时，SLA计时能直接配置吗？
ONES Desk 支持灵活调整工作流以适应不同企业的工作方式，也支持集中管理工单状态、处理进度和责任分工，可以把起算、挂起、恢复对应的状态节点固定下来，减少信息分散带来的判定争议。
SLA计时、暂停恢复与服务日历的具体配置能力，以产品实际配置和厂商说明为准，选型时建议向厂商核验起算规则如何设置、日历如何维护。
