Zendesk on Zendesk: Escalating tickets to developers
Posted Nov 24, 2015
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 hosted by Joe Oliver, a Customer Advocate in our Madison office, and is about how Zendesk Support selects and prepares tickets for escalation. It covers:
See all of our Zendesk on Zendesk series discussions.
For the majority of tickets we receive, our Support team is able to address the customer's question or issue. However, if a ticket describes an issue where the product isn't working as expected, it might be necessary to send the ticket to the Development team to look into it.
Part 1: Preparing a ticket for escalation
Before advocates escalate a ticket, we first need to prepare the ticket for escalation.
Here is some essential information our advocates need to fill out before sending the ticket:
Ticket type and priority
When the Support team receives an issue that needs to be escalated to Development, advocates need to select the accurate ticket type to alert engineers. Zendesk only escalates either Problem or Incident tickets to developers. A ticket is a Problem or an Incident depending on whether it can be replicated or reproduced.
- If we can replicate something, then we can repeat the issue in a separate test environment. If an issue can be replicated, it's a Problem. When an issue can be replicated, the advocate creates a separate internal Problem ticket that goes to the Dev team and sets the original ticket to On-hold.
- If we can reproduce something, then we can only repeat the requester's steps in their environment and produce the same result. If an issue can be reproduced, it's an Incident. In this case, We escalate the customer's original ticket to development as an Incident with the advocate CC'd.
Sometimes, we know an issue is systemic, but cannot be replicated or reproduced. In these cases, advocates will create an internal proto-problem ticket with as much information as possible, and add more information when available.
We also need to make sure that the ticket has the right priority level. The majority of tickets sent to Development are considered Normal priority, unless the impact of the issue dictates otherwise. We set a ticket to Urgent if multiple accounts are unusable or are affected by the same error. Marking a ticket as Urgent alerts multiple members of the Support team.
Replication steps
The most important thing for our advocates to include in escalated tickets are replication steps. Replication steps consolidate the details of an issue into a single comment, preventing developers from having to read through the entire comment thread to understand what's going on.
Developers and advocates might read the same information in different ways. Advocates have a well-rounded understanding of the product and customer workflows. Developers, on the other hand, tend to specialize in the technical aspects of a specific product area. It's almost impossible to just look at code and work out the problem. The Dev team relies on the advocates' product knowledge to fully understand the problem in context.
As described above, replication steps are important to include when escalating tickets. Replication steps are divided into three parts: beginning, middle, and end.
Beginning
The beginning describes the problem or issue. Our goal is for the beginning to explain the issue so clearly that the developer doesn't even have to read the steps or expected outcome. To achieve this, advocates use as many specific details as possible. For example, instead of describing something as slow, we include the exact amount of time an action took to perform.
Below is an example of a well-written beginning:
Middle
The middle describes steps used to replicate or reproduce the issue. Before listing the steps, advocates indicate any options available. Options include whether or not developers have explicit permission to access the customer's account or any ticket/forum/widget/view that produced the issue. We find that the more mystery there is in a ticket, the less likely it is to be solved quickly.
In the middle, it is important to explain the steps exactly as you performed them. Developers don't interact with the interface as often as advocates, so their methods of performing an action might be different. If the steps are repeated in the exact same way, the issue can be solved faster. Screencasts/screenshots are not required, but they can be helpful when documenting particularly complex replication steps.
Below is an example of a well-written middle: 
End
The end describes the expected result that should happen if the system were performing properly. As mentioned before, advocates are in an ideal position to put an issue in context for developers and call out potential impacts on customer workflows. Advocates also always include browser information, even if the issue is not necessarily browser-related.
Here's an example of a good end:
Part 2: During escalation
Selecting groups
Zendesk contains many different Dev groups and adds more every month. With so many Dev groups, it is difficult for our advocates to select the correct one.
If the ticket is escalated to the wrong place, the issue will take a longer amount of time to be solved. To avoid this error, Zendesk has created a series of internal triggers, based on the 'About' field. Once an advocate escalates a ticket, the series of triggers and help from Sustaining will direct the ticket to the appropriate group. It is easiest for advocates to send their tickets to regular development.
Adding relevant tags
To make it easy to search for and review escalated tickets, we use tags and business rules. Escalated tickets from Tier 2 and Tier 3 are given the following tags:
- An individualized tag with the advocate's first initial and last name. For example, I would use the tag joliver.
- A tag that marks the ticket for follow-up by their own role or team. For example, Tier 2, formerly known as Advanced Support, uses the tag as_followup.
To add these tags to all escalated tickets, each advocate creates an individual trigger named Escalated Tickets from [Advocate Name]. Here's what this trigger looks like for one of our Tier 3 advocates:
-
Meet all of the following conditions: Current user is the advocate the trigger is for.
-
Meet any of the following conditions: Group is changed to any Dev group.
-
Perform these actions: Add the two tags described above
Now, escalated tickets can be tracked in views. On a team-wide level, we can see all tickets that have been escalated by creating a view of tickets with the tag as_followup. Advocates also create personal views of tickets with their individualized name tag so they can check on their own escalated tickets.
Communicating
While the Dev team works through escalated issues, the advocate keeps in touch with the requester. When a ticket is first escalated to Development, the advocate lets the requester know what we've found so far and why it's being escalated.
After this first update, it might still take an issue a while to make its way through the development queue, depending on the specific issue and how busy the team currently is. The advocate is responsible for keeping in touch with the requester and updating them on the current status of their issue. In general, we try not to make any promises or imply how soon something will be actively worked on or solved.
Part 3: After escalating the ticket
If our advocates haven't seen an update on one of their escalated tickets for awhile, we recommend they use the checklist below to make sure their escalated ticket has all of the necessary information.
Following up
Our rule of thumb at Zendesk is to check on escalated tickets once every two weeks. Our advocates set aside an hour on their calendars to check up on the escalated tickets in their view created with the tags mentioned above. A 'check-up' doesn't always mean asking for a status update, unless the customer is asking for a status update or if the issue is impeding their workflow in some way.
Checklist
- Double-check if the priority level and replication steps are still accurate and appropriate.
- Look for any additional material that could help make the ticket easier to solve.
- If it's been a long time, check to see if the issue is still occurring.
- If the issue was a one-off or investigation, make sure there is a clear action item listed for developers.
- Check to see if there is a JIRA issue attached to the ticket. If so, look to see if there's any progress or different relative priority. If not, update the Zendesk ticket to see if Dev needs additional information to move forward with the fix.
Questions?
We want to hear about your own escalation processes! Do you follow your own set of best practices? Prepare your tickets for escalation in a different way? Do you use triggers or add tags to your tickets during escalation? Let us know in the comments below!
0
10 comments
Sign in to leave a comment.