您可以在Explore之外计划面板报告,以便将 PDF 发送给您的团队。或者,您可以每个月手动提取数字,并将其放入电子表格中。您也可以在Explore中为相同的号码创建报告。如果这些方法显示不同的结果,那可能会令人困惑 —— 为什么数字不匹配?
当您深入研究这些差异时,要记住的关键是 PDF 和电子表格是静态的,而Explore是动态的。
此文章包含以下主题:
结果为什么会改变
例如,假设您在 8 月 1 日导出了整个 7 月的数据,并将其放入电子表格中。但是后来,也就是 9 月,您在Explore中就相同的数据运行了另一份报告,它显示了 7 月的不同数字。
7 月列基于 8 月的导出运行: | 9 月在Explore中运行的报告中的 7 月列: |
继续阅读以了解:
为什么创建的工单会有所不同?
如果您一直在删除工单,则已创建的工单总数可能会减少。
已删除工单将从工单数据集中移除。因此,如果您将工单标为垃圾信息或将其删除,这些工单将从工单总数中移除。也就是说,这也会改变工单创建的数量。
在上面的例子中,创建的工单数量从 705 减少到 693。这表明从 8 月导出的数据到 9 月在Explore中运行报告之间,共删除了 12 张工单。
另一方面,如果您一直在恢复已删除工单,则创建的工单总数可能会增加。
要检查已删除和已恢复工单号,您可以使用更新历史记录数据集中的删除和恢复指标。
对于删除,您无法看到工单 ID 或其它属性等详情(因为工单已被删除),但您可以看到:
- 当工单被删除时,使用更新 - 时间戳属性
- 谁删除了工单,使用更新者名称属性
对于恢复,您可以查看类似的信息,关于它何时发生以及谁做的,您还可以查看其它工单属性,如工单 ID(因为工单再次存在)。
为什么已解决工单会有差异?
通常,您通过工单创建 - 日期属性查看已创建工单,并通过工单解决 - 日期属性查看已解决工单。然而,在某些情况下,这些数字会根据某些事件而波动。
当按解决日期查看已解决工单时,这些数字受重新开启指标(在工单和更新历史记录数据集中可用)的影响。如果在导出数据和在Explore中运行报告之间重新开启工单,这个数字就会发生变化。重新开启可以从此指标完全移除工单(因为已不再解决),或将其从一个时段移动到另一个时段(如果最后一次解决与第一次解决在不同的时段)。
当按创建日期查看已解决工单时,这些数字会随着时间的推移受到解决方案的影响。如果 10 张工单已在周一创建,2 张工单已在当天解决,则导出将显示 2 张周一的已解决工单。如果另外 3 张工单在周二解决,则报告 —— 以及下一次导出 —— 将显示 5 张工单是在周一创建的。
更新历史记录数据集中的工单已解决指标仅查看当前已解决工单的最后一次解决。您可以通过查看指标公式来了解这一点,特别是粗体的两个条件:
IF ([Changes - Field name]="status" AND [Changes - Previous value]!="solved" AND ([Changes - New value]="solved" OR [Changes - New value]="closed") AND ([Ticket status - Unsorted] = "Solved" OR [Ticket status - Unsorted] = "Closed") AND [Update - Timestamp]=[Ticket solved - Timestamp]) THEN [Update ID] ENDIF
如果您想跟踪所有的解决数,您可以创建一个标准的计算指标,剔除当前状态和日期的这两个条件,为您留下以下公式:
IF ([Changes - Field name]="status" AND [Changes - Previous value]!="solved" AND ([Changes - New value]="solved" OR [Changes - New value]="closed")) THEN [Update ID] ENDIF
为什么某个类别的工单会有所不同?
工单数据集查看工单的当前状态 —— 包括状态、组、受托人、优先级、自定义字段等等。这意味着如果字段在导出数据和您在Explore中运行报告之间发生了变化,那么您的结果很可能也会发生变化。
在上面的示例屏幕中,您可以看到 8 月的导出显示 10 个光点和 61 个错误。但在 9 月的报告中, Explore显示了 2 个光点和 69 个错误。这表明在运行导出和报告之间,有 8 张工单从 blip 重新分类到了缺陷。
此类更改也会影响报告的筛选。例如,假设您有一个已筛选的报告,仅显示组 A 的工单。如果在导出和生成报告之间,工单从组 A 移动到另一个组,该工单将不再显示在您的报告中。
对于最初分配到组 B 然后重新分配到组 A 的工单,反之亦然。由于筛选的原因,您的报告中显示的工单将比以前更多。
正确看待数字
当查看Explore报告和导出之间的差异时,正确看待实际数字本身会很有帮助。请考虑以下情况:
- 如果一个结果从 20 张工单更改为 21 张工单,则增加 1 张。这感觉并不大。但这是 5% 的改变。
- 如果另一个结果从 1,998 更改为 2,100,则差为 102。这可能感觉很大。但这也是只有 5% 的改变。
当谈到声声限制时,看看百分比以及原始数字。这可帮助您了解哪些是物质或不是。
想一下您有多少专员。如果您有 200 名专员,其中一个结果将更改 102 名,这表明您的专员平均有一半,在导出的数据与Explore上运行的报告之间的一个字段更改了该字段。
再次,您可以在更新记录数据集中检查这些结果。使用 更新者名称 属性筛选报告显示相关的[更改 - 字段名称] 属性以及之前或新的结果令人困惑。
经常,您将看到一系列更改——例如,100 名专员在期间进行大约一个字段更改。
然而,您可能会看到一两名专员正在更频繁地更改字段结果。也许他们是一名团队成员在队员之后进行迫害的管理者。或者他们很新,最初没有理解如何应用该领域,在这种情况下,更多的培训可能很有用。
使用正确的聚合器
最后,当您查看持续时间时,记住“数量与质量”是一个好主意。
Explore默认为首次回复时间和解决时间等指标使用中位数(MED)聚合器。但是您可能有一些处理很少工单的受托人或组,而且与您的常规专员不同。也许他们来自金融或安全团队,他们不经常进入工单,谁没有相同的响应时间期望。
使用 MED 聚合器对持续时间指标的持续时间指标帮助您免受这些异度的影响。如果您使用平均值(AVG)聚合器,此保护将减少。例如,金融团队一直坐在一张来自该客户的一张工单上,而您团队的其余人员在一周内经常解决工单。金融团队更严重影响您的未解决工单年龄,特别是如果您在使用平均聚合器。
当金融团队最终解决该工单时,解决时间,他们解决的时段也可能会受到重大影响——再次,特别是如果您在使用平均时间。
结论
一段时间内更改的数字可能会感到困惑。我们得到这一点特别是如果你的老板正在询问你关于它的问题。但有大量更改的逻辑原因。
如果您担心,请考虑上述问题及其影响情况的方式。如果您仍有任何疑问,浏览 Explore文档 或 社区 以获得帮助,或 联系 Zendesk 客户支持。
翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性
如对翻译准确性有任何疑问,请以文章的英语版本为准。