Use this Explore recipe to create a leaderboard that displays your agents and the number of tickets each one solved. This gives you a quick snapshot of your agents’ performance.
This article contains the following topics:
What you'll need
Skill level: Easy
Time required: 10 mins
- Zendesk Explore Professional or Enterprise
- Editor or Admin permissions (see Giving agents access to Explore)
- Ticket data in Zendesk Support
Creating the report
In this procedure, you'll create a simple report to display a table showing all of your agents and the number of tickets they've solved. If you have a lot of agents, consider using a top/bottom filter to restrict the report results to, for example, the top ten agents.
To create the report
- In Explore, click the reports (
) icon.
- In the Reports library, click New report.
- On the Select a dataset page, click Support > Support - Tickets dataset, then click Start report.
Tip: If your workflows involve changing the ticket assignee after a ticket has been solved, see Modifying the report below.
- In the Metrics panel, click Add.
- From the list of metrics, choose Tickets > Solved tickets, then click Apply.
- In the Rows panel, click Add.
- From the list of attributes, choose Assignee > Assignee name, then click Apply.
- In the Result manipulation (
) menu, click Sort, then click Apply.
- On the Sorts page, choose Value descending, then click Apply.
And you’re finished! See the screenshot below as an example of the finished leaderboard of your agents based on their ticket solves, in descending order
Enhancing the report
You can also filter on the date the ticket was solved to limit the results to tickets solved within a specific date range.
To add a date filter
- In the Filters panel, click Add.
- From the list of attributes, choose Time - Ticket solved > Ticket solved - Date, then click Apply.
- Click the Ticket created - Date attribute you just added, select Edit date ranges, and choose the date range (for example, Yesterday or Last week) you want to filter to.
Now, the result will only return tickets created within the date range you chose.
Modifying the report
If any of your organization's workflows involve changing the assignee of a ticket after it has been solved, you might want to consider a different approach than the one described above.
When you create the report as described above, it reflects the agent who is currently assigned to a ticket, even if that's not the same agent who marked the ticket as solved. Instead, you can modify the report to show which agent marked a ticket as solved, which is more likely to reflect the agent who actually did the work to solve the ticket.
To modify the report
- Use the Updates history dataset instead of the Tickets dataset.
- Use the metric D_Count(Tickets solved).
- Use a standard calculated attribute with the following formula:
IF ([Changes - Field name] = "status" AND [Changes - Previous value] != "solved" AND [Changes - New value] = "solved" AND [Update - Timestamp] = [Ticket solved - Timestamp])
THEN [Updater name]
ENDIF
18 comments
zach.prasser
Does this recipe take into account tickets Solved by the agent, only? Or does this include tickets that other agents solved for them, while the ticket was still assigned to the agent?
0
John Espina
Hi Zach,
To answer your question, as long as the ticket has been solved it will be counted as an attitude following this recipe. So it doesn't matter who solved that tickets either the Assignee or the other agents.
John Espina | Customer Advocate
0
Chris Bryant
I am trying to find a way to report on the tickets that the Agent marked as Solved only. When I look at solves this includes all tickets that were replied to in a Pending state and autoresolved. I don't want to see tickets that the customers didn't respond to and have those counting as "solves" for the purpose of my QA and reporting. Thanks!
0
Clifford James Lacson
Hello Chris,
Thanks for reaching out!
You may use One-touch Tickets as one-touch resolution calculation counts any solved or closed tickets with less than two agent replies.
However, if the customer reaches back saying ‘thank you’ for example, and the agent solves the ticket without making another reply, the ticket will still count as a one-touch resolution. If these would suffice with you, they can still be counted as one-touch tickets.
Kindly check this article as well to know more about it: How are one-touch resolutions calculated?
I hope this helps. Let us know if you need anything else. :)
Clifford James Lacson |Customer Advocate|
NEW - Zendesk offers free, on-demand training for all of our products. Set up your account and start learning today at training.zendesk.com
0
Elspeth Mogol
Hello Zendesk,
We are a retail company with customer service that handles both inbound calls and tickets (emails). The process I have with the team is if they received an inbound call with an existing SOLVED ticket, the first thing they have to do is that verify if the ticket was solved correctly (by another agent) ie. all of the customer's concerns were addressed and resolved. If yes, then, the current user will have to reopen the ticket and take ownership and action whatever the request or concern is. If not, the current user will have to reopen the ticket, add an internal note, and assign the ticket back to the previous assignee who did not properly solve the ticket.
Now, my question is:
If the current user took over the ticket assigned it to him/herself and thensolved it the second time, will it affect the previous assignee's Solved Ticket metric?
I'm asking this because I measure the team's productivity by the number of their solved tickets.
Hope to hear from you soon.
0
Clifford James Lacson
Hello Elspeth,
If a customer re-opens the ticket with an additional question and the agent responds and solves the ticket again, it will no longer count as a one-touch resolution.
You will have to use the Explore recipe: Reporting on created and solved tickets and customize it to remove the tickets that went pending until it got solved. Please note that you will have to work with your dev team as custom reports are out of our scope here in the Advocacy team.
I hope this helps. Let me know if you need anything else.
Clifford James Lacson |Customer Advocate|
NEW - Zendesk offers free, on-demand training for all of our products. Set up your account and start learning today at training.zendesk.com
0
Deo Labindalawa
Hello,
Can we get the agent name who first resolved the ticket? There are instances that the ticket was solved then transferred to other team.
Thanks!
0
Erin O'Callaghan
Hi Deo Labindalawa, great question! In that case, I think you'd want to create a report in the Ticket updates dataset instead, using the metric D_Count(Tickets solved) and the attributes Ticket ID and a standard calculated attribute with the following formula:
0
Benny Samuel
I feel like this article is not accurate, and that Erin O'Callaghan is leading us to more true numbers. The article says we should be using the "Tickets" dataset. Correct me if I'm wrong please, but that evaluates how many tickets are in solved status -and you can add parameters like assignee's name, in solved status Yesterday, etc. BUT... that doesn't necessarily mean the ticket was actually solved by the assignee during that period, just that there is a ticket in solved status to that assignee during that time period. The difference is that a ticket can be in solved status for any amount of days according to your configuration (I think default is 28 days, we have it set to 7 for our purposes). So if a ticket is in Solved status for 7 days, it will still show up for that agent. As opposed to doing the same query in the "Ticket Updates" dataset, which shows tickets that were updated by an assignee. So if the status change happened during the parameters set, it will show the ticket solved (and just for fun, Zendesk decided to term this metric as "Tickets Solved", as opposed to "Solved Tickets" in the main "Tickets" dataset - can be confusing).
I discovered this issue when we had been tracking the "Solved Tickets" metric in the main ("Tickets") dataset all this time, just like the article says, and we'd tally up how many tickets were "solved". But when we tallied all our agent's solves, it did not add up at all to the larger amount we had been publishing to our upper management. The "Tickets Solved" metric in "Tickets Updated" dataset is much more closer to the actual number of tickets the agent solved in that timeframe.
If what I'm saying is true, this article should be removed and revised.
0
Rafael
What you mentioned regarding the Ticket dataset is correct. It includes general ticket information, but it does not include the changes or updates that happened in the tickets. On the other hand, the Ticket Updates dataset is focused on these elements.
From my experience with Zendesk, the majority of times when the ticket was solved, it was kept to the agent's name who closed it, as it considered the final resolution of the ticket. It does not mean that it cannot be adapted differently for different organizations and workflows. The intention of this article was to simply show how many tickets were closed and had the agent's name attached to it. If the ticket is reassigned to someone else after it is solved, then, we can consider the Ticket Solved (Ticket Updates dataset) to reflect it.
Best Regards,
0
Erin O'Callaghan
Hi Benny Samuel and Rafael, thanks for this feedback! I've updated the recipe to add a new section called Modifying the report. The new section provides more detail on how to use the Updates history dataset (previously called Ticket updates) to report on the agent who actually marked the ticket as solved.
1
Pedro Rodrigues
The query formula conditions could also include ...AND [Updater role] = "Agent", just to make sure we're excluding automated resolutions, for example.
1
Benny Samuel
Pedro Rodrigues That's an excellent idea, but, just to confirm: will this rule still count solves that came by way of merges? If I as an agent merged 3 tickets into 1, do I get credit for 3 tickets going to solve status, or would these 3 solves be considered non-agent solves?
0
Pedro Rodrigues
Hi Benny Samuel, it depends on how we build our query. In this case, we need to include the status change to Closed in the formula.
Here's a complete example for a standard calculated attribute:
In other words: if the ticket status was changed from [any status but solved] to Solved or Closed, and the updater was not an end user, then validate.
Consequently, this will also work for tickets closed by merge.
1
Deepak Kumar
Hello everyone
What is the process for getting solved tickets to reopen them and what is the number of them?
1
Anne Ronalter
In our article Updating and solving tickets, you can find details on the process and default metrics for Reopens or Reopened tickets under the Tickets dataset.
Moreover, here you can find all Metrics and attributes for Zendesk Support.
Please also refer to this community post:
Number of reopened tickets per day
0
Leon Harris
Is there a way to edit solved tickets that had incorrect information entered?
0
Zsa Trias
Hello Leon,
You should still be able to edit ticket properties as the ticket is still in Solved status.
But if you're referring to the ticket comment, unfortunately, that can no longer be updated once it's already submitted. For reference: Can I edit a ticket comment once it has been added to a ticket?
0