| Suite | Professional, Enterprise, or Enterprise Plus |
| Support with | Explore Professional or Enterprise |
您可以从 Explore 中计划生成面板报告，以便向团队提供 PDF。或者，您可以每个月手动提取数字，并将其放入电子表格中。您也可以在 Explore 中为相同号码 创建报告 。如果这些方法显示的结果不同，那就令人困惑了，为什么数字不一致？
在研究这些差异时，要记住 PDF 和电子表格是静态的，而 Explore 是动态的。
本文章包含以下主题：
结果为何更改
例如，假设您导出了 8 月 1 日整个 7 月的数据，并将其放入电子表格中。但到了 9 月，您在 Explore 中运行另一个基于相同数据的报告，就会发现 7 月显示的数字不同。
| 基于八月导出的七月列： | Explore 九月运行报告中的七月列： |
 |
 |
继续阅读以了解：
为什么已创建工单存在差异？
如果您一直在删除工单，则创建的工单总数会减少。
已删除工单将从工单数据集移除。因此，如果您 将工单标为垃圾信息 或以其他方式 删除，这些工单将从工单总数中移除。由此推论，这也会改变工单创建的数量。
在上面的例子中，创建的工单数量从 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 张工单从“标记”重新分类为“错误”。
此类更改也会影响报告的筛选。例如，假设您有一个报告筛选为仅显示 A 组的工单。如果在导出到报告之间有一张工单从 A 组移动到了另一个组，该工单将不会再显示在您的报告中。
对于最初分配给 B 组，后来重新分配给 A 组的工单，情况正好相反。由于筛选，您的报告中将显示比以前更多的工单。
正确理解数字
在查看 Explore 报告与导出内容之间的差异时，有助于了解实际数字本身。请考虑以下事项：
- 如果一个结果从 20 张工单更改为 21 张工单，则增量为 1。感觉数字不大。但这可是 5% 的变量。
- 如果另一个结果从 1,998 更改为 2,100，则相差 102。数字可能感觉很大。但也只有 5% 的变量。
谈到差异，除了原始数字之外，还要关注百分比。这有助于您了解是否为重大变化。
想一想您有多少专员。如果您有 200 名专员，其中一个结果变化了 102，则表示从导出数据到 Explore 运行报告期间，平均大约有一半的专员更改了一张工单上的该字段。
同样，您可以在更新历史记录数据集中检查这些结果。使用 更新者名称 属性可筛选显示相关[更改 - 字段名称]属性以及您困惑的上一个或新结果的报告。
通常，您会看到变化分布很宽，例如，100 名专员在一段时间内全部更改了大约一个字段。
然而，您可能会发现一两个专员更改字段结果的频率更高。也许他们是负责跟踪团队成员进行整理的管理者。或者，他们是新手，最初不了解如何应用该字段，在这种情况下，最好进行更多培训。
使用正确的聚合器
最后，当您在考虑持续时间时，最好要记住“数量与质量”。
默认情况下，Explore 对首次回复时间和解决时间等指标使用中值 (MED) 聚合器。但您可能有一些受托人或组处理工单很少，且处理方式与常规专员有很大不同。可能他们来自财务或安全团队，不会经常涉及工单，对响应时间也没有相同期望。
使用持续时间指标的 MED 聚合器有助于避免出现这些异常值。如果您使用平均值（AVG）聚合器，这种保护会降低。例如，假设财务团队处理该客户的工单已有六个月，而团队其他成员通常在一周内解决工单。财务团队异常值会严重影响您的未解决工单期限，尤其是当您使用 AVG 聚合器时。
当财务团队最终解决了工单时，其解决时段的解决时间也可能受到重大影响，尤其是在您使用 AVG 的情况下。
结论
随时间变化的数字可能会令人困惑。知道了。特别是当您的上司问及此事时。但可能有很多合乎逻辑的更改原因。
如果您很担心，请考虑上面提出的问题，以及它们可能对这种情况产生什么影响。如果您仍有疑问，请浏览 Explore 文档 或 社区 寻求帮助，或 联系 Zendesk 客户Support。
0 条评论
登录再写评论。