Fine Tuning: How Zendesk uses Zendesk, Part 2

11 Commentaires

  • Colin Piper

    Although it seems obvious, I assume HR/Facilties use a separate instancw of Zendesk from that discussed in part 1. Is this completely separate or more of a spoke?
    Just trying to think through the logistics as I can see where adding non customer facing teams could be useful.

  • Lindsey Fischer

    Hi Colin,

    You are correct in your assumption. HR/Facilities use a separate instance of Zendesk from that discussed in Part 1. 

  • Paul Fennell

    Hello Miss Fischer, two questions....

    1) In your training example, your tickets from the feedback tab go straight to the training team.  Can you explain how this works?

    2) How do hashtags work?

  • Paul Fennell

    Nevermind, a quick search in the knowledge base and I'm good.

  • Lindsey Fischer

    Paul, I see you are the Admin for your Zendesk account. Any tips or tricks you'd like to share? 

  • Brent Curtis

    We are starting to build agent performance metrics as the team grows. I'd be interested to see how Zendesk measures their agents performance?

  • Ben

    Hi Brent,

    This is my favorite question! First, we examine global metrics for the week. Our goals require us to answer three fundamental questions:

    1. Are we solving as many tickets or more than were created in the same time frame?
    2. How fast did we reply to our customers while we were delivering those solutions?
    3. Ultimately, were our customers happy with the support experience?

    To start, we like to identify the total number of tickets created and the total number of tickets solved worldwide. This gives us a great overview of how we performed according to the demand.

    Then we look at our Median First Reply Time. Median is important as it mitigates against any exceptional experiences from throwing off a more representative majority. We compare this number to Median Customer Wait Time. This allows us to track both sister-metrics in a related fashion. They serve to corroborate each other or highlight a gap beyond the first reply.

    Following that, we identify our Customer Satisfaction (CSAT) rating for the same period. We could support all the volume in the world but it would not matter at all if our customers weren't satisfied. Right?

    Here is a sample of how that would look in a single snapshot:


    This let's us know how our global programming is impacting the customer experience at large. Once we have this contextual performance data for the whole group, we then break down the same metrics into regional teams to see how they each contributed. Finally, we review each individual on the team to celebrate their hero moments (positive CSAT rating with comments), highlight opportunities to improve (negative CSAT, slow reply time, low number of solved tickets), check in for feedback and all other standard review practices that a weekly data point furnishes.

    Of course, once you have standard metrics defined for your goal tracking, you can then use custom reports for areas of focus or to solve trending team performance issues. Let's say agents are holding on to tickets for too long and not escalating them efficiently. If you build a report that shows the number of solved tickets, average resolution time, and number of tickets escalated for each team member week over week, it will facilitate the conversations with those individuals who need to keep pace with the rest of the pack. The point is that once these larger reports highlight an issue, creating a more custom report to track how your team responds to that issue is the key compliment that leads to superior support.

    Hopefully this gives you a good glimpse into how we use performance metrics here at Zendesk.

  • Brent Curtis

    Hey Ben, 

    Wow, I wasn't expecting such a detailed response - that's awesome. Thanks for the insight, it helps build something more suited for what your design intentions are.

    I do run into one issue that the response doesn't really address. In our environment, its a little more fast paced than your average environment might be. Thus, sometimes a customer cant wait until the next day for a response and another agent has to pick up the ticket.

    To create an extreme example: What would Zendesk do if an agent was rude and angered a customer, and another agent did the good deed and helped out by taking the ticket. The 2nd agent gets penalized. 

    Whats a good way to handle ticket sharing or escalations?

    If the last example wasnt good: What if a tier 1 agent holds a ticket for 2 weeks, then escalates it to tier 2. The tier 2 agent would have their resolution time hurt by the tier 1 agent right?

  • Ben


    I know exactly where you are coming from with this question! Let me take a step back.

    The Zendesk ticket assignment strategy was built to promote accountability. This design has some ramifications on customer experience and agent experience. With regard to the customer experience, a single agent assigned to the ticket responsible for delivering a satisfying encounter is our primary use case. In fact, more than 75% of all tickets that come into our help desk are solved by the first agent who takes the ticket in Tier 1.

    The examples you cited absolutely happen to every support team. I think we can agree that these multi-agent scenarios, while universal to support teams, are still the minority of a healthy operation. If you disagree, we can certainly discuss it. It's important after all to check in on our processes in these terms. It's strange but sometimes those processes that may serve our support goals\reporting needs might not be the best customer experience. For us, it's a red flag if our operation requires more than one advocate to solve the majority of tickets. So having a help desk that caters to the majority and then complimenting that posture with workflows or reporting considerations for minority processes seems like the approach with the most advantage.

    That said, we still have the question of data integrity when tickets must change hands (which they certainly do!). To go with your example, if the first agent underperforms and leaves the customer dissatisfied, then the second agent inherits this satisfaction rating as well as a prolonged resolution time. Isn't this a penalty?

    In my mind, the answer is no. On my team, I have hired that Tier 2 advocate exactly for their ability to convert a negative encounter into a positive one (at both the soft skill level and the technical level). I'll admit that it's a weighted ticket. However, all tickets that come into Tier 2 are similarly weighted with regard to resolution time, by definition. One could argue that a Tier 1 agent could hold onto a ticket for an extreme period of time (2 weeks is too long for Tier 1 here at Zendesk). But then, that's so exceptional it wouldn't mitigate the averaging power of weekly performance statistics of the Tier 2 agent who picked up the ball and found a way to score despite the setup. Also, there are business processes outside of Zendesk as well as business rules within Zendesk that should serve as a failsafe to prevent that extreme time consumption in Tier 1:

    For example, you could have an agent in Tier 2 add a tag "inherited_csat" on tickets that arrive with a negative rating. Or you could add a tag "check_tier1" which would flag the ticket for review of the Tier 1 agent performance for improvement (such as holding on to a ticket for too long, going down the wrong technical path, etc).

    *Note: *Examining tickets with either of these tags can be a great source for trending problems and developing individual performance and organization wide workflow solutions. We use both. :)

    Finally, it may be a best practice to create an automation that alerts the Tier 1 manager anytime a ticket sits in a less-than-solved state there for more than is prudent (in your example, two weeks). I agree that the situation is unfortunate for the Tier 2 agent in that extreme scenario. And if they are feeling that pressure, imagine what the customer is feeling! I prefer a proactive approach that catches those Tier 1 exceptional tickets before they linger that long. Automations help us do that, well...automatically, so we don't have to go hunting to maintain an operation absent these exceptions.

    In fact, I know some Zendesk customers operate at such a fast pace that if a ticket stays in a less than solved state for 24 hours, it will be unassigned and sent back to the queue with high priority. This might be an efficient method for achieving speed of resolution but I would just remind anyone reading that agent accountability and the single-agent experience wherever possible is the method that yields the most customer satisfaction for our model.

    If resolution time for multi-agent tickets is a primary metric for your team (or you just need to know the numbers in a vacuum to define what amount of time makes them successful), then Insights is a perfect window into that data (Plus & Enterprise Plans). Take a look at the Agent Activity Report:

    • Agent activity focuses on performance metrics for an individual agent, including median time assigned to an agent and the agent's backlog trends over time.

    Some support teams live and die by handle time data and if Insights doesn't get you where you need to be then it's probably wise to investigate a  Time Tracking app. These apps are designed to give you better productivity reporting iteratively and may be the required functionality for you to define success for those other tiers and teams. And I totally get that approach too. Use the right tool for the job.

    Brent, this has been fun and engaging for me. I want to make sure this thread doesn't detract from the substance of the Spotlight. But I want to assure you we are working on presenting more content on How Zendesk Uses Zendesk as well as further Best Practice Spotlights that target exactly this subject matter. 

    If you would like to talk more in the mean time, say the word and I'll set up a call with you.

    Great questions!


  • Nathan Evans

    We have a single Zendesk instance.  We use this for both our support and tech services departments.  What factors do you consider when determining to create a new instance?  Can we use a single sign on for all instances?

  • Jillana Peterson

    Hi Nathan,

    That's a great question, and we hope this two part series shed some light on how to make that decision! The biggest factor to consider is likely security- is there sensitive information in the account that no other department should see? If so, you may require a separate instance to ensure data is kept confidential.

    If not, and you'd like both your Support and Tech Services departments to use the same Single Sign-on authentication script, you could place them into separate groups to share an account and configure SSO only once. Different departments can certainly coexist in a single Zendesk account with views, macros, and business rules set up to be global or restricted to a group or an individual. Read about our shared support instance here:

    Hope that helps, but of course, let us know if you have any other questions!


Cette publication n’accepte pas de commentaire.

Réalisé par Zendesk