Explore Recipe: Creating an agent leaderboard for solved tickets

Return to top

14 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

    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
    Zendesk Documentation Team

    Hi Deo, 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:

    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
    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
    Hi Benny,

    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
    Zendesk Documentation Team

    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
    Community Moderator

    The query formula conditions could also include ...AND [Updater role] = "Agent", just to make sure we're excluding automated resolutions, for example.

    0
  • 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
    Community Moderator

    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:

    IF [Changes - Field name] = "status" 
    AND [Changes - Previous value] != "solved" 
    AND ([Changes - New value] = "solved" OR [Changes - New value] = "closed")
    AND [Updater role] != "End-user" AND [Updater role] != NULL
    THEN "Valid"
    ELSE "-"
    ENDIF

    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.

    0

Please sign in to leave a comment.

Powered by Zendesk