Zendesk on Zendesk: How we triage
Zendesk on Zendesk is a day-long discussion about a specific topic and how Zendesk Support uses Zendesk. Each session is hosted by a member of our Support team.
This session is about how Zendesk Support triages tickets. It covers:
- Staffing and scheduling for ticket triage
- Consolidating user details
- Completing key ticket fields
- Perks of ticket triage
This session is hosted by Rodney Lewis, Erin Hampe, and Chelsea Gaffney in our San Francisco office.
Introduction
One of the first steps we take when a ticket comes in is making sure it's sent to the right person or team. Making sure this process, known as ticket triage, runs smoothly can keep response and resolution times down, prevent internal teams from wasting time sending tickets back and forth, and help you identify trends in incoming tickets. In this article, we'll look at the following elements of our triage process:
- Staffing and scheduling for triage
- Consolidating user details
- Completing key ticket fields
- Bonus perks of the triage process
Staffing and scheduling for triage
A designated triage agent is assigned to manage incoming tickets. This triage agent works out of the Untriaged Tickets view, which is set up as shown below:
The triage agent reviews and reassigns each ticket to the appropriate team for resolution. This triage agent is also in the best position to identify emerging support trends, assist the management of our problem/incident workflow, and assist during red alert events.
An agent on triage usually handles 30-50 tickets each hour. The majority of the time there will be one advocate assigned to this role an hour. However, in times where the amount of tickets become overwhelming for one advocate, we will have another trained agent help out.
We have a daily schedule which informs advocates of who will be on triage and when. Our support team makes sure that at least one advocate has eyes on triage at all times. Once a advocate is done with their triage shift, they will stay on until the next advocate is able to take over. Advocates handling this process must be well-rounded, well-versed in the product, and are able to multi-task and track trends in real time. We make sure that advocates are well trained and familiar with our system and team structures prior to stepping into this role.
There are two key components of triaging:
- User management
- Ticket review and escalation
Consolidating user details
One of the first steps when handling a ticket in triage is associating users with their correct organization(s). In our instance, organization is synonymous with subdomain, it’s generally something we can determine from the content of the ticket. We’ll head to the user’s profile and add the organization like below:
Not only does this help maintain our user base infrastructure, it allows Zendesk to retrieve any relevant organization information. There might be tags, notes, or custom fields on the org profile that should carry to that user’s ticket to provide additional information or influence triggers and automations. There could also be similar open tickets from other users in the organization that would help an advocate resolve the issue faster.
We’ll also merge alternate profiles into existing users when they’ve sent in a ticket from a new contact (a different email address, Twitter handle, Facebook page, or phone number). The system creates a profile page for each new unique contact, but we like to keep all contact information for one user stored in one profile. For example, when a voicemail is created, it’ll come through triage with the phone number stored as the only contact. If the customer happened to give us an email address in the voicemail, we can (try to) find their email profile in Zendesk and merge the two profiles together. The same process applies to social media tickets. By keeping all of the main contact information in one profile, we’re able to get a broader visual on the individual submitting the ticket.
Completing key ticket fields
Once we’ve listed an organization, we set field values and determine which Zendesk team should handle the ticket. There are four important fields we set in triage, as they determine the next steps in the ticket’s lifecycle:
- Type: Setting the type helps us to ensure tickets are accurately flagged when we transfer or escalate them, generate useful data for metrics, and isolate systemic problems so we can easily link incidents to them.
-
Priority: The priority helps stack the issues in order of severity. One of the most important parts of using this field is defining a priority taxonomy amongst your agents. Everyone should be on the same page as to what constitutes a low, normal, high, and urgent request or the value of the field drops significantly.
In our instance most tickets are set to Normal, with High reserved for issues that warrant more immediate attention (e.g. access, login, and channel issues). Urgent is used in only quite severe instances, which allows it to retain its power and transparency in communicating the true urgency of the request to the assignee. -
About: The About field is a custom drop-down field that we have created which allows the agent to know what type of request they will be assisting with (e.g. Triggers, Macros, Reporting, etc.). This is also useful in escalations or assigning to our product champions, so they know right away what the ticket is about.
-
Group: This is when we determine which team within Zendesk is best suited for assisting the ticket. Is this a question for Sales, Support, Documentation or Finance? Sometimes it’s deciding which subgroup it needs to be sent to -- can this be handled by our Tier 1 support group or does it require our technical resources in Tier 2? Is the request in English or do we need to route to the appropriate language-specific queue? With over 150 unique groups in our account, there’s a lot to consider!
To help with the escalation process we use macros that assign a ticket to the proper group and add the correct tags for reporting purposes. A macro can also be used to leave an internal note if you have some extra information to share that is beneficial for the agent or group handling the ticket.
The perks ;)
There are added bonuses of triaging! While it was built for the two management tools above, there are a few perks that come along with having this role.
- We have a number of requests that come over Facebook & Twitter. The advocate that is scheduled for triage will have the responsibility of handling these channels of communication. Since they are handled directly at triage, we’re able to get public replies out quickly.
- Advocates get to take on new roles and responsibilities - we have a past blog post that dives into this!
- Members in triage have the ability to solve “quick wins” at their discretion. This means a ticket comes to the triage view and can be solved with a quick answer within a minute or less.
- Triaging is a great way for your company to identify trends. For example, if an advocate sees multiple tickets being sent in about the same issue, he or she will be able to identify the problem area and create a problem ticket. When an advocate notices new tickets coming in reporting that same issue, he or she will notify the proper teams and link those new tickets to that problem ticket.
- Your triaging advocates will also see a larger scope of your company. Since advocates are responsible for sending tickets to the appropriate team, you will get to know more departments and are able to develop a relationship with coworkers outside of your team!
Summary/questions
Triage is a valuable resource that is a big part of our daily workflow. It is so important to us that we thought it may be useful for our customers as well. Now we want to hear from you! Does triage sound like a workflow that would be useful for you? Do you have a similar workflow to our triage duty? If you are not using the triage workflow, what are you doing now to sort your tickets?
-
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.
-
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!
-
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! :)
-
How do you use Triggers with the ticket fields? Does About and Group feed into assigning the ticket?
-
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!
-
@Erin
Thanks! :D
-
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!
-
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!
-
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
-
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!
-
@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!
-
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?
-
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!
La publicación no admite más comentarios.
13 Comentarios