Monitor and Measure Ticket State and SLA Event Timings in Views and Reports

Sub Banner

The data recorded as part of the SLA Event Time Management service and presented in the SLA Assistant can also be used within Zendesk views and Insights reports (GoodData) to monitor and measure your SLA Event Timings.

The following SLA 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 Insight reports (GoodData), 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 SLA 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 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 Hours To Total update

*Note: 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 SLA 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 SLA 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 SLA 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 SLA 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 SLA Event Timings in Views

Monitor SLA Event Timings in Views

Using the fields generated and maintained by the SLA 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 SLA Event Timings above for information regarding the currency and accuracy of timings until the ticket id solved.

Measure SLA Event Timings using GoodData (Insights)

Measure SLA 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 SLA Event Timings above for information regarding the currency and accuracy of timings until the ticket id solved.

Build Reports using the SLA Event Time Measurements Metrics

Build Reports using the SLA 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 SLA setup and configuration service.

It isn't possible to load these metrics until your SLA 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.

Monitor and Measure Ticket State and SLA Event Timings in Views and Reports

Sub Banner

Monitor and Measure Ticket State and SLA Event Timings in Views and Reports

The data recorded as part of the SLA Event Time Management service and presented in the SLA Assistant can also be used within Zendesk views and Insights reports (GoodData) to monitor and measure your SLA Event Timings.

The following SLA 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 Insight reports (GoodData), 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 SLA 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 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 Hours To Total update

*Note: 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 SLA 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 SLA 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 SLA 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 SLA 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 SLA Event Timings in Views

Monitor SLA Event Timings in Views

Using the fields generated and maintained by the SLA 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 SLA Event Timings above for information regarding the currency and accuracy of timings until the ticket id solved.

Measure SLA Event Timings using GoodData (Insights)

Measure SLA 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 SLA Event Timings above for information regarding the currency and accuracy of timings until the ticket id solved.

Build Reports using the SLA Event Time Measurements Metrics

Build Reports using the SLA 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 SLA setup and configuration service.

It isn't possible to load these metrics until your SLA 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.

Monitor and Measure Ticket State and SLA Event Timings in Views and Reports

Sub Banner

The data recorded as part of the SLA Event Time Management service and presented in the SLA Assistant can also be used within Zendesk views and Insights reports (GoodData) to monitor and measure your SLA Event Timings.

The following SLA 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 Insight reports (GoodData), 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 SLA 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 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 Hours To Total update

*Note: 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 SLA 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 SLA 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 SLA 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 SLA 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 SLA Event Timings in Views

Monitor SLA Event Timings in Views

Using the fields generated and maintained by the SLA 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 SLA Event Timings above for information regarding the currency and accuracy of timings until the ticket id solved.

Measure SLA Event Timings using GoodData (Insights)

Measure SLA 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 SLA Event Timings above for information regarding the currency and accuracy of timings until the ticket id solved.

Build Reports using the SLA Event Time Measurements Metrics

Build Reports using the SLA 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 SLA setup and configuration service.

It isn't possible to load these metrics until your SLA 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.

Monitor and Measure Ticket State and SLA Event Timings in Views and Reports

Sub Banner

Monitor and Measure Ticket State and SLA Event Timings in Views and Reports

The data recorded as part of the SLA Event Time Management service and presented in the SLA Assistant can also be used within Zendesk views and Insights reports (GoodData) to monitor and measure your SLA Event Timings.

The following SLA 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 Insight reports (GoodData), 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 SLA 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 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 Hours To Total update

*Note: 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 SLA 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 SLA 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 SLA 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 SLA 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 SLA Event Timings in Views

Monitor SLA Event Timings in Views

Using the fields generated and maintained by the SLA 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 SLA Event Timings above for information regarding the currency and accuracy of timings until the ticket id solved.

Measure SLA Event Timings using GoodData (Insights)

Measure SLA 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 SLA Event Timings above for information regarding the currency and accuracy of timings until the ticket id solved.

Build Reports using the SLA Event Time Measurements Metrics

Build Reports using the SLA 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 SLA setup and configuration service.

It isn't possible to load these metrics until your SLA 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.