This article provides definitions for metrics and metric filters for creating Insights reports. For more information on Insights, see Insights resources. For information on other reporting objects, see Insights object reference. Insights and custom reporting is available on Professional and Enterprise. When creating your report, metrics are found in the 'What' panel. After selecting a metric, you can view its MAQL definition in the 'Detail' panel. In the table below, the 'How it's calculated' column gives a simplified version of the MAQL definition.
The article contains the following sections:
- Tickets
- Events
- Time-based events
- Service Level Agreements (SLAs) metrics
- Surveys
- Calls
- Zendesk Chat
- Skills
- Zendesk Guide
- Metric filters
If you're looking for information about metrics for Zendesk Explore, see Understanding Explore datasets.
Tickets
You can use the metrics defined in this section to report on your tickets.
Ticket metrics
The metrics below are located under the Tickets folder in Insights.
Metric | Definition | How it's calculated |
---|---|---|
# Assignee Stations | The number of agents a ticket has been assigned to. | Assignee is not the current assignee
Increment assignee stations by 1. |
# Incidents | The number of tickets where the ticket type is 'Incident'. | The count of ticket IDs WHERE ticket type is Incident AND deleted tickets are not included. |
# One-touch Tickets | The number of tickets that were solved in one-touch (one reply). | The number of solved tickets WHERE the average number of replies BY ticket ID is less than or equal to one. |
# Open Tickets | The count of tickets that are not in solved or closed statuses. | The count of ticket IDs WHERE ticket status is not Solved, Closed, or Deleted. |
# Problems | The number of tickets where the ticket type is 'Problem'. | The count of ticket IDs WHERE ticket type is Problem AND deleted tickets are not included. |
# Reopens | The number of ticket reopens during the selected time period. | The sum of ticket reopens WHERE deleted tickets are not included. |
# Reopens [Avg] | The average number of ticket reopens. | The average ticket reopens WHERE deleted tickets are not included. |
# Replies | The number of public agent comments on tickets during the selected time period. | The sum of ticket replies WHERE deleted tickets are not included. |
# Replies [Avg] | The average number of replies on a ticket.
If there is more than one reply on a ticket, each reply will be counted. |
The average of ticket replies WHERE deleted tickets are not included. |
# Solved Tickets | The number of solved or closed tickets. | The number of tickets WHERE ticket status is Solved or Closed. |
# Tickets | The total number of tickets. | The count of ticket IDs determined by ticket tag IDs WHERE deleted tickets and tickets with a delete flag are not included. |
# Unsolved Tickets | The number of unsolved tickets. This includes tickets in every status except Solved and Closed. | The number of tickets WHERE ticket status is not in Solved or Closed. |
Ticket Age (days) [AVG] | The average age of tickets. | The average number of days between the ticket created date to the present BY ticket ID WHERE deleted tickets are not included. |
Ticket age (days) [MAX] | A ticket's lifespan from the creation date to the close date. | The max age between ticket created date to the present BY ticket ID WHERE deleted tickets are not included. |
Ticket Age (Open Tickets) | The age of tickets not in the Deleted, Solved, or Closed statuses. | The max age between the ticket created date to the present BY Ticket Id WHERE ticket status is not Solved, Deleted, or Closed. |
Current backlog | The current number of tickets that are not in the Solved or Closed status. This includes New, Open, Pending, and On-hold. | The count of ticket IDs WHERE ticket status is not Solved, Closed, or Deleted. |
# Backlog Tickets | The number of backlog tickets. This is the total number of backlog tickets throughout history. This metric is located in the Backlog folder. | The sum of the backlog ticket count. |
User and organization metrics
The metrics below are located under the Users and Organizations folder in Insights.
Metric | Definition | How it's calculated |
---|---|---|
# End-Users | The number of total end-users, including both active and suspended users. | The count of users WHERE the user is active AND the user role is end-user. |
# Organizations | The number of organizations. | The count of organizations WHERE deleted organizations are not included. |
# Users | The number of active users. | The count of users WHERE the user is active. |
Days Since Last Log-in | The number of days since an agent or user last logged-in. This is calculated from their last log-in date, not from the last time they used Zendesk Support to the present date. | The last date the user logged in BY user WHERE the user is active. |
Events
You can use the metrics described in this section to report on your different ticket events.
Ticket event metrics
The metrics below are located under the Ticket Events folder in Insights.
Metric | Definition | How it's calculated |
---|---|---|
# Group Reassignments | The number of tickets reassigned to different groups. | The number of ticket updates WHERE the text field change is group AND deleted tickets are not included. |
# Tickets Created | The number of tickets created (received) in the selected time period or as a total amount. | The count of ticket IDs determined by ticket text field change WHERE the beginning date is the ticket created date BY ticket ID AND deleted tickets are not included. |
# Tickets Deleted | The number of deleted tickets | The number of ticket updates WHERE the text field is status AND the new text field status value is deleted. |
# Ticket Events | The number of events or changes to a ticket's system fields and text fields. | The count of ticket text field change WHERE deleted tickets are not included. |
# Tickets Reopened | The number of tickets where the ticket status was Solved, and then reopened into a new unsolved status. | The count of ticket IDs determined by ticket text field changes WHERE the text field is status AND the new text field status value is Open, Pending, Hold AND previous text field status value is Solved AND deleted tickets are not included. |
# Ticket Updates | The number of ticket updates during the selected time period.
This metric does not count updates that consist only of a comment and/or numeric field changes. |
The count of ticket updates determined by ticket text field change. |
# Tickets Solved | The number of tickets marked as Solved | The count of number of tickets |
[GeoChart] # Tickets Created | The number of tickets created displayed in the GeoChart widget. | The number of tickets created WHERE _Filter Event Dates filters the created date to the dashboard timeline. |
Ticket comment metrics
The metrics below are located under the Ticket Comments folder in Insights
Metric | Definition | How it's calculated |
---|---|---|
# Private Comments | The number of private comments on tickets. | The number of total comments WHERE public comments are not included (false). |
# Public Comments | The number of total public comments on tickets. | The number of total comments WHERE public comments are included (true). |
# Total Comments | The total number of both public and private comments on tickets. | The count of tickets updates WHERE tickets are flagged with a comment AND deleted tickets are not included |
Time-based events
You can use the metrics described in this section to report on your different time related events.
Time metrics
The metrics below are located under the Time Based folder in Insights.
Metric | Definition | How it's calculated |
---|---|---|
Agent Wait Times (hrs) [Mdn] | The median hours tickets spend in the Pending status.
If a ticket returns to Pending multiple times, all hours will be recorded. |
The median agent wait time (in minutes) divided by 60 WHERE deleted tickets are not included. |
Duration Since Last Change [Text Field] (hrs) | The median amount of time since a change was made to a ticket's text field or system field. | The sum of the text field duration (in minutes) divided by 60 WHERE deleted tickets are not included. |
First Reply Time (hrs) [Mdn] | The median hours before a first reply is made on a ticket. | The median first reply time (in minutes) divided by 60 WHERE deleted tickets are not included. |
First Reply Time (min) [Mdn] | The median minutes until a ticket's first reply. This includes all minutes, not just business hours. | The median first reply time (in minutes) WHERE deleted tickets are not included. |
First Resolution Time (hrs) [Mdn] | The median hours before a ticket is first resolved. | The median first resolution time (in minutes) divided by 60 WHERE deleted tickets are not included. |
First Resolution Time (min) [Mdn] | The median minutes until a ticket is first resolved. | The median first resolution time (in minutes) WHERE deleted tickets are not included. |
Full Resolution Time (hrs) [Mdn] | The median hours before a ticket is fully resolved. | The median full resolution time (in minutes) divided by 60 WHERE deleted tickets are not included. |
Full Resolution Time (min) [Mdn] | The median minutes until a ticket is fully resolved. | The median full resolution time (in minutes) WHERE deleted tickets are not included. |
Fast First Resolution (<2 hrs) | The number of tickets that were first resolved in less than two hours. | The number of solved tickets WHERE the sum of first resolution time (in minutes) divided by 60 BY ticket ID is less than 2. |
Normal First Resolution (<8 hrs) | The number of tickets first resolved in less than eight hours. | The number of solved tickets WHERE the sum of first resolution time (in minutes) divided by 60 BY ticket ID is between 2 and 8. |
Slow First Resolution (>8 hrs) | The number of tickets that were first resolved in more than eight hours. | The number of solved tickets WHERE the sum of first resolution time (in minutes) divided by 60 BY ticket ID is greater than 8. |
Hold Time (hrs) [Mdn] | The median hours tickets spend in the On-hold status. | The median On hold time (in minutes) divided by 60 WHERE deleted tickets are not included. |
Requester Wait time (hrs) [Mdn] | The median hours a ticket spends in the New, Open, and On-Hold statuses. This value is recalculated each time the ticket status changes. | The median requester wait time (in minutes) divided by 60 WHERE deleted tickets are not included. |
Business hours metrics
The metrics below are located under the Business Hours folder in Insights.
Metric | Definition | How it's calculated |
---|---|---|
[Biz Hrs] Agent Wait Time (hrs) [Mdn] | The median hours tickets spend in the Pending status within your set business hours.
If a ticket returns to Pending multiple times, all hours will be recorded. |
The median agent wait time (in minutes) within business hours divided by 60 WHERE deleted tickets are not included. |
[Biz Hrs] First Reply Time (hrs) [Mdn] | The median hours before a ticket is first replied to publicly within your set business hours. | The median first reply time (in minutes) within business hours divided by 60 WHERE deleted tickets are not included. |
[Biz Hrs] First Resolution Time (hrs) [Mdn] | The median hours before a ticket is first resolved within business hours. | The median first resolution time (in minutes) within business hours divided by 60 WHERE deleted tickets are not included. |
[Biz Hrs] Full Resolution Time (hrs) [Mdn] | The median hours until tickets are fully resolved within your set business hours. | The median full resolution time (in minutes) within business hours divided by 60 WHERE deleted tickets are not included. |
[Biz Hrs] On Hold Time (hrs) [Mdn] | The median hours tickets spend in the On-hold status within your set business hours. | The median On hold time (in minutes) within business hours divided by 60 WHERE deleted tickets are not included. |
[Biz Hrs] Agent Wait Time (min) [Mdn] | The median number of minutes a ticket spends in the Pending status within your set business hours. | The median agent wait time (in minutes) within business hours WHERE deleted tickets are not included. |
[Biz Hrs] First Reply Time (min) [Mdn] | The median minutes before a ticket's first reply within your set business hours. | The median first reply time (in minutes) within business hours WHERE deleted tickets are not included. |
[Biz Hrs] First Resolution Time (min) [Mdn] | The median minutes before tickets are first resolved within your set business hours.
A ticket can have only one first resolve time, and it will never change. |
The median first resolution time (in minutes) within business hours WHERE deleted tickets are not included. |
[Biz Hrs] Full Resolution Time (min) [Mdn] | The median minutes until a ticket is fully resolved within your set business hours.
If tickets are reopened, the time will be recalculated until a ticket returns to Solved. |
The median full resolution time (in minutes) within business hours WHERE deleted tickets are not included. |
[Biz Hrs] On Hold Time (min) [Mdn] | The median number of minutes a ticket spends in the On-hold status within your set business hours. | The median On hold time (in minutes) within business hours WHERE deleted tickets are not included. |
[Biz Hrs] Requester Wait Time (hrs) [Mdn] | The median hours a ticket spends in the New, Open, or On-hold statuses during business hours. This value is recalculated each time the ticket status changes. | The median requester wait time (in minutes) within business hours divided by 60 WHERE deleted tickets are not included. |
Service Level Agreements (SLAs)
You can use the metrics described in this section to report on your Service Level Agreements (SLAs). These metrics are located under the Ticket SLAs folder in Insights.
Metric | Definition | How it's calculated |
---|---|---|
# SLAs Achieved | The number of SLA targets that were achieved. | The count of all ticket SLAs WHERE the SLA metric status is achieved AND deleted tickets are not included. If null replace with 0. |
# SLAs Breached (Total) | The count of all ticket SLAs where the SLA metric status is breached AND deleted tickets are not included. If null replace with 0. | SLA metric status is breached (active) AND deleted tickets are not included. If null replace with 0. |
# SLA tickets | The number of tickets with an SLA policy applied. | The count of tickets IDs determined by the number of all ticket SLAs. |
% Achieved | The percentage of tickets where the SLA policy was achieved out of the total number of both breached and achieved. | The number of SLAs achieved divided by the number of SLAs breached (total) added to the number of SLAs achieved. |
% Breached | The percentage of tickets where the SLA metric breached its target divided by total number of instances where that SLA metric was measured. | The number of SLAs breached divided by the number of SLAs achieved (total) added to the number of SLAs breached. |
SLA Breach time [Mdn] | The median amount of time the SLA metric surpassed the target time. | The median SLA metric value minus SLA metric target WHERE SLA metric status is breached (active) or breached (fulfilled). If null replace with 0. |
SLA Metric Target [Median] | The median target time (in minutes). | The median SLA Metric Target. If null replace with 0 |
SLA Metric Value | The median amount of time (in minutes) the metric was active. | The median SLA Metric Value. If null replace with 0. |
Surveys
You can use the metrics described in this section to report on your Net Promoter Score℠ (NPS® ) and customer satisfaction survey results.
NPS® survey metrics
The metrics below are located under NPS® Survey folder in Insights.
Metric | Definition | How it's calculated |
---|---|---|
# NPS® Deliveries | The number of NPS surveys delivered. | The count of NPS delivery IDs by the NPS recipient ID. |
# NPS® Detractor Ratings | The number of NPS ratings that received a score of 6 or less. | The number of NPS responses WHERE NPS rating is 0, 1, 2, 3, 4, 5, or 6. |
# NPS® Passive Ratings | The number of NPS survey responses with a 7 or 8 rating. | The number of NPS responses WHERE NPS rating is 7 or 8. |
# NPS® Promoter Ratings | The number of NPS ratings with a 9 or 10. | The number of NPS responses WHERE NPS rating is a 9 or 10. |
# NPS® Recipients | The number of recipients that received a NPS survey. | The count of NPS recipients IDs. |
# NPS® Responses | The number of NPS survey responses received. | The count of NPS recipients ID WHERE NPS rating is not 11. |
% NPS® Detractors | The percentage of NPS surveys with a 6 or less rating out of the total number of NPS survey responses. | The number of NPS detractor ratings divided by number of NPS responses. |
% NPS® Passives | The percentage of NPS® surveys with a 7 or 8 rating out of the total NPS survey responses. | The number of NPS passive ratings divided by the number of NPS responses. |
% NPS® Promoters | The percentage of NPS ratings that received a 9 or 10 out of the total number of NPS responses. | The number of NPS promoter ratings divided by NPS responses. |
% NPS® Response Rate | The percentage of NPS survey responses out of the total number of users who received NPS surveys. | The number of NPS responses divided by NPS Recipients |
Median NPS Rating | The median NPS rating during the selected time period.
If no time attribute is selected, the metric displays your median NPS rating so far. |
The median NPS rating. |
Net Promoter Score℠ | The overall Net Promoter Score. | The percentage of Net Promoters (if null replace with 0) minus the percentage of Net Detractors (if null replace with 0) multiplied by 100 WHERE NPS deliveries is greater than 0. |
Satisfaction survey metrics
The metrics below are located under the Satisfaction Surveys folder in Insights.
Metric | Definition | How it's calculated |
---|---|---|
# Satisfied | The number of good satisfaction survey responses. | The count of ticket IDs determined by satisfaction survey change (if null replace with 0) WHERE the new satisfaction value is good AND deleted tickets are not included AND ticket status is Solved or Closed. |
# Satisfaction Change | The number of satisfaction survey responses that changed to bad or good. | The count of ticket IDs determined by satisfaction survey change (if null than replace with 0) WHERE the new satisfaction value is Bad or Good AND deleted tickets are not included AND Ticket status is Solved or Closed. |
# Satisfaction Offered | The number of satisfaction surveys offered when the ticket is in the Solved or Closed status. | The count of ticket IDs determined by satisfaction survey change WHERE ticket status is Solved or Closed AND ticket satisfaction score is Bad, Good, or Offered. |
# Satisfaction Responses | The total number of satisfaction responses. | The count of ticket IDs determined by satisfaction survey change WHERE ticket satisfaction score is Bad or Good AND deleted tickets are not included AND ticket status is Solved or Closed. |
# Unsatisfied | The number of surveys with a bad satisfaction response. | The count of ticket IDs determined by satisfaction survey change WHERE ticket status is Solved or Closed AND ticket satisfaction score is bad. |
% Dissatisfaction Score | The percentage of dissatisfied survey responses out of the total satisfaction survey responses received. | 1 minus (the number of satisfied responses divided by the number of total satisfaction survey responses). |
% Satisfaction Response Rate | The percentage of satisfaction surveys responded to out of the total satisfaction surveys offered. | The number of satisfaction responses divided by the number of satisfaction surveys offered. |
% Satisfaction Score | The percentage of good satisfaction responses out of the total satisfaction survey responses. | The number of satisfied responses divided by the number of satisfaction responses changed. |
Calls
You can use the Calls metrics to report on your Zendesk Talk conversations. These metrics are located under the Calls folder in Insights.
Metric | Definition | How it's calculated |
---|---|---|
Call Hold Time [Sum] | Total call time on hold | Sum aggregation of the 'Call Hold Time' fact |
Wrap up [Sum] | Total time in wrap-up | Sum aggregation of the 'Call Leg Wrap Up Time' fact |
Time spent in IVR | Total time customers spend in IVR before making a selection and being routed to an agent based on their selection | Max aggregation of 'Time spent in IVR' fact |
# Accepted Calls | The number of calls agents accepted. Does not include calls that agents have missed or declined. | If the Call Leg does not exist, then the Record of Calls values are counted where the call is inbound, the call leg status is completed, and the call leg type is agent. |
# Missed Calls | Number of calls an agent missed. | Similar to # Accepted Calls, but call leg status is missed. |
# Declined Calls | Number of calls an agent declined | Similar to # Accepted Calls, but call leg status is declined. |
# Calls abandoned | Total number of calls where a customer hung up while waiting to talk with an agent. | Number of calls where the call completion status is abandoned in queue, IVR, voicemail, or on-hold. |
# Calls abandoned in voicemail | Total number of calls where customer hung up after being sent to voicemail | Number of calls where the call completion status is abandoned in voicemail |
# Calls abandoned in on-hold | Total number of calls where customer hung up while on hold | Number of calls where the call completion status is abandoned on hold |
# Calls abandoned in queue | Total number of calls where customer hung up while waiting in the queue | Number of calls where the call completion status is abandoned in queue |
# Calls abandoned in IVR | Number of calls where customer hung up while going through the IVR tree | Number of calls where the call completion status is abandoned in IVR |
# Abandoned Calls (% change) | The percentage change of abandoned calls this period versus last period. | Number of calls abandoned this period divided by the number of calls abandoned in the previous period. |
Talk time | Net talk time when a customer is connected to an agent returned in seconds. Does not include any hold time. | Leg Duration minus Call Wait Time minus Call Hold Time |
Agent Talk Time | The time agents spend talking with customers. Does not account for exact figures for customer talk times. | The sum of the 'Call Leg Talk Time' fact where the call leg type are agents and the call leg status is completed. |
Total Talk Time | The total talk time per call. Should be used when looking for customer talk time values. | The sum of the maximum Call Talk Time fact by call. |
Leg Duration [Sum] | Total leg duration time in seconds | Sum aggregation of 'Leg Duration' fact |
Call Wait Time [Sum] | Total call wait time | Sum aggregation of 'Call Wait Time' fact |
Call Wait Time abandoned calls [Sum] | Wait time for a call prior to it being abandoned | Call wait time where completion status is abandoned_in_ivr OR abandoned_in_queue OR abandoned_in_voicemail OR abandoned_on_hold |
# Outbound calls | Total number of outbound calls | Number of calls where call direction is outbound |
# Inbound calls | Total number of inbound calls | Number of calls where call direction is inbound |
# Voicemails | Total number of calls that went to voicemail for any reason | Number of calls where voicemail is true |
# Inbound calls (% change) | Percentage change of inbound calls during the selected period compared to inbound calls within the previous period of the same duration as the selected period. | Number of inbound calls of this period divided by number of inbound calls of previous period |
Call Consultation Time [Sum] | Total time in consultation | Sum aggregation of 'Call Consultation Time' fact |
Talk minutes billed [Sum] | Total Talk minutes billed | Sum aggregation of 'Call minutes billed' fact |
IVR Hops [Sum] | Total number of IVR hops | Sum aggregation of 'IVR Hops' fact |
Charges [Sum] | Total amount of charges | Sum aggregation of 'Call charge' fact |
# Voicemails (% change) | Percentage change of voicemails created during the selected period compared to voicemails created within the previous period of the same duration as the selected period. | Number of voicemails of this period divided by number of voicemails of previous period |
# Outbound calls (% change) | Percentage change of outbound calls during the selected period compared to outbound calls within the previous period of the same duration as the selected period. | Number of outbound calls of this period divided by number of outbound calls of previous period |
# Voicemails requested | Number of calls where customer requested to be put through to voicemail by dialing 1 |
Zendesk Chat
You can use the metrics described in this section to report on your different Zendesk Chat features.
Chat engagement time-based metrics begin measuring specifically when an agent interacts with a chat. Other Chat time-based metrics begin measuring when a visitor (or a visitor representative - such as an agent or trigger beginning a chat on behalf of a visitor) interacts with the chat.
Chat metrics
The metrics below relate to chat sessions.
Metric | Definition |
---|---|
# Offline Messages | Total number of offline messages sent by website visitors. |
# Chats | Total number of chats started by visitors or agents. |
# Missed Chats | Total number of chats requested by visitors that were not answered by agents. |
# Served Chats | Total number of chats requested by visitors that were answered by agents. |
# Completed Chats | Total number of served chats that were not dropped by agents. |
# Dropped Chats | Total number of chats where the agent did not respond to the visitor's last message. |
# Triggered Chats | Total number of chats in which a trigger fired. |
# Proactive Chats | Total number of chats started by an agent. |
# Chats Rated Good | Total number of chats where the visitor's final rating was good. |
# Chats Rated Bad | Total number of chats where the visitor's final rating was bad. |
# Department-Transferred Chats | Total number of chats that were transferred to a department. |
Median Chat Duration | The median duration of chats, from the first to the last message. |
Median Missed Chat Wait Time | For missed chats, the median time visitors waited for a response before leaving. |
Median Dropped Chat Wait Time | For dropped chats, the median time visitors waited for a response before leaving. |
Median Served Chat Wait Time | For served chats, the median time visitors waited before the first response from an agent. |
Median Chat Response Time | For served chats, the median time between visitors' messages and the subsequent agents' messages throughout the chat. |
Median Chat Total Messages | Median of total number of messages between visitor and agents in a chat. |
Median Chat Visitor Messages | Median of total number of visitor messages a chat. |
Median Chat Agent Messages | Median of total number of agents messages a chat. |
Chat Miss Rate | Percentage of ‘Total Missed Chats / Total Chats’ |
Chat Drop Rate | Percentage of ‘Total Dropped Chats / Total Chats’ |
Chat Trigger Rate | Percentage of ‘Total Triggered Chats / Total Chats’ |
Chat Satisfaction Rate | Percentage of ‘Total Chats rated good / (Total chats rated good+Total chats rated bad)’ |
Chat Department Transfer Rate | Percentage of ‘Total Department Transferred Chats / Total Chats |
Chat Skill Fulfillment Rate | Percentage of chats with requested skills that were successfully assigned to an agent with those skills |
% Chats with Duration under 3m | The percentage of chats which lasted under three minutes |
% Chats with Duration between 3m and 6m | The percentage of chats which lasted between three and six minutes |
% Chats with Duration between 6m and 9m | The percentage of chats which lasted between six and nine minutes |
% Chats with Duration between 9m and 12m | The percentage of chats which lasted between nine and 12 minutes |
% Chats with Duration over 12m | The percentage of chats which lasted over 12 minutes |
% Served Chats with Wait Time under 15s | The percentage of served chats where visitors waited under 15 seconds for an agent's first response. |
% Served Chats with Wait Time between 15s and 30s | The percentage of served chats where visitors waited between 15 and 30 seconds for an agent's first response. |
% Served Chats with Wait Time between 30s and 45s | The percentage of served chats where visitors waited between 30 and 45 seconds for an agent's first response. |
% Served Chats with Wait Time between 45s and 1m | The percentage of served chats where visitors waited between 45 seconds and one minute for an agent's first response. |
% Served Chats with Wait Time over 1m | The percentage of served chats where visitors waited over one minute for an agent's first response. |
% Missed Chats with Wait Time under 15 | The percentage of missed chats where visitors waited under 15 seconds before leaving. |
% Missed Chats with Wait Time between 15s and 30s | The percentage of missed chats where visitors waited between 15 and 30 seconds before leaving. |
% Missed Chats with Wait Time between 30s and 45s | The percentage of missed chats where visitors waited between 30 and 45 seconds before leaving. |
% Missed Chats with Wait Time between 45s and 1m | The percentage of missed chats where visitors waited between 45 seconds and one minute before leaving. |
% Missed Chats with Wait Time over 1m | The percentage of missed chats where visitors waited over one minute before leaving. |
% Chats with Response Time under 15s | The percentage of chats with response time under 15 seconds. |
% Chats with Response Time between 15s and 30s | The percentage of chats with response time between 15 and 30 seconds. |
% Chats with Response Time between 30s and 45s | The percentage of chats with response time between 30 and 45 seconds. |
% Chats with Response Time between 45s and 1m | The percentage of chats with response time between 45 seconds and one minute. |
% Chats with Response Time over 1m | The percentage of chats with response time over one minute. |
Chat engagement metrics
Engagement metrics define the total number of chat sessions for a particular agent and contain a more granular level of data. Chat engagement time-based metrics begin measuring specifically when an agent interacts with a chat.
A chat could involve multiple different agents. Each agent is included as one engagement. For example if four agents worked on the same chat, it would be considered four engagements for the chat, but one engagement per agent. The total number of engagements will always be greater than the total number of chats.
Metrics | Definition |
---|---|
# Engagements Rated Good | Total number of engagements in which an agent is rated good. |
# Engagements Rated Bad | Total number of engagements in which an agent is rated bad. |
# Assignments | Total number of engagement which were assigned to the agents. |
# Accepted Assignments | Total number of assigned engagements which were accepted by the agents. |
Engagement Satisfaction Rate | Percentage of ‘Total agent engagements rated good / (Total agent engagements rated (good + bad) )’ |
Engagement Skill Fulfillment Rate | Percentage of chats or department transfers with requested skills, that were successfully assigned to an agent with those skills. |
Acceptance Rate | Percentage of accepted engagements / assigned engagements. |
Total Engagement Duration | Total duration of engagement since an agent joining a chat till agent leaves the chat or chat ends. |
Median Engagement Duration | The median duration of engagement since an agent joining a chat till agent leaves the chat or chat ends. |
Median Engagement Wait Time | The median time visitors waited before the first response from a agent in an engagement. |
Median Engagement Response Time | The median time between visitors' messages and the subsequent agents' messages in a particular engagement. |
Median Engagement Total Messages | Median of total number of messages between visitor and agent in an engagement. |
Median Engagement Visitor Messages | Median of total number of visitor messages in an engagement. |
Median Engagement Agent Messages | Median of total number of agents messages in an engagement. |
% Engagements with Duration under 3m | The percentage of engagements which lasted under three minutes |
% Engagements with Duration between 3m and 6m | The percentage of engagements which lasted between three and six minutes |
% Engagements with Duration between 6m and 9m | The percentage of engagements which lasted between six and nine minutes |
% Engagements with Duration between 9m and 12m | The percentage of engagements which lasted between nine and 12 minutes |
% Engagements with Duration over 12m | The percentage of engagements which lasted over 12 minutes |
% Engagements with Wait Time under 15s | The percentage of engagements where visitors waited under 15 seconds for an agent's first response. |
% Engagements with Wait Time between 15s and 30s | The percentage of engagements where visitors waited between 15 and 30 seconds for an agent's first response. |
% Engagements with Wait Time between 30s and 45s | The percentage of engagements where visitors waited between 30 and 45 seconds for an agent's first response. |
% Engagements with Wait Time between 45s and 1m | The percentage of engagements where visitors waited between 45 seconds and one minute for an agent's first response. |
% Engagements with Wait Time over 1m | The percentage of engagements where visitors waited over one minute for an agent's first response. |
% Engagements with Response Time under 15s | The percentage of engagements with response time under 15 seconds. |
% Engagements with Response Time between 15s and 20s | The percentage of engagements with response time between 15 and 30 seconds. |
% Engagements with Response Time between 30s and 45s | The percentage of engagements with response time between 30 and 45 seconds. |
% Engagements with Response Time between 45s and 1m | The percentage of engagements with response time between 45 seconds and one minute. |
% Engagements with Response Time over 1m | The percentage of engagements with response time over one minute. |
Chat agent activity metrics
The agent activity metrics relate to agents' activities when signed in and their status.
Metric | Definition |
---|---|
Logged In Duration | Total logged in duration of the agents. |
Online Duration | Total duration of the agents where agents had online status. |
Away Duration | Total duration of the agents where agents had away status. |
Invisible Duration | Total duration of the agents where agents had invisible status. |
Chatting Duration | Total duration where agents are engaged in chatting regardless of their status. |
Cumulative Chatting Duration | Agent can get engaged in multiple chats concurrently. This metric represents sum of duration of individual chats where an agent is engaged concurrently. |
Online Chatting Duration | Total chatting duration where agents had online status. |
Away Chatting Duration | Total chatting duration where agents had away status. |
Invisible Chatting Duration | Total chatting duration where agents had invisible status. |
Online Rate | Percentage of total online duration / total logged in duration. |
Away Rate | Percentage of total away duration / total logged in duration |
Invisible Rate | Percentage of total invisible duration / total logged in duration |
Chatting Rate | Percentage of total chatting duration / total logged in duration |
Online Chatting Rate | Percentage of total online chatting duration / total online duration |
Away Chatting Rate | Percentage of total away chatting duration / total away duration |
Invisible Chatting Rate | Percentage of total invisible chatting duration / total invisible duration |
Average Concurrency | Number of concurrent chats an agent is involved at the give time. ( Cumulative chatting duration / Chatting duration ). |
Maximum Concurrency | Maximum number of engagements an agent is involved concurrently at a particular time |
Skills
You can use the Skills metrics to report on Zendesk Support skills-based routing. These metrics are located in the Skills folder in Insights.
Skills metrics
Metric | Definition | How it's calculated |
---|---|---|
# Skill Names | The number of skill names associated with at least one ticket. | Counts the number of skill names that have been used in at least one ticket. |
# Skill Names (% change) | The percentage change of skill names associated with at least one ticket this period versus last period. | Number of skill names used this period divided by number of skill names used in the previous period. |
# Skill Types | The number of skill types associated with at least one ticket. | Counts the number of skill types that have been used in at least one ticket. |
# Skill Types (% change) | The percentage change of skill types associated with at least one ticket this period versus last period. | Number of skill types used this period divided by number of skill types used in the previous period. |
# Tickets with Skills | The number of Support tickets that have a skill associated with them. | Counts the number of tickets that have at least one skill associated with them. |
# Tickets with Skills (% change) | The percentage change of tickets with an associated skill this period versus last period. | Number of tickets with an associated skill this period divided by number of tickets with an associated skill in the previous period. |
# Tickets without Skills | The number of Support tickets that do not have a skill associated with them. | Subtracts the number of tickets with skills from the total number of tickets. |
# Tickets without Skills (% change) | The percentage change of tickets without an associated skill this period versus last period. | Number of tickets without an associated skill this period divided by number of tickets without an associated skill in the previous period. |
Zendesk Guide
You can use the metrics described in this section to report on your different Zendesk Guide features.
Answer Bot metrics
The metrics below are located under the Answer Bot folder in Insights.
Metric | Definition | How it's calculated |
---|---|---|
# Answer Bot attempted resolutions | The number of Answer Bot responses sent. | The count of ticket IDs with an automated response WHERE an Answer Bot suggested article was included. |
# Answer Bot resolutions |
The number of tickets resolved by Answer Bot. Note: Explore does not report when a solve is made where the customer follows an Answer Bot link, navigates to a different article, and solves from there. However, this information is still stored. To report on all solves, consider tagging tickets solved by Answer Bot. |
The count of ticket IDs with an automated response WHERE Answer Bot was used to solve a customer's support request. |
Answer Bot overall click-through-rate | The percentage of Answer Bot suggested articles that were clicked over the total number of Answer Bot responses sent. | The number of Answer Bot suggested articles clicked divided by the number of tickets with an Answer Bot response. |
Answer Bot unique ticket click-through-rate | The percentage of tickets where an Answer Bot article was clicked over the total number of Answer Bot responses sent. | The number of tickets WHERE an Answer Bot article was clicked divided by the number of Answer Bot emails sent. |
# Answer Bot article clicks | The number of clicks on articles suggested by Answer Bot. | The count of all Answer Bot responses sent WHERE an article was clicked. |
# Tickets with Answer Bot article clicks | The number of tickets that included an Answer Bot responses where one of the suggested articles was clicked. | The count of ticket IDs with an automated response WHERE a suggested article was clicked. |
Answer Bot attempt:solve ratio | The number of times an Answer Bot suggested article solved a customer’s support request over the total number of Answer Bot responses sent. |
The count of tickets where the Answer Bot suggested article solved the support request divide by the total number of tickets with an Answer bot response BY Article ID. |
Answer Bot resolution rate | The percentage of support requests that were resolved with Answer Bot over the total number of Answer Bot responses. | The number of solved tickets with an Answer Bot response over the total number of responses sent |
MDN Answer Bot time-to-click | The median number of hours, minutes, and seconds between Answer Bot suggesting an answer and the customer clicking on one of the articles. | The median between when a customer clicked an article and when the Answer Bot response was sent WHERE an article was clicked. |
MDN Answer Bot time-to-resolve | The median number of hours, minutes and seconds between Answer Bot suggesting an answer and the customer confirming their ticket as solved. | The median between when the support request was marked as solved and when the Answer Bot response was sent WHERE the article solved the support request. |
Knowledge Capture metrics
The metrics below are located under the Knowledge Capture folder in Insights.
Metric | Definition | How it's created |
---|---|---|
# of Create Events | The number of ticket updates that included a Knowledge Capture create event. | The count of ticket updates with a Knowledge Capture event BY ticket ID WHERE the event type was knowledge_captured. |
# of Event ID | The number of ticket updates that included a Knowledge Capture event. | The count of ticket updates with a Knowledge Capture event ID. |
# of Flag Events | The number of ticket updates that included a Knowledge Capture flag event. | The count of ticket updates with a Knowledge Capture event BY ticket ID WHERE the event type was knowledge_flagged. |
# of Link Events | The number of ticket updates that included a Knowledge Capture link event. | The count of ticket updates with a Knowledge Capture event BY ticket ID WHERE the event type was knowledge_linked. |
# Solved Tickets with KC Create | The number of tickets solved with at least one Knowledge Capture create event. | The number of solved tickets BY ticket ID WHERE the maximum number of create events is greater than 0 BY ticket ID. |
# Solved Tickets with KC Events | The number of tickets solved with at least one Knowledge Capture event. | The number of solved tickets BY ticket ID WHERE the maximum number of Knowledge Capture events is greater than 0. If this value is null, then replace with 0. |
# Solved Tickets with KC Flag | The number of tickets solved with at least one Knowledge Capture flag event. | The number of solved tickets BY ticket ID WHERE the maximum number of Knowledge Capture flag events is greater than 0 BY ticket ID. |
# Solved Tickets with KC Link | The number of tickets solved with at least one Knowledge Capture link event. | The number of solved tickets BY ticket ID WHERE the maximum number of Knowledge Capture link events is greater than 0 BY ticket ID. |
% Change in Solved Tickets with KC Create | The percentage change in solved tickets between the last 29 days and the previous 29 days with a Knowledge Capture create event. | The number of solved tickets with a Knowledge Capture create event BY ticket ID WHERE the ticket was solved within the last 29 days divided by the number of solved tickets with a Knowledge Capture create event WHERE the ticket was solved within the previous 29 days. |
% Change in Solved Tickets with KC Events | The percentage change in solved tickets between the last 29 days and the previous 29 days with a Knowledge Capture event. | The number of solved tickets with a Knowledge Capture event WHERE the ticket was solved within the last 29 days divided by the number of solved tickets with a Knowledge Capture event WHERE the ticket was solved within the previous 29 days |
% Change in Solved Tickets with KC Flag | The percentage change in solved tickets between the last 29 days and the previous 29 days with a Knowledge Capture flag event. | The number of solved tickets with a Knowledge Capture flag event WHERE the ticket was solved within the last 29 days divided by the number of solved tickets with a Knowledge Capture flag event WHERE the ticket was solved within the previous 29 days. |
% Change in Solved Tickets with KC Link | The percentage change in solved tickets between the last 29 days and the previous 29 days with a Knowledge Capture link event. | The number of solved tickets with a Knowledge Capture link event WHERE the ticket was solved within the last 29 days divided by the number of solved tickets with a Knowledge Capture link events WHERE the ticket was solved within the previous 29 days |
% Tickets Solved with KC Create | The percentage of solved tickets with a Knowledge Capture create event. | The number of solved tickets containing a Knowledge Capture create event divided by the number of solved tickets BY ticket ID. |
% Tickets Solved with KC Events | The percentage of solved tickets with a Knowledge Capture event. | The number of solved tickets containing a Knowledge Capture event divided by the number of solved tickets BY ticket ID. |
% Tickets Solved with KC Flag | The percentage of solved tickets with a Knowledge Capture flag event. | The number of solved tickets containing a Knowledge Capture flag event divided by the number of solved tickets BY ticket ID. |
% Tickets Solved with KC link | The percentage of solved tickets with a Knowledge Capture link event. | The number of solved tickets containing a Knowledge Capture link event divided by the number of solved tickets BY ticket ID. |
Metric Filters
The _spFilters and _Filters are special metrics that bridge together usually disconnected dimensions. After adding your report to a dashboard, you can activate these metric filters by selecting corresponding dashboard filters. There are two types of corresponding dashboard filters, User filters and Timeline filters. For more information on disconnect dimensions see, Understanding disconnected date dimensions.
These metrics aren't added into the 'What' panel, but instead are selected as numeric range filters after you've finished building your report. The third column of both tables below display the numeric range information for each metric filter.
The following filters can only be used when the Date (Timeline) dashboard filter is applied.
Filter | Definition | Numeric range |
---|---|---|
_Filter Backlog Date | The number of backlog tickets (New, Open, Pending) in the selected time period. | Attribute: Date (Event)
Metric and Range: _Filter Backlog Date is greater than 0 |
_Filter Backlog Date Most Recent Day | The number of backlog tickets on the most recent day of the selected time period. | Attribute: Date (Event)
Metric and Range: _Filter Backlog Date Most Recent Day is greater than 0 |
_Filter Event Date | The number of events only within the selected time period. | Attribute: Date (Event)
Metric and Range: _Filter Event Date is greater than 0 |
_Filter NPS Rated Date | The NPS ratings during the selected time period. | Attribute: Date (NPS Rated)
Metric and Range: _Filter NPS Rated Date is greater than 0 |
_Filter Org Created Date | The number of organizations created during the selected time period. | Attribute: Date (Organization Created)
Metric and Range: _Filter Org Created Date is greater than 0 |
_Filter Ticket Created Date | The number of tickets created during the selected time period. | Attribute: Date (Ticket Created)
Metric and Range: _Filter Ticket Created Date is greater than 0 |
_Filter Ticket Solved Date | The number of tickets solved during the selected time period. | Attribute: Date (Ticket Solved)
Metric and Range: _Filter Ticket Solved Date is greater than 0 |
_Filter User Created Date | The number of users created during the selected time period. | Attribute: Date (User Created)
Metric and Range: _Filter User Created Date is greater than 0 |
_spFilter Backlog (Last Day of Month) | The number of backlog tickets on the last day of each month during the selected time period. | Attribute: Month/Year (Event)
Metric and Range: _spFilter Backlog (Last Day of Month) is greater than 0 |
_spFilter Backlog (Max Day) | The number of backlog tickets on the last day of the selected time period. | Attribute: Date (Event)
Metric and Range: _spFilter Backlog (Max Day) is greater than 0 |
_spFilter Backlog (Min Day) | The number of backlog tickets on the first day of the selected time range. | Attribute: Date (Event)
Metric and Range: _spFilter Backlog (Min Day) is greater than 0 |
_spFilter Created Date (Previous Period) | The number of tickets created during the period of time previous to your selected time period. | Attribute: Date (Ticket Created)
Metric and Range: _spFilter Created Date (Previous Period) is greater than 0 |
_spFilter Event Date (6 months) | The number of events within six months previous to the selected time period. | Attribute: Date (Event)
Metric and Range: _spFilter Event Date (6 months) is greater than 0 |
_spFilter Event Date (12 months) | The number of events within 12 months previous to the selected time period. | Attribute: Date (Event)
Metric and Range: _spFilter Event Date (12 months) is greater than 0 |
_spFilter Event Date (Previous Period) | The number of events during the period of time previous to the selected time period. | Attribute: Date (Event)
Metric and Range: _spFilter Event Date (Previous Period) is greater than 0 |
_spFilter Ticket Created (6 Months) | The number of tickets created within six months previous to the selected time range. | Attribute: Date (Ticket Created)
Metric and Range: _spFilter Ticket Created Date (6 Months) is greater than 0 |
_spFilter Ticket Created (12 Months) | The number of tickets created within 12 months previous to the selected time range. | Attribute: Date (Ticket Created)
Metric and Range: _spFilter Ticket Created (12 Months) is greater than 0 |
_spFilter Ticket Solved (6 Months) | The number of tickets solved within six months previous to the selected time range. | Attribute: Date (Ticket Solved)
Metric and Range: _spFilter Ticket Solved (6 months) is greater than 0 |
_spFilter Ticket Solved (12 Months) | The number of tickets solved within 12 months previous to the selected time range. | Attribute: Date (Ticket Solved)
Metric and Range: _spFilter Ticket Solved (12 months) is greater than 0 |
_spFilter Solved Date (Previous Period) | The number of tickets solved within the period of time previous to the selected time range. | Attribute: Date (Ticket Solved)
Metric and Range: _spFilter Ticket Solved (Previous Period) is greater than 0 |
_spFilter Org Created (prior to BOP) | The number of organizations created before the set beginning date of the selected time range. | Attribute: Date (Organization Created)
Metric and Range: _spFilter Org Created (prior to BOP) is greater than 0 |
_spFilter NPS Rated (6 Months) | The number of NPS ratings within six months previous to the selected time range. | Attribute: Date (NPS Rated)
Metric and range: _spFilter NPS Rated (6 Months) is greater than 0 |
_spFilter NPS Rated Date (Previous Period) | The number of NPS ratings within the period of time previous to the selected time period. | Attribute: Date (NPS Rated)
Metric and range: _spFilter NPS Rated Date (Previous period) is greater than 0 |
The following metric filters are used to restrict report results to selected users. They can only be activated when the User filter is added to the dashboard.
Filter | Definition | Numeric range |
---|---|---|
_Filter Ticket Assignee (Current) | The selected agent's number of replies, reopens, or any selected ticket metric. | Attribute: Ticket Assignee
Metric and Range: _Filter Ticket Assignee (Current) is greater than 0 |
_Filter Ticket Assignee (Historic) | The number of ticket updates made when the selected user was the assignee. | Attribute: Ticket Assignee (Historic)
Metric and Range: _Filter Ticket Assignee (Historic) is greater than 0 |
_Filter Backlog Assignee | The number of backlog tickets for the selected agent. | Attribute: Backlog Assignee
Metric and Range: _Filter Backlog Assignee is greater than 0 |
_Filter Updater | The number of times the selected agent has updated a ticket. | Attribute: Updater
Metric and Range: _Filter Updater is greater than 0 |
_Filter User | This filter enables you to show any metric that can be used with the user attribute for only your selected agent. | Attribute: User
Metric and Range: _Filter User is greater than 0 |
Team Publishing metrics
You can use the Guide Team Publishing metrics to report on the Zendesk Guide Team Publishing workflow. These metrics are located in the Team Publishing folder in Insights.
Metric | Definition | How it's calculated |
---|---|---|
# of Active Agents (Guide) | The number of agents who have interacted with articles, for example, updated or created an article. | Counts the number of users who have article event IDs associated with them. |
# of Active Agents (Guide) (% change) | The percentage change in the number of agents who have interacted with articles. | The number of users who have article event IDs associated with them in this period divided by the number from the previous period. |
# of Article Approved Events | The number of article approved events. | Counts the number of events with type article_translation_approved_for_publishing. |
# of Article Approved Events (% change) | The percentage change in the number of approved articles this period versus last period. | The number of article approved events in this period divided by the number from the previous period. |
# of Article Assigned Events | The number of article assigned events. | Counts the number of events with type article_translation_assigned. |
# of Article Assigned Events (% change) | The percentage change in the number of articles that were assigned to another user this period versus last period. | The number of article assigned events in this period divided by the number from the previous period. |
# of Article Created Events | The number of article created events. | Counts the number of events with type article_added. |
# of Article Created Events (% change) | The percentage change in the number of created articles this period versus last period. | The number of article created events in this period divided by the number from the previous period. |
# of Article Edited Events | The number of article edited events. | Counts the number of events with type article_translation_edited. |
# of Article Edited Events (% change) | The percentage change in the number of articles that were edited this period versus last period. | The number of article edited events in this period divided by the number from the previous period. |
# of Article Published Events | The number of article published events. | Counts the number of events with type article_translation_published. |
# of Article Published Events (% change) | The percentage change in the number of published articles this period versus last period. | The number of article published events in this period divided by the number from the previous period. |
# of Article Submitted for Review Events | The number of article submitted for review events. | Counts the number events with type article_translation_submitted_for_review. |
# of Article Submitted for Review Events (% change) | The percentage change in the number of articles that were assigned to another user for review this period versus last period. | The number of article submitted for review events in this period divided by the number from the previous period. |
# of Total Agents (Guide) | The number of agents in your Zendesk instance. | Counts the number of users whose role is either Agent, or Admin. |
% of Active Agents (Guide) | The percentage of your agents who have interacted with articles, for example, updated or created an article. | The number of agents who have article event IDs associated with them divided by the total number of agents. |
% of Active Agents (Guide) (% point change) | The percentage point change in the percentage of active agents this period versus the last period. | Subtracts the number of active agents in the last period from the number of active agents in this period. |
51 Comments
From the descriptions, it looks like the three Ticket Age metrics all keeping counting even when a ticket is solved of closed. They do a comparison to 'Present' rather than to 'Closed Date'. Is this correct?
Ticket Age (days) [AVG]
Ticket age (days) [MAX]
Ticket Age (Open Tickets)
I would be more interested in:
Average age of Unresolved tickets
Average age of Tickets when Solved
Average age of all tickets (combination of the above)
Does anyone else have an example of these?
Hi Tom,
You are correct - Ticket Age (days) [AVG] and Ticket age (days) [MAX] will measure the age of a ticket from the day it was created to today, regardless of its status.
Making custom metrics for your own needs based on the default metrics should be pretty straightforward:
Average age of Unresolved tickets: Take the "Ticket Age (Open Tickets)" metric, make a new copy of it, and replace "MAX" with "AVG" in its MAQL.
Average age of Tickets when Solved: I duplicated the "Ticket Age (days) [AVG]" metric and modified it slightly to calculate the number of days between the date a ticket was created and the date a ticket was solved:
SELECT AVG(SELECT Date (Ticket Solved) - (SELECT Date (Ticket Created) BY Ticket Id)) WHERE Ticket Status IN (Closed, Solved)
Otherwise, if you mean you want to combine the average age of unsolved tickets (today minus Date (Ticket Created)) and the average age of the tickets when they were solved (Date (Ticket Solved) minus Date (Ticket Created)), I don't think that is possible with Insights. My best recommendation in that case is to use the two metrics I described above side-by-side on a dashboard and compare them.
Hope that helps! Please let us know if we can be of further assistance or if you'd like more detail on how to make the metrics.
Hi there!
My team uses an open-pool ticket system where, once re-opened with a response from the requester, it goes back into the unassigned pool. Because of this system, many tickets get "Solved" more than once, often by different Agents. Does "# of Tickets Solved" include multiple Solves on the same ticket? Or does it just count once + get attributed to that person?
Thanks!
Looking through the metrics, I've noticed there are two types of solved ticket metrics.
What's the difference between how these work. I'm having trouble understanding the first one.
1. # Tickets Solved
SELECT IFNULL(COUNT(Ticket Id, Ticket Text Field Change), 0) WHERE [Text Field] New Value IN ([Status] solved, [Status] closed) AND [Text Field] Previous Value <> [Status] solved AND Ticket Status IN (Solved, Closed) AND Date (Event) = (SELECT MAX(SELECT Date (Ticket Solved) BY Ticket Id) BY Ticket Id)
2. # Solved Tickets
SELECT # Tickets WHERE Ticket Status IN (Solved,Closed)
Hi Alex!
Functionally, there isn't any difference between the two metrics. The longer definition in the first metric allows solved tickets to be sliced by Event date attributes in addition to Ticket Solved date attributes. This is so the results from the # Tickets Solved metric would make sense alongside other metrics that might not make sense using Ticket Solved date attributes.
I hope this helps-- Happy reporting!
Hi Bianca!
# Tickets Solved only sees the final solve on a given ticket. Who gets the credit depends on how you slice it! If you use Ticket Assignee (Historic), it'll attribute the solve to the first assignee on the ticket. If you use Ticket Assignee, it'll attribute the solve to the ticket's assignee when the ticket was solved. And if you use Updater, it'll attribute the solve to the person or process that updated the ticket to Solved.
Thanks for your question!
Hi,
If I look at number of group stations for a specific group does the number mean the number of tickets that have ended up in the group? Or the number of tickets which has left the group?
e.g 1st line # of group stations is 56. Is the number showing number of tickets that has been moved from 1st line or tickets being moved into 1st line?
Hi Team,
Our group is trying to create a report that shows the % of tickets created and solved by agent. Basically we are trying to measure the amount of work each agent is doing on a weekly basis.
I already have a report that shows me # of Tickets Solved and # of Tickets Created by each agent, but I don't know how to switch the results to a percentage.
Any suggestions?
Thanks!
Hi Monica!
For this, you’ll need to create a custom metric. If I understand you correctly, you’ll need to create two different metrics: one for % Tickets Created and one for % Tickets Solved. The metrics you want are:
SELECT # Tickets Solved/ (SELECT # Tickets Solved BY ALL OTHER)
and
SELECT # Tickets Created/ (SELECT # Tickets Created BY ALL OTHER)
For your report, you’ll select these two metrics and then select Ticket Assignee under the How section. The report will show a distribution of how many tickets are created and solved for each of your assignees by percentage.
Hey Gurunn,
When you create a report for Group Stations by Group Name the number you're seeing is the # of tickets that have been changed to that group.
Thanks for your question!
Hi,
I am trying to create a report for the number of tickets that have been changed from a particular ticket group to another ticket group. I know the names of both the ticket groups.
Any suggestions on how this can be created?
Thanks in advance!
Hey Jill!
This is an interesting question...let me see if I can get some of our Insights gurus in here to help you out!
Hi Jill!
I would recommend checking out our article on Building custom metrics for the events model-- you're going to want to specify the groups you're interested in using the [Text Field] New Value and [Text Field] Previous Value attributes to pull tickets that had an update submitted that changed groups in the way you've specified.
I hope this helps! Happy reporting!
Jill
That is a really good suggestion for a metric.
Here is an example of counting the number of times the group is changed from the development group to the support group.
Hi.
Im missing the option in the image. Why my zendesk don't give me this? I need it to create a report. Can someone explain?
Best regards!
Hello there,
Hello Diogo,
I am going to be sending you a ticket shortly so that I can get some more information about your account.
We can continue our conversation there!
Hello Warren,
I'd like to gather a bit more information about your reporting needs. I'd like to pull your request into a ticket and see if we can get your question answered!
Hey!
I'm trying to measure satisfaction of all the tickets our three different technical support groups touched.
We have a first line support which keep all the contact with our customers but when it comes to database-changes and such our technical support have to be involved. Our first line agents then send the tickets to one of these groups (depending on question). A agent in the technical support group sends the ticket back to the supportgroup (without assigning the ticket to themselves).
I figured I could perhaps solve this by using ticket group (historic) since the tickets I wish to measure should have at one time or another been assigned to one of these groups - however I'm not getting the results I should. Any idea on how to solve this?
Hi Daniel!
If I understand you question correctly, you specifically want to measure satisfaction on tickets that have been touched by all three of your support groups. Let me know if that's not right!
If that's the case, can you tell me how you're looping these other teams onto the tickets if they're not actually being assigned?
My thought here is that you can add tags to those tickets to identify that they've been escalated and then filter your report results to measure just tickets that contain those tags, but the feasibility of that is going to depend on your escalation process, I think.
Hi Jessie!
I might have been a bit unclear in my message, I just want to measure the satisfaction separate for each group which touched the ticket. So for instance I have my first line support group: "Support", my first second-line supportgroup "Techsupport", my second second-line supportgroup "Integration support" and my third second-line supportgroup "Conversions".
90-95% of all tickets come to first line supportgroup "Support" first but in 5% of cases they have to be escalated to one of the three second-line supportgroups.
I want a report to measure all the tickets that has touched each second-line separately, i.e:
Group Satisfaction
Techsupport 85%
Integration support 75%
Conversions 80%
The purpose is to measure how (and if) satisfaction% is changed from a normal first-line support ticket in comparison to tickets escalated to a second-line support. Since second-line support-tickets usually takes longer time I would guess the satisfaction drops when being escalated.
Hi Daniel,
Based on what you're wanting you should definitely be able to use the attribute "Ticket Group (Historic)". As mentioned here, the historic attribute shows the value at the start of an update, not the end.
So if your tickets are moved from say Group 1 to Group 2. Then back to Group 1. Group 2 should be one of the attribute values on that ticket under the "Ticket Group (Historic)".
Therefore if you were to slice your Satisfaction metric results by the "Ticket Group (Historic)" attribute, you should in theory be seeing the satisfaction results compared and broken down by the groups which the tickets were assigned from one group to another at some point in the tickets history.
Would you be able to confirm if in your report you are slicing your metric results by this attribute?
Another alternative method to reporting on this data I can recommend is to build some custom metrics to report on the ticket satisfaction based on movement between your respective groups. This recipe here should help further if you want to explore this option.
If so and you're still not receiving the results as expected please let us know so that we can take this one offline here and dig a little further into this for you!
Hello Nhia!
Thanks for the reply.
I am slicing the report by Ticket Group (Historic).
Currently I'm trying this as simple as possible by:
What: % Satisfaction Score
How: Ticket Group (Historic)
Filter: Ticket Group (Historic) is Group1, Group2 and Group3 (actual group names are Integration, Konvertering and Techsupport)
Here I get the results that satisfaction is 80% for G1, 75% for G2 and 30% for G3 which I suppose could be true even if 30% seems very low.
(No filter applied regarding time period at this time)
When I try to slice this into actual ticket id's however (in order to see what the rating is actually based on in data) I get more or less no results, perhaps around 80 NKI ratings total for all of the groups since 2013. Seeing as we have around 20-25% answer rate on our Satisfaction-ratings and just one of these groups (Group 3) sends back around 200 tickets per week back to the base-support-group this seems extremely low and makes we wonder if this is correct?
Another question regarding this is if I want to split this into weeks what metric should I be using, Week (mon-sun) (Event)? Or which metric would be best?
Thanks in advance!
Hey Daniel,
Thanks very much for sharing that additional information.
I'd like to help take a closer look into the report data so let me create a ticket for you so that I may help dive further into this for you.
Additional if you're wanting to slice your metric results within a report by a week period I would normally recommend "Week (Mon-Sun)/Year (Ticket Solved)". This will compare the satisfaction results based on the week of the year that the ticket was solved. Alternatively you could also use "Week (Mon-Sun)/Year (Ticket Created)" but it just really depends on how you wish to slice and compare the data.
Hello again!
Sorry to bother again, however I'm trying to create a report that specifies the number Solved and #Replies per agent and date. I.e. the number of solved tickets and public agent comments for each specific day in an interval.
I was trying to do this by:
What:
# Tickets Solved
# Replies
How:
Day of Week (mon-sun) (Assignee Updated)
Ticket Assignee
Filter:
Week (Mon-Sun)/Year (Assignee Updated) is last week
Ticket Assignee is Person 1, Person 2, and 4 more
Day of Week (Mon-Sun) (Assignee Updated) is Mon, Tue, Wed, Thu, Fri
I'm not sure if I can even get the right slice while measuring both solved and number of public comments but what I can't seem to accomplish even by measuring only # Replies is the actual number of public comments by a specific agent a specific date.
If I measure # Replies based on i.e. Ticket solved the last ticket assignee on the "measure-date" gets all the replies on the ticket, from all the agents. So let's say "person 1" makes one public comment on a ticket and then solves it but three other agents have made five comments each person 1 still gets all of these under his or hers # Replies. In this case that would show up as # Replies for person 1: 16 (5x3+1).
I want to measure only the public comments made by the ticket assignee of my choice per the date of my choice. In the same example as above it should show 1 instead of 16 since person 1 only made one comment.
Any idea how to solve this and if it even can be combined with # Tickets solved in the same report?
Hi Daniel,
In this situation the "Ticket Assignee" attribute isn't going to be suitable for what you're needing as this attribute will always only contain the value of the current agent assigned to the ticket. It doesn't record and store the value of the agents/admins who performed the update on the ticket on the event.
You can approach this in two ways. The first is that you would need to break this into seperate reports. One to report on the tickets solved by ticket assignee. And the second is to report on the public comments by updater.
For this second report you would want to use the metric "# Public Comments". And the attributes you'd want to use are "Updater" and "Week (Mon-Sun)/Year (Event)". You can then filter your report results to just "Updater Role" is "Agent" and "Admin".
However if you'd like to combine both within the same report it won't be possible to use the default "# Tickets Solved" metric and may require creating a custom metric. This helpful recipe HERE should offer a good starting point. You'll need to modify the metric formula so that it looks for the ticket solve event. This should be represented by the following:
This metric you should then be able to use in the same report as the one above reporting on the comments by updater name. The metric should then return the number of tickets that were solved based on the updater who solved the ticket.
Hopefully this helps you further on this one!
Perfect, just what I was looking for - couldn't manage to get # Replies to go along with Updater but that explains it. Thanks again Nhia!
Hi There,
I am wondering if it's possible to have a report that displays, for example, the 25 tickets in the past 30 days, with a status of either solved or closed that had the longest resolution time and that had highest first reply time?
Thanks!
Hey T Lathouwers!

I'm not exactly sure how you want to present this report when it should be based on both longest res. time and highest first reply time but maybe something like this could help?
("WHAT" you measure could of course be changed to something else, if you want it to be based on full resolution time or First reply time based on Biz hrs instead.)
WHAT:
First Reply Time (hrs) [Avg]
Resolution Time
HOW:
Ticket Id
Filter:
Date (Ticket Solved) is from 30 days ago to today
Top 25 Ticket Id by First Reply Time (hrs) [Avg]
Top 25 Ticket Id by Resolution Time
Ticket Status is Solved, Closed
Hi Daniel,
Please sign in to leave a comment.