Question
When creating reports, I noticed that there are multiple different metrics about tickets that are solved. What is the difference between Solved tickets and Tickets solved?
Answer
- Find the Solved tickets metric in the Tickets dataset. This metric tells you the number of tickets that are currently in a solved status in your account.
For example, by using the Solved tickets metric with the Assignee name attribute, you can see a snapshot of the number of tickets that are currently in a solved status organized by what agent those tickets are currently assigned to. But, as soon as one of those tickets switches back to pending or open, the ticket will no longer show in the report.- If you have tickets with custom ticket statuses within the Solved ticket status category, these tickets are also included in the Solved tickets metric.
- Find the Tickets solved metric in the Tickets dataset and the Updates history dataset. This metric tells you the number of tickets that changed from a different status to a solved status or a closed status at any point. This metric excludes tickets moving from a solved status to a closed status so as not to double count tickets.
In the updates history dataset, the data this metric shows is dependent on how you use it. For example, you can use it along with the Ticket group attribute to see how many tickets were moved to a solved or closed status by each of your agent groups regardless of what status those tickets are in now.
In the tickets dataset, the metrics each specify the timeframe themselves. For example, Tickets solved - last 7 days. To see a list of the tickets solved metrics in the tickets dataset, visit this anchor link and scroll up a bit: Ticket dataset.
Generally, when using a time axis, such as ticket solved date, you can use the Tickets dataset with the Solved tickets metric. This shows you the tickets that were solved on the given day. There is no need to switch over to the updates history dataset to try and get day-by-day information on what tickets were moved to a solved status.
If you want to see a snapshot of how many tickets were in a solved status on any given day, use the backlog dataset to do that. Learn more about that unique dataset here: Analyzing your ticket backlog history with Explore.
6 Comments
Hello Elissa,
Similar to Rodger's question, I am trying to find the best way to quantify the amount of work done by an agent during a given date range. I am using the tickets solved metric but in reading your article, I'm not sure it will give me the true number of ticket solved events.
For example, if a ticket is solved multiple times by multiple assignees, would the solved ticket metric only use the most current solved date? If a ticket is solved on Monday by Assignee A, reopened and solved again on Tuesday by Assignee B, reopened and solved again on Friday by Assignee C, would the solved ticket event only show on Friday by Assignee C? If I pull a report on Saturday, Is there a way to get all solved Ticket events for single/unique Ticket? Thanks!
Hi @..., if you use the 'Tickets solved' metric within the Ticket Updates dataset you should be able to see what you need. A ticket that's been updated to 'solved' on three separate occasions would show a 3 for that metric.
I am currently using the Tickets Solved metric in the Ticket Updates dataset and have come across a discrepancy that I don't quite understand.
I'm using the metric to create a day-by-day query to show Tickets Created vs Solved throughout the week.
As you can see, the two Solved values don't match.
(The Solved figure under today is using the Solved Tickets metric in the Tickets dataset).
I have narrowed it down to the following scenario:
If an agent creates a new ticket and sets the status directly to solved, it is not being counted in the Tickets Solved metric.
From what I can see, the only reason why it is not being included is because there is a 1 second difference between [Update - Timestamp] and [Ticket Solved - Timestamp]
How can I fix this to ensure there are no variances?
Hi Michael,
We've encountered similar cases before where the recorded timestamps of the update and for the last solved date differ by 1 or 2 seconds. You're right, this is the reason why these tickets are not being counted by the metric Tickets solved. A fix that we can recommend for this is to use a custom metric instead of the native Tickets solved metric. You can use this formula:
This formula should account for instances where there's a 1- or 2-second discrepancy between Update - Timestamp and Ticket solved - Timestamp.
This is a really helpful formula, @.... I just bumped into a few cases where the formula doesn't apply because both 'previous' and 'new' values are weirdly showing up as 'solved'.
Would you know why this happens? The previous value on that update should show 'open'.
Just for reference, I managed to obtain an exact match between the Tickets dataset (Solved tickets calculated based on Solved dates) and the Updates history dataset by using the following standard calculated metric:
With this I can now accurately see resolutions above 100%, which was the expected result.
Cheers!
Naming conventions in Zendesk Explore are not intuitive at all. Would a simpler solution to help users understand metrics be to make the name unique or more specific? Better descriptions are needed to make reporting leveraging Zendesk easier and more efficient. As an example Tickets Solved and Solved Tickets, it is not intuitive at all that these mean two different things even for native English speakers. Something like Current Status - Solved and Number of Times Solved, while maybe overly verbose provide more clarity. Confusion over the similarity in names and significant differences in results causes us to not trust Zendesk reporting.
Please sign in to leave a comment.