Zendesk on Zendesk: How we triage

15 Comments

  • Nora Mullen
    Comment actions Permalink

    Hi everyone,

    This post is live and ready for discussion! Weigh in with your thoughts on the article, questions you have, or insights about how your organization handles triage.

    0
  • Kevin Rocci
    Comment actions Permalink

    This is a great post with lots of good tips. :D 

    I have a question, though: Can you talk about how you came up with the About section? How did you know what to add there? How often are you changing the categories and subcategories? How do you set that up?

    I guess that is more than one question. ;)

    Thanks!

    0
  • Erin Hampe
    Comment actions Permalink

    Hi Kevin,

    Excellent questions! We built the field as a way for us to help determine what kinds of questions our customers were writing in about; two of the most useful components for us being:

    1.) the ability to track trends in product questions 

    2.) the ability to quickly route tickets to specialized agents based on content

    And yes, it is absolutely a dynamic field! As we deprecate, update, and introduce features, we modify the About field’s categories and subcategories to reflect this.  Keeping it up to date (and communicating any updates to advocates) is essential to making sure it retains its value. We have a Support Operations team that does a fantastic job of maintaining our own instance, including this field, and we in Support are always able to request updates if we have any suggestions.

    Thanks again for the questions! :)

    1
  • Terry Thomas
    Comment actions Permalink

    How do you use Triggers with the ticket fields? Does About and Group feed into assigning the ticket?

    0
  • Erin Hampe
    Comment actions Permalink

    Hi Terry!

    The triggers that operate based off fields set in triage are generally for things like email notifications, adding CCs, and adjusting ticket tags to ensure tickets are properly handled in any future updates or escalations.  A few examples:

    • The About field selection  “Apps/Integrations” initiates a trigger that adds an integrations specialist as a CC on the ticket

    • Setting Priority to Urgent could trigger an email notification to select staff letting them know a ticket requires immediate attention

    The Group field we set in triage is the assignee on the ticket so while that certainly factors into the assignment, it doesn’t require the assistance of triggers.

    Hope that helps! 

    0
  • Kevin Rocci
    Comment actions Permalink

    @Erin

    Thanks! :D

    0
  • Samantha Flaherty
    Comment actions Permalink

    This is a great article - thanks for writing it up! I think the 'about' field is interesting and would certainly help apply structured tags to tickets and provide clearer reporting. 

    As for the triage groups - in your view, it doesn't show all the agents that are listed within the triage groups so looks like you would be more likely to assign to the group, instead of a person. Is that a customisation you're using?

    Also, your macros to assign a ticket to a triage group - is it just a simple macro to assign a group? Or what other things do you include (to what level of detail is useful)? I'd imagine these macros are quite loosely tied to the 'about' field? 

    Great stuff - thanks! 

    0
  • Chelsea Gaffney
    Comment actions Permalink

    Hey Samantha!

    Glad to hear that you like it! :)  

    Yeah you have it right, the view is intended for unassigned tickets that have not been touched. Anytime that someone will email, tweet, & etc to Zendesk will have their ticket appear in this view.  The view doesn't actually assign the tickets to the group, but rather provides a way to view these untouched tickets.  From there the agent will use macros to assign to the appropriate group.

    The macros won't assign tickets to the triage group, rather they will assign them to different groups from triage.  The macros we use will typically have a name as Assign to Tier 1 and from there the macro will add a tag (for reporting reasons) and have a rule to assign to the Tier 1 Support Group.  Other than that we will manually assign priority and the about field.  The goal is to keep your Triage queue at Zero.  :)

    Hope this helps!  

     

     

     

    0
  • Diane Albert
    Comment actions Permalink

    Love it!  Even with only 2 people in our support queue, I think it's time to do this so that all other internal folks know what to expect - and so that our dept has some written processes so that we CAN grow without huge growing pains.

    1) do you differentiate your reporting tags vs views, macros, etc?  i.e. RPT_ so that they can stay with the ticket and you know they will always be there for Insights?  I was working with an Insights report the other day and I know I'm probably missing data because we move our tickets through views using tags/macros.

    2) I see you have a type of 'schema' or naming convention set up to your macros - is there a particular way that you blueprint these (or your other triggers/automations) so they don't step on each other? (I would love to be able to reorder things in my macros so I can see from one to the next how similar they are...*feature hint*)

     

    Thanks, Diane

    0
  • Erin Hampe
    Comment actions Permalink

    Hi Diane,

    Great idea to start something early and let it evolve with you -- processes like triage are perfect for this since they're scalable and can be easily modified and adjusted as you grow. Over to your questions!

    1.) It depends. Some change based on various business rules or ticket fields while other tags are static and stick with the ticket through the full lifecycle. A quick example of each:

    • The About field applies a related tag (Email = about_email) and if that field value is changed later down the road, the associated tag will change as well (Email>CCs = about_email_ccs). 

    • Every macro we use adds a specific tag to the ticket (macro_1234567) so we can report on their usage. Since multiple macros can be applied over a ticket's life, we want to see any and all that were used -- so even if additional macros are applied in future updates, each unique macro tag remains.

    2.) Our taxonomy for macro titles is structured similarly to the About field: we keep the categories broad so the main menu is simple to navigate and get a little more specific with each subcategory. Filtering ( on Plus and above) or using Business Rules analysis (available on Enterprise) can also keep them organized!

    1
  • Samantha Flaherty
    Comment actions Permalink

    @Chelsea

    Thanks for your explanation - I realised I typed 'view' when I meant to put 'macros' - I hadn't realised you could tier macros the same as custom fields! (without knowing this, it looked like your macros were the actual assignee field drop-down with a bit of extra spice - I've since realised this is just your tiered macros) I've just updated some of ours to make them tidier - woohoo! 

     

    0
  • Andreas Larkfeldt
    Comment actions Permalink

    Thank you for a great and helpful article!

    I have a question regarding if you have some guidelines on when you should and shouldn't use Triage when it comes to number of tickets.

    I can see that you are receiving a great number of tickets, but when do you think this is becoming efficiant - is it when you recieve 10, 50, 100, 1000 tickets a day?

    0
  • Rodney Lewis
    Comment actions Permalink

    Hey Andreas,

    I hope you had a great weekend! This is a good question. It really depends on your workflow. If you like to track trends in real time the numbers do not matter. I would say if you receive 500 to 1000 tickets a day creating a triage team would be efficient. It’s also efficient if you have more than one team (i.e. Sales/support) That way it sends to the same group and everything is updated for the user.

    You can use a trigger to manually filter your tickets. We like to have our advocates keep an eye on the queue to help provide the best support possible and resolve issues in a timely manner.  I hope this is helpful!

     

    0
  • Crawford Philleo
    Comment actions Permalink

    Hey there,

    We've been building/customizing our own version of Triage, but one area I'm struggling with is coming back with a comprehensive way to report on the process and its effectiveness. How do you easily identify who triaged what ticket, and when? How do you identify how long it takes for a ticket to be triaged once it's created, then how long the response time is post-triaged?

    0
  • Jessie Schutz
    Comment actions Permalink

    Hey Crawford! These are all really interesting questions.

    I think there are a numerous ways to answer, so I think I want to try and narrow things down a little bit. What constitutes "effective" in your triage process? Is it the speed of tickets moving from triage to another group? Is it the accuracy of routing? Is it something else? The first step in figuring out how to report on something is to determine what success looks like. What does a successful triage process look like for you?

    0

Please sign in to leave a comment.

Powered by Zendesk