Building an Example Performance Dashboard in Explore

Martin Barker

June 01, 2022 13:23

Your Performset setup will record measurements pertaining to the performance of your agents against agreed service levels.

These measurements are recorded against your tickets as ticket fields that can be referenced as metrics in your reports and dashboards using Zendesk Explore.

A full list and explanation of the purpose and use of each ticket field is provided in the following article: Monitor and Measure Performance in Views and Reports

At this time Zendesk explore doesn't offer an API or alternative import option to allow the automatic generation of templates and example reports and dashboards.

However, the following short videos provide instructions explaining how to build an example SLA Performance Dashboard, using the metrics provided by your CloudSET Performset setup and configuration.

*Important Note: after watching the videos and building the queries, please see the instructions for the introduction of an additional changes filter at the end of this article.

Building an Example Pass vs Violation Performance Dashboard

The following video explains how the CloudSET performance measures recorded in ticket fields can be used to build an example set of queries and a dashboard, to report on the number of ticket events passing or violating the SLA, to give a % within SLA.

*Note: the slides from this video can be viewed in the PDF file attachment at the end of this article.

Filtering out Irrelevant Changes

When the above videos were created it had been assumed that the calculated attributes and calculated metrics would have successfully filtered out the changes that aren't involved in performance measurements (Explorer is a relatively new product and we're still learning about it ourselves).

However, it has since been discovered that Explore is unnecessarily returning all of the changes to the query before the metrics are applied, which can lead to performance issues or even prevent the query returning results.

An additional filter is therefore required to restrict the changes returned by the query to only those that involve an update to the performance measures involved.