服务级别协议、日历与升级

期限在“Settings → SLA”里设置。这个页面在没有生效策略时会在上方明说。一条策略有三部分：一个名称、若干条件和若干目标。新策略刻意以未生效的状态创建，这样您可以先把它配好，再让它开始起作用。

条件是“Team”、“Priority”、“Main category”和“Subcategory”。留空表示“任意”，也就是“适用于所有”，不是“不适用于任何”。如果有多条策略命中，“Order”里数字最小的那条胜出；所以窄的策略排在上面，通用的排在下面。

两个分类字段是按团队分组的，因为分类属于团队，但系统会把所有分类都提供给您，包括别的团队的。这是有意为之：转交时工单会走，分类不会。帮助台转交给网络团队的工单仍然带着帮助台的分类，而一条策略正可以指向它。选定主分类之后，下面的字段只提供与之关联的子分类，一个工单上不可能出现的组合在保存时会被拒绝。

每条策略有两个目标。“Time to first response”在客服人员写下第一条对客户可见的回复时结束，自动确认信和内部备注明确不算。“Time to resolution”在工单进入一个算作已解决的状态时结束（哪些算，您在“Settings → General → Status”里设置）。两个目标各有自己的分钟数、自己的日历，以及自己对超时的反应。

在工单上，期限位于右侧的“Details”卡片里，下面是“Show deadline history”：一份记录每一步的日志，开始、暂停、恢复、达成、超时，每一条都带原因和已用掉的工作时间。只有客服人员和管理员看得到它，客户那边根本调不出来。

如果之后有人改了优先级或团队，计时器会切换到当时匹配的那条策略：此前用掉的工作时间按旧日历结清，之后按新值算。如果再也没有策略匹配，计时器就没有结论地结束，既不算达成，也不算超时。

如果创建工单时没有匹配的策略，计时器会在某次改动之后第一次有策略匹配时启动，比如优先级调高了。它从那一刻开始计算。首次响应的计时器只有在还没有人回复时才会启动。

只有工单被重新打开时才会产生新的计时器。其他状态变动不会创建新的计时器。

日历说明计时器什么时候走。它有一个名称、自己的时区，以及每个工作日任意多个时段，午休就是一天里有两个时段。一个时段可以跨过午夜，那时旁边会写着“ends next day”。

一个团队用哪份日历，在团队上设置（“Settings → Teams”）。在策略的单个目标上还可以覆盖它：“From the team”用团队那份，或者您另选一份。常见的做法正是这么来的：故障不分昼夜地算，其他的只在办公时间算。

算的是时段之内真正流逝的时间，不是两个钟点读数之间的差。在夏令时切换时这就有区别了：十月里一个全天候的日子有 25 小时，春天里 22:00 到 06:00 的夜班只有七小时而不是八小时。09:00 到 17:00 的办公时段永远不受影响，因为在欧盟切换发生在夜里。

如果找不到任何有营业时间的日历，就不会生成期限，宁可没有，也不要猜一个。工单上出现的是一条提示，而不是一个日期。

每份日历下面都有“Closed days”清单。点一下“Import holidays (.ics)”接收一个日历文件，之后会报告四个数字：接收了多少天、替换了多少天、有多少读不出来，以及有多少本来就有。您也可以手工录入单个日期。

日期后面的 ↻ 符号表示“每年重复”。它只对固定日期正确：10 月 3 日每年都是同一个日期，而耶稣受难日和圣灵降临节星期一挂在复活节的日期上，会移动。所以移动的假日会按年份以具体日期列在清单里，图里的“Good Friday”就没有这个符号。

一个休息日会吞掉这一天的整个时段，包括伸进第二天的那一部分。而当一份日历在未来十二个月里一个休息日都没有时，页面会明确说明这一点，否则系统会不声不响地把假日算进去，得出错误的期限。

关于期限最常见的争论就是这一条：工单已经等客户回话三天了，计时器还照走不误。所以每个目标都有“Pause while waiting for the requester”开关，是按目标分别设的，不是整条策略一起。

是不是在等，由状态决定：在“Settings → General → Status”里，每种状态都带一个标记，说明它是否算“在等请求者”。开关打开时，工单处于这样的状态期间，期限就歇着。挂钟时间照常走，所以列表里显示的是“Paused”而不是剩余时间，期限历史里则有带时间的“Paused”和“Resumed”。如果工单直接从这样的状态被解决，等待的时间同样不计入。

对首次响应，通常把这个开关关着：不管在等什么，第一条回复都是您欠着的。对解决，通常是打开的。图里正是这样的设置。

只要有一条策略生效，工单列表就会多出“Deadline”列。它显示下一个未结期限的剩余时间（“14h 53m”）。等工单上再没有正在走的期限时，那里显示的就是结论：达成的是“In time”标记，超时的是红色的“Breached”。完全没有计时器的工单显示一个中性的短横线，这是有意为之：策略生效之前的工单不算失败。

如果没有生效的策略，这一列干脆不出现，而不是空着摆在那儿。筛选也一样：只有确实存在期限时，“Filter”里才会出现“Breached only”这个勾选项。

一张工单有两个计时器，而这一列只有一个位置，它显示的是最紧迫的那个未结期限。如果首次响应已经超时而解决还在走，这一列显示的是解决的剩余时间，旁边带一个红色的“!”。这个标记的意思是：这张工单上已经有一个期限超时了，而“Breached only”筛选找的正是这个，因为它问的是有没有任何超时的期限，包括早已结束的那种。到底是两个里的哪一个，写在工单本身里。

还可以按它排序：同一个“Deadline”标题下有一个字段，可选“Due soonest first”和“Due latest first”。没有正在走的计时器的工单永远排在最后，它们不是最不紧急，而是根本不涉及。按期限排序优先于按“Updated at”排序：没有哪份列表能同时满足两种顺序。

每个目标都可以在“When breached”下面设定超时后发生什么：“Record only”只做记录，“Notify assignee and observers”给负责人和关注者发一封邮件（不是发给整个团队），“Hand over to another team”把工单转交出去。转交必须选一个目标团队，没有选的策略在保存时会被拒绝，因为它看着配好了，实际什么也不做。

这个动作对每个计时器只执行一次。没有这道闩，服务器一重启就会把同一封邮件再发一遍。就算发送失败，“已执行”标记也会被设上，因为一封没送到的邮件，好过一个每分钟都新发一封的循环。

超时本身以它到期的那一刻为准，而不是以检查运行的时刻为准，否则报表就会挂在检查服务的节奏上。而且它是按用掉的工作时间衡量的：暂停中的计时器不会超时，哪怕到期日早就过去了。

转交会把状态重置为“Open”。相关的历史记录是内部的；客户在工单上只看到新的状态和新的团队。

在“Reports”里选好时间段，按“Generate report”，不点这一下页面就是空的。报表随后包含“Service level agreements”一块，每个目标一行：达成、超时、仍在进行、达成率和平均用时。

统计是按目标算的，不是按工单算的，表格下面也这么写着。所以一张两个目标都有的工单会出现两次，每一行里各一次。

达成率只统计已有结论的计时器。还在走的不属于分母，否则每一套刚打开的服务级别协议一开始都会显得糟透了，然后自己慢慢变好。如果一个有结论的计时器都还没有，显示的是一个短横线，而不是“0 %”。

如果您用群体故障，还会多出一行“Achieved without group incidents”：一次群体故障挂上一百张工单，否则会把达成率往两个方向都带偏。这一行不计入任何与群体故障关联的工单。

客服人员在这一块里只看到自己的团队。没有 Professional 时，只有存在以前的期限数据，这一块才会出现，而且仍然可以查看。