The data recorded as part of the Event Time Management service and presented in the Performset Assistant can also be used within Zendesk views and Explore reports to monitor and measure your Event Timings.
The following ticket fields are generated and maintained as part of this service and although generally hidden from view in the ticket forms, these fields are available for use in views and Explore reports, where state_name is the name of the ticket status being measured and event_name is the name associated with each of the events configured as part of the Performset setup:
- SLA3 Hours in state_name - the total calculated time spent in the ticket state (including custom states)
- SLA3 Hours To event_name - the total calculate time taken to reach the event
- SLA3 Permitted Hours To event_name - the amount of time permitted to reach the event
- SLA3 Hours To Total event_name - the total number of event occurrences during the life of the ticket
For example SLA3 Hours in Open, SLA3 Hours To respond, SLA3 Permitted Hours To respond, SLA3 Hours To Total update
Calculating Targets against Actuals (Fulfilment)
It is possible to calculate how well your agents are performing against agreed targets by subtracting 'SLA3 Hours To event_name' from 'SLA3 Permitted Hours To event_name', to determine if your agents are meeting agreed targets, e.g. Agent Performance against 'Initial Response' Target = SLA3 Permitted Hours To respond - SLA3 Hours To respond
Calculating the Average Hours for Repeating Events
For repeating events such as update the 'SLA3 Hours To event name' is divided by the 'SLA3 Hours To Total event_name' to calculate the average event timing, e.g. Average Hours To 'Update By' = SLA3 Hours to update / SLA3 Hours To Total update
Important Information Concerning the Purpose and use of Event Timings
Events that Cause the Calculation of a Measure
- There is not a ticking timer for each of the measures and they are only recalculated and updated when a request is submitted to the Performset service to perform a calculation
- This is most usually the case when there is a change of status, but the measure for the current status will also be recalculated when other events cause an Performset service request, e.g. change of priority, providing an initial response
- Since the measures will only include time spent within business hours it is possible that a ticket could sit in a status for a period of time but have a zero value in the measures calculation
- So for example if a ticket arrived outside of business hours and has a status of New for 1 hour before being placed On-hold whilst still outside of business hours, then the measure for the status of New will be calculated as zero
- The total amount of time spent in a status will only be known once the ticket has been moved out of the status
- However, if the ticket is moved back into a status the existing measure is accumulated, adding any business hours spent in the status again to the existing value
- The measures are designed for historical reporting purposes, i.e. how many business hours were spent during the status and cannot be relied upon for an accurate ongoing monitoring, i.e. how many business hours have been spent in the status so far
Reporting against Solved Tickets
The above being the case the measures and the metrics provided in your Insights project are designed for use when reporting against solved tickets, since this assumes that a final measurement has been calculated for each status.
Reporting against Unsolved Tickets
In order to get report on the measures for tickets that haven't yet been solved using only accurate measures, it would be necessary to introduce a set of metrics that check the status of the ticket, e.g. only return the Business Hours in Pending where the Ticket Status <> Pending
- Obviously any report using these metrics wouldn't know about the business hours spent in tickets that still reside in a particular status.
- However, since the measures are designed for historical reporting purposes (i.e. how many business hours were spent during the status), then the figures in the report would be accurate.
- Even if the measures were updated in Zendesk every second, the data available for reporting in your Insights project will always be up to 1 hour out of date.
- So the most accurate way to report on the measures would still be based on metrics that return the measures when it is known the ticket is no longer in the corresponding status.
Monitor Event Timings in Views

Using the fields generated and maintained by the Event Time Measurement service it is possible to create views to monitor event timings as in the example above.
*Note: please see Important Information Concerning the Purpose and use of Event Timings above for information regarding the currency and accuracy of timings until the ticket id solved.
Measure Event Timings using GoodData (Insights)

The information calculated for the time a ticket spends within each state or the time taken to reach each event is held against the ticket in fields that will be included for use in your Insights (GoodData) project.
It is therefore possible to build reports based on this data such as the average amount of time as in the example screenshot above (1).
*Note: please see Important Information Concerning the Purpose and use of Event Timings above for information regarding the currency and accuracy of timings until the ticket id solved.
Build Reports using the Event Time Measurements Metrics

Your reports should be created using the metrics located in the CloudSET SLA Performance folder (2).
The CloudSET SLA Performance metrics will be loaded into your Insights project by your CloudSET consultant as part of your Performset setup and configuration service.
It isn't possible to load these metrics until your Performset setup is complete and sample tickets have been created that make use of all ticket fields and option values.
So if some or all of the required metrics are missing please contact Coherence Design to make the necessary arrangements for the data load.
Comments
Please sign in to leave a comment.