工单SLA计时不准，通常先分成两类来源：规则表本身配置有偏差，或边界条件没有被规则覆盖。排查时先确认异常工单的计时口径，再逐条比对命中的规则表条目，最后用跨天、暂停、重开等边界场景做验证，判断是规则缺失、条件冲突还是事件未触发，避免一上来就改配置。
要点总览（TL;DR）
- 先确认异常工单的计时口径：起止事件、工作日历、暂停条件、响应与解决两类承诺，口径不清就无法比对规则表。
- 规则表按“条件—动作—优先级”顺序核对，重点看条件字段未覆盖、起止事件或日历绑定错误、多条规则同时命中导致的优先级错位。
- 边界条件按跨天跨周末、暂停恢复、重开改派、优先级变更四类逐项验证，记录预期与实际，用差异判断是规则缺失、条件冲突还是事件未触发。
- 处置按影响面从小到大推进：先补缺失规则，再处理冲突与优先级，最后调整日历与暂停条件；修改前备份，验证不通过时回退。
- 把六类边界场景做成回归用例集，在规则表、日历、暂停条件变更后执行，并定期抽查计时结果与命中记录。
计时不准的表现与排查范围
“计时不准”是一个笼统描述，先把它拆成可观察的症状，才能判断问题落在规则表还是边界条件。常见症状有四种：剩余时间在刷新后突然跳变；工单进入暂停状态后计时仍在走；跨天或跨周末后剩余时长与预期偏差明显；工单重开后计时归零或延续，与团队约定不一致。不同症状指向的排查方向不同，跳变多与规则命中变化有关，暂停后仍走表多与暂停条件或事件绑定有关，跨天偏差多与日历口径有关。
在比对任何配置之前，先确认异常工单的计时口径。口径确认包括四项内容：起止事件是什么，从创建开始计时还是从受理、分派开始，到解决结束还是到关闭结束；计时使用工作日历还是自然日，工作日历中的工作日、服务时段、节假日如何定义；暂停与恢复由哪些条件触发，暂停期间是否完全停止计时；工单涉及的是响应类承诺还是解决类承诺，两类承诺的起止事件通常不同。口径没有确认清楚，后续比对规则表就没有基准。
| 确认项 | 需要记录的内容 | 用途 |
|---|---|---|
| 起止事件 | 开始计时的事件、停止计时的事件 | 判断计时区间是否与承诺定义一致 |
| 计时日历 | 工作日历或自然日、服务时段、节假日 | 解释跨天、跨周末偏差 |
| 暂停条件 | 触发暂停的状态或字段、恢复条件 | 解释暂停后仍走表或恢复后未续算 |
| 承诺类型 | 响应承诺、解决承诺及各自目标时长 | 区分两类承诺的偏差来源 |
排查范围同样需要收敛。先确认异常是集中在单条规则、某一类工单，还是某个时间段内提交的工单。单条规则异常通常指向该规则的条件或动作配置；某类工单集中异常通常指向匹配字段未覆盖；某个时间段集中异常则要优先检查该时间段内是否有规则变更、日历调整或批量改派。范围划得越具体，后续核对的工作量越小。
规则表逐项核对：条件、动作与优先级
规则表核对按“条件—动作—优先级”的顺序推进，每一步都留下记录，避免凭印象判断。核对的对象是异常工单实际命中的规则条目，而不是规则表里的全部条目。
第一步核对规则条件。逐项检查工单类型、优先级、来源渠道、客户等级等匹配字段，确认异常工单在这些字段上的取值能够命中预期规则。常见偏差是条件写得过窄，例如只匹配了某一来源渠道，其他渠道的同类型工单落入默认规则；或者条件之间是“且”的关系，实际工单只满足其中一部分。核对时把异常工单的字段取值与规则条件并列记录，能直接看出是否匹配。
第二步核对规则动作。动作包括起止事件绑定、计时日历、暂停条件、目标时长四项。起止事件绑定错误会让计时区间整体偏移；计时日历选错会在跨天场景集中暴露；暂停条件缺失会让本应停表的工单继续计时；目标时长填错则表现为所有命中该规则的工单统一偏差。动作类偏差往往影响面较大，核对时优先看是否有整批工单呈现相同偏差。
第三步核对规则优先级与命中顺序。多条规则同时满足条件时，系统按优先级取其中一条执行，优先级设置不当会造成“以为命中A规则、实际命中B规则”。另一种情况是所有规则都不命中，工单落入默认规则或不计时。核对方法是先记录异常工单实际命中的规则，再反查该规则为何被选中，确认是优先级排序问题还是条件重叠问题。
| 核对项 | 检查内容 | 典型偏差 |
|---|---|---|
| 规则条件 | 工单类型、优先级、来源渠道、客户等级等字段取值 | 条件过窄、字段未覆盖、多条件组合不满足 |
| 规则动作 | 起止事件、计时日历、暂停条件、目标时长 | 事件绑定错误、日历选错、暂停条件缺失 |
| 优先级与命中 | 多条规则同时满足时的选中结果 | 优先级错位、条件重叠、全部不命中 |
核对过程中要区分假设与证据。看到“暂停后仍在走表”，先把它记为假设，再用异常工单的实际命中规则、状态变更时间和计时记录去验证。只有命中记录与计时明细能对应上，才能把假设转为结论。缺少命中记录时，可以用同类工单构造一条测试工单，观察它命中的规则和计时结果，作为补充证据。
边界条件排查：跨天、暂停、重开与变更
规则表核对通过后仍有偏差，问题通常落在边界条件。边界场景按四类逐项验证，每类记录预期值、实际值和结论，用差异定位原因。
跨天与跨周末验证的重点是日历口径是否一致。选取周五下午提交、周一上午解决的工单，分别按工作日历和自然日计算应消耗时长，与系统显示的实际计时对比。如果规则表配置的是工作日历，但计时结果按自然日推进，偏差会集中在周末和节假日；如果服务时段设置与实际排班不符，偏差会出现在每日的固定时段。验证时同时检查日历配置是否被后续调整过，历史工单可能仍按旧日历计算。
暂停与恢复验证要确认两件事：暂停条件触发后计时是否真正停止，恢复后是否从暂停点续算。选取一条进入过暂停状态的工单，核对暂停开始时间、恢复时间与计时明细，确认暂停区间是否被扣除。常见偏差是暂停条件绑定的状态与实际使用的状态不一致，工单实际已暂停但规则未识别；或者恢复后计时重新起算，导致暂停前已消耗的时长丢失。
重开与改派验证关注计时归属。重开后计时是重置还是延续，取决于团队约定和规则配置，两种做法都可能正确，关键是实际行为与约定一致。改派会影响工单归属人和所属队列，如果规则按队列或处理人匹配，改派后可能命中另一条规则，计时口径随之变化。验证时记录改派前后的命中规则和计时结果，确认变化是否符合预期。
优先级或承诺变更验证关注规则是否重新匹配。工单优先级上调后，如果规则表按优先级匹配目标时长，系统应重新计算剩余时间；如果仍沿用变更前的规则，就会出现计时与当前优先级不匹配。验证时记录变更时间点、变更前后的命中规则和剩余时间，确认旧计时是重新计算、按比例折算还是保持不变，并与团队约定对照。
| 边界场景 | 预期 | 实际 | 结论 |
|---|---|---|---|
| 跨天与跨周末 | 按配置日历扣除非服务时段 | 待填 | 日历口径是否一致 |
| 暂停与恢复 | 暂停区间不计时，恢复后续算 | 待填 | 暂停条件是否生效 |
| 重开 | 按约定重置或延续 | 待填 | 行为是否与约定一致 |
| 改派 | 按新归属匹配规则或保持原规则 | 待填 | 归属变化是否影响计时 |
| 优先级或承诺变更 | 重新匹配规则并调整剩余时间 | 待填 | 旧计时处理是否符合约定 |
处置步骤与恢复验证
排查结论明确后，处置按风险从低到高推进，每一步都保留可回退的状态。
- 备份现有规则表与日历配置，记录修改前异常工单的命中规则和计时结果。备份是后续回退的依据，也是验证修改效果的对照基准。
- 先补缺失规则。条件未覆盖、动作缺失这类问题影响面明确，补充后即可用同类工单验证，风险较低。
- 再处理条件冲突与优先级错位。调整优先级会改变多条规则的命中结果，修改前先列出受影响的规则组合，修改后用构造工单逐组验证。
- 最后处理日历与暂停条件的调整。这类修改影响所有使用该日历或该暂停条件的工单，影响面最大，放在最后执行。
验证分两部分。第一部分用历史异常工单回归，确认修改后这些工单的计时结果符合预期；第二部分用构造的边界用例验证，覆盖跨天、跨周末、暂停恢复、重开、改派、优先级变更六类场景。两部分都通过，才能认为修复完成。
验证不通过时回退到备份配置，重新核对排查结论。回退前记录本次修改的内容和验证失败的场景，避免在回退后重复同样的调整。修改规则表属于影响面较大的操作，建议在业务低峰期执行，并提前告知受影响的处理团队。
在ONES Desk中，工单优先级可以被评估和定义，工作流与工单属性支持自定义配置，这些配置项是规则表核对时需要用到的输入。核对时可以把异常工单的优先级、类型、来源等字段取值与规则条件对照，确认匹配关系；修改后借助工单分析报表观察计时结果的变化趋势。SLA计时规则表的具体配置入口和字段以实际使用版本的配置界面为准。
复发预防与日常检查
一次性排查解决的是当前偏差，规则表再次失准往往发生在变更之后。把验证动作固化成可重复的检查项，能降低复发概率。
建立规则表变更后的回归用例集。用例集至少覆盖跨天、跨周末、暂停恢复、重开、改派、优先级变更六类场景，每次修改规则表、日历或暂停条件后执行一遍，记录预期与实际。用例集随业务变化补充，新增工单类型或承诺类型时同步增加对应用例。
定期抽查计时结果与规则命中记录。抽查对象包括近期解决的工单和仍在计时中的工单，重点看命中规则是否符合预期、剩余时间变化是否连续。抽查频率可以根据规则变更频率确定，变更频繁时缩短间隔。
新增工单类型、优先级或调整日历时做同步检查。新增类型要确认是否有规则覆盖，避免落入默认规则；新增优先级要确认目标时长和匹配条件已配置；日历调整要确认历史工单与新工单的口径区分清楚。
| 检查项 | 触发时机 | 记录内容 |
|---|---|---|
| 回归用例执行 | 规则表、日历、暂停条件变更后 | 用例、预期、实际、结论 |
| 计时结果抽查 | 按固定周期 | 工单、命中规则、剩余时间变化 |
| 新增配置同步检查 | 新增工单类型、优先级或调整日历 | 覆盖规则、目标时长、口径说明 |
| 异常工单留档 | 每次计时异常处理后 | 症状、命中规则、根因、处置、验证结果 |
异常工单的留档字段建议包括症状描述、异常工单标识、命中规则、根因分类（规则缺失、条件冲突、事件未触发、日历口径）、处置动作和验证结果。留档积累到一定数量后，可以按根因分类统计，找出高频偏差类型，在下一次规则表调整时优先加固。
常见问题
规则表核对通过，边界场景也验证了，计时仍有偏差，下一步查什么？
先确认偏差是否集中在某个时间段提交的工单。如果集中在某几天，优先检查该时间段内是否有规则表变更、日历调整或批量改派，历史工单可能仍按旧配置计算。其次核对计时事件是否真正触发，例如状态流转没有按预期发生，规则条件满足但起止事件未被记录。最后检查是否存在规则表之外的计时来源，例如手工调整过剩余时间或导入过历史工单。排查时保留工单的状态变更时间线，与计时明细逐条对照。
多条规则同时满足条件时，怎么确认实际生效的是哪一条？
用异常工单反查命中记录，确认系统实际选中的规则，再对照规则表的优先级排序，判断选中结果是否符合设计。如果命中记录不可查，可以构造一条字段取值与异常工单相同的测试工单，观察它命中的规则和计时结果。确认是优先级错位后，调整前先列出受影响的规则组合，修改后逐组用构造工单验证，避免修正一处又影响另一处。
暂停后计时仍在走，通常是什么原因？
常见原因是暂停条件绑定的状态或字段与工单实际使用的状态不一致，工单在业务上已暂停，但规则没有识别到暂停事件。另一种情况是暂停条件已触发，但恢复时计时重新起算，导致暂停前已消耗的时长丢失。核对时取一条进入过暂停的工单，比对暂停开始时间、恢复时间与计时明细，确认暂停区间是否被正确扣除，再检查规则中暂停条件与工作流状态的对应关系。
修改规则表应该在什么时间做，需要提前准备什么？
规则表修改影响所有命中该规则的工单，建议在业务低峰期执行，并提前告知受影响的处理团队。修改前备份现有规则表与日历配置，记录异常工单修改前的命中规则和计时结果，作为回退依据和验证对照。修改后先用历史异常工单回归，再用构造的边界用例验证；验证不通过时回退到备份配置，并记录失败场景，避免回退后重复同样的调整。
新增工单类型或优先级后，怎么避免计时规则漏配？
新增类型或优先级时同步检查三件事：是否有规则覆盖该类型，避免工单落入默认规则；目标时长与匹配条件是否已配置；回归用例集是否补充了对应场景。上线前用一条该类型的测试工单走完整流程，确认命中的规则、计时日历和剩余时间符合预期。ONES Desk 支持自定义工单属性与工作流配置，具体字段和规则配置入口以实际使用版本的界面为准。
