如何制作支持工单报告：分步指南

服务工单报告本质上是一个定义问题。创建工单数、解决工单数、首次回复时间和解决时间，这些词听起来都不言自明。然而，在同一个服务台系统中，它们每一个都拥有不止一种官方定义。

只要明确了统计规则，报告自然就水到渠成了。如果跳过这一步，两个同样诚实的人导出相同的数据，得出的结果可能会相差数个小时。

本指南将介绍工单报告应包含的内容、定义产生分歧的四个关键点，以及如何通过导出的工单数据来构建这份报告。

服务工单报告中应包含哪些内容

仅凭数量几乎说明不了任何问题。合理的排布才能让数据具有参考价值。

要素	存在的原因
统计周期内创建的工单	需求侧
统计周期内解决的工单	供给侧，基于明确的状态规则
周期结束时的积压工单	所有未解决或未关闭的工单
首次回复时间	基于明确的计时方式和定义
解决时间	首次或最终解决，需明确指出
重新打开的工单	其他数据所掩盖的质量信号
未回复的工单	流程彻底失效的地方
明确的日期基准和范围	包含哪些渠道、品牌和队列

有两行内容的分量比它们看起来要重得多。重新打开和未回复的工单，是让报告不再仅仅是冷冰冰的记分牌，而是开始发挥实用价值的关键所在。

Zendesk 公布了底层公式，这使得定义是可以核实的，而不是凭主观意见。其 指标和属性参考 详细列出了每一个定义。

从最简单的开始。“解决的工单”是指“已解决或已关闭的工单数量”，因此该指标涵盖了两种状态，而不仅仅是一种。

“首次回复时间”有两个官方定义

这是引起最多分歧的分歧点，厂商也直接对此发出了警告。

Zendesk 的 SLA 文档 用一句话说明了这一点：“不要将 SLA 回复时间与原生的 Zendesk 回复时间指标混淆。”

原生指标对回复主体有着严格的要求。Zendesk 指出，“首次回复时间完全基于客服的回复进行计算。”在计算首次回复时间时，“不考虑”自动回复和机器人相关的操作。

但 SLA 指标并非如此。在 SLA 中，首次回复时间是“工单创建到客服首次发表公开评论（或自动回复）之间的时间”。Zendesk 补充道，“如果您设置了触发器以公开评论进行自动回复，则回复时间指标即算达成。”

将这两者结合起来看，结果显而易见。自动回复可以满足您的 SLA 目标，而原生的首次回复时间却仍在继续计时。

因此，一份显示 98% 的 SLA 达成率 and 4 小时中位数首次回复时间的报告并没有自相矛盾。它报告的是两件不同的事情，且都是正确的。

还有两个较小的例外值得了解。以客服创建工单且第一条评论是公开的情况为例。时长指标参考 指出，第二个时间戳“会转移到客服的第二条公开评论”。

共享工单也不计算在内。Zendesk 指出，当客服使用工单共享功能从另一个账户发表公开评论时，“这不会计入您账户的首次回复时间”。

“解决时间”也有两个定义

同样的划分也贯穿于解决指标中，而且这两个版本在默认情况下都是提供的。

首次解决时间是“工单创建到首次解决之间的时长”，结束于“工单状态首次被设置为已解决的时间”。

最终解决时间是“工单创建到最近一次解决之间的时长”。它结束于“工单状态最后一次被设置为已解决的时间”。

对于只解决过一次的工单，这两者是完全相同的。对于一个被解决、重新打开并再次解决的工单，它们之间的差距就是第二轮处理所花费的时间。

这正是重新打开的工单应该包含在报告中的原因。Zendesk 将其定义为“解决后重新打开”的工单，并指出该指标“不包括在同一次更新中解决并重新打开的工单”。

还有一个人们容易忽略的次级效应。每日解决工单的平均值“仅在工单当前处于已解决或已关闭状态时”才将其计算在内。因此，今天重新打开的工单会悄悄地从上个月的解决数量中消失。

因此，您在 6 月运行的报告在 8 月将无法重现。并没有出什么故障，只是底层状态发生了变化。

还有两个指标将等待时间与工作时间区分开来。请求者等待时间是在新建、开启和挂起状态下的累计时间，而客服等待时间是在待处理状态下的累计时间。

这两个指标回答了平均解决时间无法回答的问题。因等待客户而导致的解决时间过长，与因队列积压而导致的解决时间过长，是完全不同的两个问题。

自然时间还是工作时间

每个回复和解决数据都存在于两种计时方式中，选择其中一种是必不可少的。

Zendesk 两者都会存储。在首次公开回复后，“系统会以自然时间和工作时间计算首次回复时间。”这两个指标“都会与工单数据一起存储”。

您看到的默认设置并不是中立的。Zendesk 指出，预建的 Explore 报告“以自然时间显示预建报告中的信息”。工作时间指标“是可用的，并可用于您自己构建的报告中”。

因此，一个朝九晚五的团队在默认报告中看起来效率会很低。周五晚上 6 点到达的工单在周一早上之前大约会产生 63 个自然小时，而工作时间则接近于零。

实时对话渠道又增加了一个复杂情况。在线消息和聊天的“首次回复时间（秒）”指标“会忽略您的在线消息工作时间和在线聊天运营时间设置”。

并且聊天回复时间的 SLA 是需要手动开启的。Zendesk 指出，在线聊天的回复时间 SLA“默认是关闭的”，因此没有这些指标只是因为配置状态，而不是因为表现完美。

如何手动制作报告

方案 1：每个指标类别一个标签页

导出带有指标字段的工单列表，然后在进行任何汇总之前，将数量、回复时间和解决时间拆分到不同的标签页中。

将自然时间和工作时间列并排放在一起，而不是在导出时只选择一个。因为你迟早会被问到另一个。

对于时间指标，计算中位数而不是平均值。少数在假期期间未关闭的工单会将平均值拉到一个不切实际的高度。

这种方法的局限性在于电子表格无法查看状态历史记录。您只能获得每个工单的当前状态，因此重新打开的行为必须来自“重新打开次数”这一指标，而无法通过还原历史来获取。

方案 2：先写一个定义标签页

记录回复时间定义、计时方式、解决指标、已解决的状态规则、范围内的渠道以及日期基准。

然后记录报告中未声明的内容。写下 SLA 达成率和原生首次回复时间测量的是不同的东西，可以防止好心的同事将它们混为一谈。

局限性也显而易见。记录规则并不等于应用规则，下个季度可能又会有人凭记忆重新构建透视表。

方案 3：在计算平均值之前进行细分

在计算任何时间指标之前，先按渠道进行拆分。邮件、聊天和电话工单的处理规律完全不同，混合的中位数无法准确描述其中任何一个。

然后排除或标记那些会扭曲数据的工单。等待客户回复数周的工单应该单独列出，而不是放在平均解决时间中。

显示您排除了什么以及有多少。看不到过滤器的读者会认为没有进行任何排除。

局限性在于细分会使工作量成倍增加。三个渠道乘以两种计时方式再乘以两个解决指标，就是 12 个需要理清的数据。

共同的局限。 这三种方案都假设导出数据涵盖了每个队列在同一个日期基准上的同一个日期范围。跨标签页的混合日期范围是此报告中最常见的隐性错误。

手动制作报告的瓶颈所在

制作第一份服务工单报告需要一个下午。但到了第四份，花费的时间可能会更长，因为底层的服务台系统已经发生了变化。

比如启用了一个新渠道，导致混合中位数因为与业绩无关的原因而发生变化；或者为新地区修改了工作时间，导致所有历史工作时间数据也随之改变。

接着是“重新打开”效应。上个季度的数据再也无法重现，而解释其中的原因比重新制作一份报告还要费时。

还有第四种成本，只有在面临压力时才会显现。比如有人问本季度支持服务是否变快了，一个严谨的回答需要首先说明计时方式、定义和渠道组合。

至于同一张图景中的满意度方面，请参阅我们的 创建 NPS 报告 指南。如果工单量本身是问题所在，我们关于 构建售前客户支持 AI 智能体 的教程则涵盖了工单分流方面的内容。

如何使用 Powerdrill Bloom 构建报告

步骤 1: 上传导出的工单数据

上传导出的工单数据，或者将工单和 SLA 导出数据一起上传。Powerdrill Bloom 会在导入时自动分析各列，因此在计算任何中位数之前，空白时间戳、混合日期格式以及缺少首次回复的工单都会被提前识别出来。

步骤 2: 用自然语言描述报告

直接声明定义，而无需重新构建。指出回复时间定义、计时方式、所需的解决指标、已解决的状态规则以及包含的渠道。

然后提出能够发现错误的问题。比如：有多少工单根本没有客服回复？哪些工单被重新打开了？要求提供每个渠道的中位数，而不是一个混合的数据。

步骤 3: 导出图表、报告或幻灯片

导出每个渠道的指标表，或者创建与解决对比且包含积压工单的图表。在数据旁边附带定义的幻灯片也会在同一次运行中生成。

常见错误

将 SLA 达成率等同于首次回复时间。 前者认可自动回复，而后者则完全排除自动操作。

混淆自然时间与工作时间。 默认报告提供的是前者，而您的目标通常是基于后者设定的。

在回复和解决时间上使用平均值。 少数被遗弃的工单会将平均值拉到一个不切实际的高度。

混合渠道数据。 在线聊天和电子邮件的中位数在设计上就是不同的，混合数据会掩盖这两者的真实表现。

报告解决时间时未明确指出是哪一种。 首次解决时间和最终解决时间是分别存储的独立指标，而不是四舍五入的变体。

将解决数量视为一成不变的最终数据。 解决数量仅包括当前处于已解决或已关闭状态的工单，因此重新打开工单会改变历史数据。

遗漏未回复的工单。 它们被定义为客服回复次数为零的工单，是报告所能反映的最明显的流程失效点。

结语

明确回复定义、计时方式，选择首次或最终解决时间，声明状态规则，按渠道进行细分，并展示重新打开和未回复的工单。只有这样，才能制作出一份真正具有行动指导意义的服务工单报告。

但这份报告可能无法直接与其他公司的数据进行横向对比。因为这些定义都是可配置的，您在别处看到的行业基准几乎肯定采用了不同的衡量规则。

相反，您应该在固定规则下，对照自己的历史数据进行追踪。只有这样，才能真正看出服务质量是否得到了实际提升。

如果每个月重新制作报告要耗费您一整天的时间，不妨在导出工单后 尝试使用 Powerdrill Bloom。另请参阅 AI 报告生成器 页面和 客户之声汇总器。

常见问题

为什么我的 SLA 达成率与首次回复时间不一致？

因为它们衡量的是不同的事件。Zendesk 的 SLA 首次回复时间可以通过自动回复来达成，而原生的首次回复时间指标则完全排除了自动回复和机器人操作。

我应该报告首次解决时间还是最终解决时间？

报告您明确定义的那一个。首次解决时间结束于工单首次被设置为已解决的时间；最终解决时间则结束于最后一次被设置为已解决的时间，因此重新打开的工单会导致这两者产生偏差。

支持指标是用自然时间还是工作时间衡量的？

系统会同时存储这两个数据。Zendesk 预建的 Explore 报告默认显示自然时间，而工作时间指标则可用于您自己构建的报告中。

为什么上个季度的解决工单数量发生了变化？

因为解决数量仅包含当前处于已解决或已关闭状态的工单。在统计周期结束后被重新打开的工单，会从该周期的统计数据中剔除。

可以将我的解决时间与行业基准进行比较吗？

只能进行粗略的参考。因为定义、计时方式和渠道组合都是可配置的，公开的行业数据很可能采用了与您完全不同的衡量规则。