Fine Tuning: Analyzing the metrics that matter

Comments

22 comments

  • Avatar
    Roshni Sondhi

    Hi All!  Our first discussion topic is up!  As a reminder, this first discussion topic is around analyzing your ticket backlog and why this is an important report to review on a frequent basis.

  • Avatar
    Justin Graves

    I love hearing the ZD take on this stuff.  Very helpful.  Thanks for defining "backlog" as well.  I wasn't sure if the headline report for "Current backlog" included solved tickets since they can still be re-opened but now I know that it doesn't.

    Can you explain what the Insights "Historical backlog" report is indicating?  I would think it should show the # of unsolved tickets on the last day of a given month but since the numbers are way too high for that in my report I don't think that's the case.  Thanks in advance.

  • Avatar
    Roshni Sondhi

    Understanding your top contact drivers allows you to have full visibility into why customers are contacting your support team and to provide better service to your customers.  In this section, we'll discuss how to understand what the tickets are about.  Part 2 has just been posted.  Let me know how you review your contact drivers!

  • Avatar
    Graeme Carmichael

    I think that designing your 'about' field is one of the hardest things to do in a new Zendesk. Too many options distracts agents; making the choices clear and unambiguous takes care; agents are not always accurate and consistent in their selection and management can place too much weight on the data without first ensuring these issues are addressed. The help desk manager really needs to get a handle on the 'about' field using analytic tools.

  • Avatar
    Diane Albert

    Graeme - how do you help your agents define the "about" - do you do this through custom ticket fields with tagging, conditional fields, custom ticket forms???

    We have a custom ticket form internally for our incoming media files - things that people send us that we know have to go through an internal process to be loaded onto their online sites.  Depending upon how that media comes to us (electronic, physical), what it is (portraits, candids), and some other choice pieces, we have a macro for each of those selections.  That might seem like a lot of macros to choose from (it's around 10), but after about a day's worth of slogging through media, you know what you're looking at.  8000 tickets and 3 months later, you come to love those macros!

    Now I just need to get better...more "Insights-ful" - on how long the tickets are in certain statuses (we have views for issues or specific plant locations which are more important than actual ticket status), was there a customer faux pas that caused delay or was it our fault, and so on.

    I guess I need to start making my lists of what's important to me.  My teammate and I differ on how much to track.  He says I try to report on too much.  I guess I've been asked by upper management for enough things that I just happened to have thought ahead to capture.  :)

     

    I can't wait to see the "how satisfied are your customers" part.  Some of our Satisfaction comments are very odd, but telling.  "How come you didn't tell me about...." such n such?  And you know that information is in a printed document, an online document, and has been sent in an email by their account rep. 

    The Lead A Horse To Water syndrome is hard to solve - I never mind answering a question if it's asked.  It's frustrating to receive bad satisfaction when you not had the opportunity to answer before being thwacked and you think you've flooded the stable sufficiently.

    Diane

  • Avatar
    Colin Piper

    I changed the whole concept when I designed my helpdesk. I took away the free text subject line and replaced it with a dropdown of symptoms. This allows me to have the "about" without my agents having to always set it. Do customers always get it right? Most of the time they do as I analysed my tickets from our previous ticket system and came up with symptoms that made sense to our customers. Investing time upfront is important as you cannot go back and change your mind retrospectively on closed tickets.

    I am now finding also that I can further segment the "about" by the types of customers we service. The result differ based upon consumer/business and company size. I was not originally expecting that.

  • Avatar
    Graeme Carmichael

    Diane, we use a custom ticket field with nested options to tag each ticket. The field is mandatory before solving. I have no problem with having many options to provide a lot of detail, but that is hard to do well. As Colin says, if you get it wrong, you are lumbered with it.

  • Avatar
    Emily

    Hi Justin, 

    Even though the pre-built dashboards aren't customizable, you can still click the title of any report to see how it was built. When you click 'Historical Backlog,' then click the 'What' section, you'll see the basis of this report is the metric called 'Backlog Ticket Count.' Clicking on the words 'Backlog Ticket Count' will populate the MAQL recipe for how this metric was built in the column to the right. Here, we can see this 'Backlog Ticket Count' metric specifies this is the backlog as of the last day of the month. 

    Since you mentioned your report's numbers aren't adding up, I'm creating a ticket on your behalf where we can dive into your project and find out why. I'll see you in that ticket shortly!

  • Avatar
    Roshni Sondhi

    I've typically encouraged setting up an "About" field for customers to fill out, as well as one for agents to fill out.  I think the information becomes very telling based on the similarities versus gaps in what customers think they're emailing you about versus how the agent codes the ticket.  Colin,  I think it's really interesting that you segment the "Abouts" by customer size/business.  Have you seen similarities between verticals?  Have you been able to forecast business trends based on this?

    Graeme:  I would agree that setting up the "Abouts" requires some detailed thought, because you can either be too vague or get too detailed, and overwhelm the agents.  Do you currently have an "Abouts" field set up?  If not, how do you determine contact drivers?

    Diane:  I'm glad you're excited about the Satisfied post - only 40 minutes left!  I am a data fan like yourself, the more data points the better!  As you determine what to measure, it's really important to keep your business goals and strategies in mind.  If you can post what your goals/strategies are, I'd be happy to help brainstorm on metrics.

     

  • Avatar
    Colin Piper

    Roshni, I was actually surprised how different the results were between the verticals. So much so that I have now started to revisit the customer journey a little more to see how we can better meet the different needs of these segments.

  • Avatar
    Roshni Sondhi

    Colin:  That's really interesting.  Are you building the journeys that are vertical based?  Or are you looking to create a focus group with some of your different vertical customers who are pretty vocal?

  • Avatar
    Colin Piper

    Although I should do the job properly, at this stage I am simply adapting the support areas of the journey for each segment from an internal viewpoint. I am sure this will bring some improvements for our customers.

  • Avatar
    Roshni Sondhi

    We all want customers to be satisfied, so in this section we'll discuss what actions to take based on customer satisfaction feedback you receive.  We'll also share what actions you can take based on the data received from your customer satisfaction surveys.   Part 3 focused on customer satisfaction has just been posted.  

     

  • Avatar
    Roshni Sondhi

    Diane - The customer satisfaction portion has just been posted. Looking forward to your thoughts.

  • Avatar
    Colin Piper

    We have a company information session each month where I share who has achieved 100% customer satisfaction since the last meeting. I feel it is important that all areas of the business hear the results not just the teams with agents in them. We do have a rule that states that you must have more than 5 responses in order to qualify and i do have a treat for the first agent who achieves this 3 months in a row. 

  • Avatar
    Roshni Sondhi

    Colin:  That's great!  Here at Zendesk, we post CSAT ratings (positive and negative) on our internal Yammer feed for company visibility. 

  • Avatar
    Justin Graves

    @Colin - I'm super interested to know how you hid the subject field and replaced it with a drop down.  I thought ZD required it.  Have you created an article on this?

  • Avatar
    Jennifer Rowe

    Hey guys,

    I wanted to share this two part tip that our community moderator Andrea wrote about the metrics you should measure:

    https://support.zendesk.com/entries/42890613

     

  • Avatar
    Bianca Llamas

    Hi all,

    You can learn more about analytics and Insights in our Support Analytics Masterclass.

    You can register at https://university.zendesk.com/#/purchase and apply a 20% discount using this code: 0OtMoA3q

  • Avatar
    Dave Dyson

    I recently managed a revision to the "About" field we use in support.zendesk.com. It was a major undertaking, since the aim was to add more granularity to a field that was fairly complex already. 

    1. Consider your "customers" and their needs - who's going to be looking at this data, and what will they use it for? There's no use creating and using a field that's not going to be used. You'll want to talk to those stakeholders; in our case I spent time with our product experts in Support as well as the members of our Product team.
    2. What's the "mission statement" for the field? Do you want to capture what the issue is, or where the issue is happening? The complexity and rate of change of your product/service can inform this. If you have a fairly straightforward product with a limited number of frequent issues, then a simple field listing common symptoms (with an "other/misc" selection), accessible by your end-users when creating a ticket, may be good for you. In our case, we have a complex product worked on by independent engineering teams that evolves rapidly, so we want to capture where the issue is happening - our About field is only accessible by agents,  and lists areas of the product (in many cases with a layer or two of specificity so we can pinpoint areas that need concentrated attention).
    3. There are some details of the custom field implementation that you may want to pay attention to, especially if you're using a nested field with categories and item (like we do):
    • The ticket field in the Agent UI only shows the name of the actual item selected, and not any category information, so you'll want to make sure all your items have unique names. You wouldn't want to have "API" under two different categories, for example. The clearer your names are, the less training and documentation you'll need for your team (or customer) to know which choice to make.
    • Views will show the category (or nested categories) as well as the item name (e.g. "Product::Reporting::Insights"), but note that if you're sorting by a custom dropdown field, the sorting is alphabetical by Tag. This isn't a problem if you use the tags automatically generated by Zendesk, but if you're using your own (and especially as items evolve over time), this can cause problem if you don't have a consistent tagging strategy.
    • The fewer cooks, the better - if practical, limit the number of Admins so that desired changes can be vetted properly (to prevent redundancy, naming-convention issues etc.).

    • If you're doing a major revision and/or have a large number of options in your list, consider using the API to update the field instead of the Agent UI. This way you can make sure everything is correct before committing the change, and you can easily apply all the changes at once (and fix or revise as needed later on). Note that if you're revising an existing field, the API update call doesn't just make changes or add items - it completely replaces the old list with whatever you supply in the API call. It's a good idea to test in a temporary field (or sandbox account, if you have one available).

    Finally, once your field is in place, periodically review it, spot-checking tickets for accurate usage, making sure people are using it at all (if you haven't made the field Required), and circling back with your stakeholders to make sure it's still meeting their needs. 

    Hope this helps!

     

  • Avatar
    Dgood

    Hi - we've been using the "about" field - and now I'd like to see the breakdown. Where does it live?  I don't see anything in reporting.  Is seeing this only visible if you have Insights?  Thanks. 

  • Avatar
    Dave Dyson

    @Dgood: Your "about" field will appear as an Attribute in Insights. To see the breakdown, you'll need to create a new report in Insights that uses that Attribute - here's one recipe on how you could do that:

    https://support.zendesk.com/hc/en-us/articles/203664276-Insights-recipe-Reporting-on-what-your-tickets-are-about-by-channel

    Another way I like to look at "about" results is by looking at the most frequently-used values. In Insights, you'd do this by creating a new report and specifying:

    What: #Tickets

    How: About (or whatever your custom "about" field is called)

    Filters:

    * Ticket (Date Created) is last 90 days [or any time frame you'd like to see]

    * Add a Ranking filter and specify Top 15 About by #Tickets

    Select the bar chart format, then click Show Configuration and:

    * Under "Configuration", drag "Metric Values" to the X-Axis, and "About" to the Y-Axis, and click the Apply button there - this will switch the bars of the chart to being horizontal

    * Scroll down to "Chart Sorting" and select "largest first" (and click Apply) - this puts the most frequently-used About field selections at the top

    Then click Create, and you've got yourself a report!

     

Please sign in to leave a comment.

Powered by Zendesk