Zendesk on Zendesk: Escalating tickets to developers
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.
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.
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:
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:
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
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.
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.
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.
- 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.
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!
Hi Joseph. Always good to hear how things work internally at Zendesk.
We escalate between support teams in a similar way. Instead of tagging the tickets I add a private comment to the ticket via a target but I can see how tagging might be bether.
My macro for collecting information during the escalation is quite basic so I may modify it :)
Thank you for sharing with us!
Typically we use a combination of the two; escalation-wise, public note to the requester informing them of the escalation, and then an Internal note with the gritty details of replication and steps taken.
The tag association is two-fold, first is does give you the associated element in Insights on when that tag was associated and the escalation happens.
The second benefit is that it is a quick way for agents to consult their escalated requests.
I have a personal view to track all of the historical tickets that I have escalated based on the advance_ticket_joliver tag; in addition to CCIng myself on active requests, I now have a dedicated view for those tickets I have escalated.
The benefit of course is that this can all take place within a Macro, escalation note details and tag association.
Thank you for sharing Colin : )
Thanks for sharing this - it's great to see that our internal processes already mirror this kind of best practice!
I have one question for the community on this though: how do you handle developers as agents in Zendesk? Our processes mirror almost exactly that above. The developer has no direct contact with our customers, and simply helps the assigned agent with troubleshooting as needed.
The major problem we have is that we chose to set up our developers as Light Agents. It turns out that the huge restrictions on what Light Agents can do is preventing our developers from using the system properly. What we want is for a Dev to review the ticket, add internal comments, and pass it back to the agent working on the ticket. As light agents cannot change ticket properties, they can't do this which means agents are having to remember to regularly review the tickets we put with development.
We had thought about adding a trigger so that Dev's could "un-tick" a box and the trigger would re-assign it back to a triage queue, but from a workload perspective that doesn't change much from having someone review their tickets each day.
Does anybody have any thoughts and experiences they can share on this?
I created a custom field with the names of the people in one of my teams and this field is used to "assign" the ticket when escalated. They can create views based upon this custom field and I clear the field when it is passed back.
Thank you for reaching out!
Now, in terms of including these Devs/Light agents have you thought about handling it through adding them as CCs onto the request?
The idea here is that handling agent would CC one or more of these Light agents and then Internal note to them asking for assistance.
The Light agents can then note the ticket with their suggestions while it remains assigned to your handling agent.
Thank you for providing that Custom field use.
This can certainly help to facilitate escalation/assignment to available team members as well as helping to track ticket escalations based on the Field and your views.
How about integration with On Prem TFS?
We actually have a fairly active thread on this in our [Product Feedback Forum](https://support.zendesk.com/hc/communities/public/topics/200132066-Community-Zendesk-product-feedback):
As you'll see from Maxime's post from this past August, we're not currently planning an integrate with Microsoft TFS, but I encourage you to add your vote and use case to the thread!
Hope that helps!
We tested the Play View feature with our first level support agents some time ago because of the cherry picking issue. One problem we have faced was that some agents started to press "play" and read the ticket contents. If they weren't feeling like solving the issue, they just closed this ticket's tab and waited for half a minute. When reentering the play view, another person will be on the "skipped" ticket.
We are currently thinking about bringing the play view up again, but we would like to have a way to check if and who of our agents make use of this loop hole. Is there any way find this is out? Or is anything planned in this regard? :)
I can't see that TFS post (Not authorized apparently).
Is there any update?
Hi Ross -
Sorry about that. That thread was archived as we determined that it's not something we have plans to build.
Vous devez vous connecter pour laisser un commentaire.