Deskhero
中文
免费试用

← Back to articles

如何自动化SLA提醒，避免升级为违约

如何自动化SLA提醒，避免升级为违约

自动化 SLA 提醒应在仍有时间采取行动时显示工单，然后让逾期工单变得一目了然。正确的设置取决于帮助台。有些平台提供原生的即将到期和违约提醒，而自定义工作流可能需要定时检查和明确的升级步骤。

先从计时规则开始，而不是通知：

  • 为首次回复和解决分别定义目标。
  • 决定目标使用日历时间还是工作时间。
  • 选择哪些工单状态会暂停解决计时器。

专业提示： 在依赖实时提醒之前，使用示例工单测试每种 SLA 状态。包括即将到期、已违约、已暂停、已重新分配和已完成的情况。

要点总结

可靠的提醒始于准确的截止时间。提醒时间、接收人和升级流程，都应建立在策略本身正确的基础上。

要点 详情
定义两种计时器 分别跟踪首次回复和解决，因为它们会在不同事件发生时结束。
遵循工作时间 当夜间和周末不应计入目标时，使用工作时间安排。
配置暂停状态 当工单等待客户或其他外部相关方处理时，暂停解决目标。
有意选择接收人 确保即将到期和违约提醒能够发送给有能力处理工单的人。
上线前进行测试 使用受控工单验证截止时间、暂停行为和通知送达情况。
优先使用原生 SLA 功能 具备内置策略、工作时间安排、提醒、筛选器和报告功能的帮助台，可以避免单独设置轮询工作流。

接下来可参考的权威文档和操作指南

如需了解特定平台的示例，请参阅 Jira 的自动跟进文档。其中介绍了定时规则和 SLA 阈值方法，并建议先针对较小的查询范围进行测试，再逐步扩大范围。

目录

逐步构建 SLA 提醒自动化

在配置提醒之前，准确写下每个 SLA 衡量的内容。首次回复目标和解决目标是两种不同的计时器。确定每个计时器由哪个工单事件启动、由哪个事件完成，以及截止时间遵循日历时间还是工作时间安排。

然后配置提醒路径。

  1. 定义策略。将团队和优先级映射到首次回复和解决目标。为不符合更具体规则的工单添加兜底策略。
  2. 设置工作日历。添加适用于该目标的工作时间和时区。如果承诺持续运行，请使用日历时间。
  3. 配置暂停行为。选择团队等待信息时会停止解决计时器的状态。确认首次回复计时器是否可以暂停，因为许多系统对它的处理方式不同。
  4. 启用通知。决定谁接收即将到期和已违约状态的通知，以及帮助台将使用哪些受支持的渠道。
  5. 添加操作响应。记录接收人应采取的行动，例如回复、更改优先级、重新分配或请负责人介入。通知和纠正行动不必属于同一条技术规则。

如果帮助台缺少原生 SLA 阈值，定时工作流可以检查未关闭工单，并将其截止时间与当前时间进行比较。LOW/CODE 记录了一个每 15 分钟轮询一次的示例，但适当的间隔取决于最短目标、API 限制、工作时间以及团队可以容忍的延迟。请保存提醒状态，避免后续运行重复发送相同通知。

选择不会引发提醒疲劳的阈值

有用的警告应为接收人留出足够的响应时间。在自定义系统中，百分比阈值可能有效，但对于时长不同的策略，固定的警告时间窗口通常更容易理解。

  • 时间充裕：让工单继续显示在常规队列视图中，但不要发送警告。
  • 即将到期：在目标仍有机会达成时，通知负责的用户或团队。
  • 已违约：将工单标记为逾期，并遵循团队记录在案的升级流程。

不要在检查底层目标之前就照搬通用的 80% 阈值。对于一小时的目标，它只剩 12 分钟；而对于三天的目标，则还剩半天以上。请衡量团队实际需要多少行动时间。

重复提醒很快就会造成噪音。原生帮助台提醒应在状态转换时发送，而不是每次刷新页面都发送。自定义轮询工作流应记录已发送即将到期或违约通知，并且只有在策略真正重新开始时才重置该状态。

选择不会引发提醒疲劳的阈值：概览图

SLA 提醒应包含哪些内容以及应发送到哪里

提醒应标明工单、显示截止时间，并明确说明预期响应。避免添加接收人不需要的客户数据。

  • 工单 ID 和链接，方便接收人打开正确的对话。
  • 目标类型，例如首次回复或解决。
  • 截止时间或逾期时长，并使用明确无歧义的时区。
  • 当前状态、优先级、团队和负责人，当这些字段会影响归属时尤其需要提供。
  • 一个下一步行动，例如回复、重新分配或请负责人审核。

使用支持团队已经在监控的渠道。当应用内通知和电子邮件能够可靠地触达负责人或相关团队时，它们通常就足够了。如果需要单独的呼叫或消息系统，请先确认帮助台支持该集成，再围绕它设计流程。

专业提示： 显示精确的截止时间或倒计时。具体时间比模糊的警告更容易帮助人们确定优先级。

SLA 提醒应包含哪些内容以及应发送到哪里：概览图

通过暂停状态确保 SLA 计时器准确

提醒是否可信，取决于计时器是否准确。解决目标通常会在工单等待客户处理时暂停，但具体状态应与团队的实际工作流程保持一致。

  • 选择明确的暂停状态，并记录每个状态停止计时的原因。
  • 工单离开暂停状态后恢复计时。
  • 测试多次进入和离开暂停状态的工单。
  • 确认首次回复和解决目标是否遵循相同的暂停规则。

工作时间安排解决的是另一个问题。它会从目标本身中排除非工作时间，而暂停状态则根据工单状态排除时间。请同时配置并测试两者。周末不应消耗工作时间目标；而工作日等待客户处理的工单，即使团队处于工作时间，也应保持暂停。

在信任自动化之前进行测试和调优

使用受控工单测试完整生命周期。历史数据有助于确定现实可行的目标，但实时状态测试更适合验证通知送达和截止时间变化。

  1. 覆盖每项策略。为每种可能选择不同 SLA 策略的团队和优先级组合创建测试工单。
  2. 使用较短的临时目标。无需等待数小时或数天即可确认即将到期和已违约状态，然后恢复真实数值。
  3. 测试暂停状态。暂停并恢复解决计时器，验证截止时间是否按预期变化。
  4. 检查接收人。分别测试已分配和未分配的工单，确保正确的人员收到相应通知。
  5. 检查记录。确认工单显示所应用的策略，以及每个计时器何时达成或错过。

上线后，检查误报和交接遗漏。如果提醒准确却仍被忽略，问题可能出在归属或人员配置上，而不是阈值时间设置。

Deskhero 如何为你处理 SLA 提醒

Deskhero 提供专用的 SLA 策略。这些策略与其通用自动化规则分开，后者不按计划运行，也不基于时间。

  • 所有者和管理员可以排列与工单团队及优先级匹配的 SLA 策略。第一个匹配的策略会设置首次回复和解决目标。
  • 每项策略都可以使用带有独立时区的命名周工作时间安排，也可以按日历时间计时。
  • 解决计时器会在工作区选择的状态下暂停。首次回复计时器不会暂停。
  • Deskhero 会在下一个截止时间前最后 60 分钟内将工单标记为有风险，并在截止时间过后将其标记为已违约。
  • 后台检查每五分钟运行一次，并向负责人发送应用内通知和电子邮件摘要；如果工单未分配，则发送给团队成员。用户可以按团队控制 SLA 通知渠道。

工单列表包含 SLA 列和 SLA 筛选器，仪表板会突出显示有风险和已违约工单，工单时间线会记录策略和计时器事件。工作流上线后，统计功能会提供 SLA 达成情况视图。

提醒上线后需要跟踪哪些内容

首先要问的是，提醒是否正在防止违约。将有风险工单与之后错过目标的工单数量进行比较，然后调查那些提醒未能挽救的案例。

分别跟踪首次回复达成率和解决达成率。同时检查当前处于警告时间窗口内的工单数量、已经违约的工单数量，以及哪些策略或团队—优先级组合造成了最多的目标未达成。

将百分比与运营背景结合起来分析。整体百分比较高，可能掩盖某个反复违约的队列。突然下降可能是工作时间安排发生变化、新增了某个优先级，或出现了归属缺口，而不一定意味着处理速度变慢。

管理重叠 SLA，避免提醒冲突

一个工单可能同时拥有首次回复目标和解决目标。请将它们视为独立的计时器，因为回复只能完成第一个目标。解决目标会持续计时，直到工单达到满足该目标的事件。

工单界面应显示即将到来的未完成截止时间，同时保留两个目标的详细信息。筛选和报告也应区分首次回复与解决，避免一个健康的指标掩盖另一个指标中的问题。

当客户拥有不同的服务承诺时，请使用与团队和优先级等稳定工单字段匹配的独立策略。将具体策略排在兜底策略之前，然后针对每种有意义的组合测试工单。避免创建用户无法在工单中看到或验证的隐藏合同层级。

SLA 自动运行时保持可审计状态

保留所应用策略、计算出的截止时间，以及每个计时器达成或错过的时间记录。如果团队、优先级或时间安排的变化导致截止时间重新计算，也应能够追踪这项变化。

将策略变更记录在通知收件箱之外。记录谁批准了变更、何时生效，以及是否适用于现有工单。这样可以更轻松地回答后续客户问题，也能防止 SLA 报告含义发生无记录的变化。

对于合同审查，请确认平台的实际行为，不要假设每个可见事件都是审计日志。Deskhero 的工单时间线会记录 SLA 策略应用和计时器结果，而统计区域会报告达成情况。具有正式留存要求的组织应确认这些记录符合自身义务。

为用户、管理者和客户撰写 SLA 消息

内部提醒和客户更新的用途不同。每种消息都应专注于读者接下来可以采取的行动。

面向用户的提醒应以工单链接、目标类型、截止时间和即时行动开头。当用户需要处理工单时，不要加入一大段策略背景。

面向管理者的复盘应展示某个团队、优先级或策略中的规律。单个错过目标的工单需要采取行动，而反复错过目标则需要作出人员配置或流程方面的决策。

面向客户的沟通应准确且具体。如果团队预计会出现延迟，经人工审核的更新可以给出合理的下一次联系时间。不要暴露内部提醒标签，也不要承诺团队无法支持的解决时间。

将 SLA 自动化连接到你已经在使用的工具

当原生 SLA 功能能够覆盖所需的策略、日历、暂停状态、提醒、筛选和报告时，请优先使用这些功能。与并行维护的电子表格相比，原生截止时间通常能更可靠地与工单变化保持一致。

当原生支持有限时，团队也使用过社区插件和论坛记录的变通方案。在依赖这种方式之前，请检查其维护状态和版本兼容性。

当多个系统必须向同一个升级渠道提供信息时，单独的工作流可能比较合适。首先定义事实来源。帮助台和集成层分别计算 SLA 可能会产生偏差，尤其是在时区、工作时间、暂停状态和重新分配方面。

编辑观点：提醒不是重点，行动才是

即将到期通知只有在归属明确时才有用。接收人需要权限、背景信息和时间来推动工单向前处理。

计时器准确性优先。错误的工作时间安排或暂停配置，会产生看似确定却具有误导性的提醒。在调整消息措辞或增加渠道之前，先修正截止时间计算。

请按以下顺序构建：策略目标、工作时间安排、暂停行为、通知接收人、操作响应和报告。这样的顺序可以让提醒始终与所有人都理解的截止时间保持关联。

无需迁移项目即可启用 SLA 提醒

Deskhero 支持与 Gmail 或 Microsoft 365 双向同步，因此团队可以保留现有的支持邮箱，同时增加共享工单处理和 SLA 策略。

Deskhero

按团队和优先级配置首次回复和解决目标，在需要时添加每周工作时间安排，并选择哪些状态会暂停解决计时。Deskhero 随后会显示下一个截止时间，突出显示一小时内到期的工单，通知负责的用户，并记录 SLA 结果。

30 天免费试用无需信用卡。连接一个邮箱，配置一小组策略，并在将设置扩展到更多团队之前测试完整的 SLA 生命周期。

来源

常见问题

SLA、SLO 和 SLI 有什么区别？

SLA 是双方之间的服务承诺。SLO 是针对服务性能设定的目标，通常在内部使用，以确保履行该承诺。SLI 是用于评估该目标的测量值。

什么算是 SLA 违约提醒？

违约提醒表示尚未完成的首次回复或解决截止时间已经过去。即将到期提醒则不同，因为团队仍有时间达成目标。

4 小时 SLA 是什么意思？

这意味着策略指定的操作（例如首次回复或解决）按照该策略的计算方式，应在四小时内完成。计时器可能使用日历时间或工作时间安排。

SLA 与 KPI 有什么不同？

SLA 规定服务承诺。KPI 衡量绩效，并且可以用于监控许多并非合同截止时间的目标。

Deskhero 可以在不编写自定义代码的情况下自动发送 SLA 提醒吗？

可以。Deskhero 提供内置 SLA 策略、固定的即将到期警告时间窗口、违约检测、应用内和电子邮件通知、工单筛选器、仪表板视图以及 SLA 报告。这些功能与其通用自动化规则分开。