Zendesk on Zendesk: Using a Play button-centered workflow
Zendesk on Zendesk is a discussion about a specific topic and how Zendesk Support uses Zendesk. Each topic is written by a member of our Zendesk Customer Support team.
This session is about how our Support agents use the Play button to work through tickets. It covers our goals for using Play, how we piloted and rolled out the Play mode workflow, and the changes in ticket metrics we saw as a result.
- Rolling out the Play button workflow
- What we've learned
See all of our Zendesk on Zendesk series discussions.
On the Customer Support team, our primary responsibility is to solve customers' requests by working on tickets. With a high number of tickets to deal with, and as we grow globally, it's increasingly important to optimize and define our ticket workflow. To that end, we've implemented a Play button-centered workflow for our teams.
If you're not familiar with Play mode, it's a way for agents to work through the available tickets in a view automatically. In Play mode, agents press the Play button to open the first ticket in the view.
After submitting the ticket with their updates, the next ticket in the view automatically opens.
Here's why we decided to use it:
- Efficiency: Using the Play button allows agents to spend their mental energy on solving tickets rather than combing through the queue. It also saves time by automatically skipping tickets that others are already viewing.
- Workflow definition and priority control: Using Play ensures tickets are addressed in order according to the view. We assign tickets a priority level during triage, and this makes sure we use that field appropriately and consistently.
- Broader agent experience: Agents have the opportunity to grow their skills in product areas they would usually bypass, giving them better overall product knowledge and understanding.
Rolling out the Play button workflow
We introduced the Play button to agents gradually to identify any issues early on. We knew this would be a significant workflow change to adjust to, and wanted to make sure we could dedicate time and attention to advocate happiness and performance.
Deciding which teams should use it
When we implemented the Play button, our Customer Support team was split into three tiers to address the varying level of technical expertise and time needed to solve incoming tickets.
- Tier 1 takes incoming phone calls and resolves email requests about our product and its features; these are typically questions that can be resolved in less than 15 minutes.
- Tier 2 spends more time digging into issues and the related logs and handles requests that typically can be resolved in less than an hour.
- Tier 3 addresses the most complex or time-consuming tickets before sending qualified issues on to our Development team.
Higher tier ticket queues have relatively few tickets and a lower ticket-to-agent ratio. With shorter queues, it's not as time consuming or chaotic for advocates to scroll through and open individual tickets.
Additionally, higher tier agents specialize in specific product areas, so it makes more sense for them to pick and choose their tickets.
Tier 1 has a high volume of tickets that don't require intensely specialized knowledge to solve.
As a result, we decided to try it out initially with only Tier 1 and Tier 2 agents.
Piloting and gathering feedback
A pre-selected pilot group tried out the Play button for 30 days. Managers of pilot group agents also set up regular meetings with them to gather feedback and review their ticket stats (see Agent feedback below). Each day, we sent surveys to the pilot group to gather their feedback. The surveys asked about the overall experience, how much their workflow felt disrupted, and general comments on what they thought. We tracked this feedback, in addition to other key metrics, in a dashboard.
What we've learned
We tracked agent feedback and ticket metrics throughout our initial Play button pilot.
We had a relatively small pilot group and tested over the holidays, a time when ticket volume is also low, so the statistical significance of the results is somewhat limited. However, we did notice a few interesting patterns.
Before the Play button workflow was rolled out, there was a tendency for CSAT to fluctuate based on the day of the week. With the majority of tickets submitted Monday to Friday, the smaller groups of agents working on tickets during the weekend would often end up with the trickier tickets passed over during the week. As a result, CSAT might dip on the weekend and be higher during the week. After implementing the Play button, this stabilized and became more consistent across the entire week.
Another trend we saw was changes in escalation percentage. This metric refers to the number of tickets that are sent to a higher support tier. For Tier 1, there was an initial increase in escalated tickets for the first two weeks of the pilot. This can probably be attributed to the fact that the first couple weeks involved clearing out previously passed over, difficult tickets. It could also be related to the agents using Play being exposed to tickets in areas they hadn't previously worked on. After the first weeks, Tier 1 escalation percentage returned to about the same as pre-pilot.
For Tier 2, escalation percentage seemed to increase overall. Our best hypothesis for this is that the tickets being skipped were consistently the ones that would take over thirty minutes, or would need even more of a technical deep dive, making them appropriate for Tier 3.
The numbers we collected on agent satisfaction were overall positive.
Workflow disruption was rated as minimal with the exception of a few outliers. Interestingly, the highest disruption was reported on days ticket queues were the lowest. One possible reason for this is that, as previously mentioned, the Play button is the most appropriate for higher amounts of tickets that don't require a specialized subject matter expert.
There was an initial trend of somewhat negative advocate experience ratings for the first two or three days of the pilot. However, once agents became more accustomed to the new workflow, the ratings turned around to be much more positive.
Agent comments included both positive and negative feedback, but was overall encouraging. Many mentioned how they appreciated the experience of "working on tickets they wouldn't normally necessarily pick out" and "mixing up the tickets they are involved in instead of just the tickets they already have solutions for", improving their overall product knowledge. As one agent put it, "I did take tickets outside of my comfort zone and the next time a customer asks me the same questions, I will have a quicker answer."
Another comment was that it made them more efficient by "taking the guess work out of choosing which tickets to work." One comment explained, "I get to the ticket faster because I don't have to look through the View to see which tickets are available."
We want to hear about your own experience with Play and agent ticket workflows. If you're using it, what impact have you seen on ticket stats and agent experience? If you're not using it, what factors have made you decide to stick to a pick-and-choose workflow? Let us know all about it in the comments below.
We've updated this article with some helpful visuals of the data we collected. Check it out above!
We do not currently use the "Play" button but might consider doing so... Some questions
1) This only looks at "unassigned" tickets -> if one agent has more open tickets than another, is this taken into account in any way
2) We have some different language skills in our team, everyone speaks English but some Spanish and others French... These need to be "cherry picked" how does this system take skills into account?
3) Lunch... If a team member stops for launch how do they stop the flow of tickets...
Hopefully this answers your questions:
1) The way our workflow was setup was that open tickets are handled when an agent first comes in for their shift and then periodically throughout the shift. Our Play Button usage was just for getting to those tickets that were unassigned. Later on, during our testing, we found that agents were using the Play Button on their own views that they had set up but it wasn't something we focused on.
2) We managed this by having multiple views. One view had all English tickets, one had Spanish, another French, etc. We have a triage process that quickly reviews a ticket and is able to assign it to a language view by setting a language field. Most of our agents worked out of the default English view. The language specific agents would use the Play Button in their language queue and, if that was empty and the moved to the default view, they would continue to use the Play Button there.
3) When an agent goes on lunch, they either closed their Zendesk instance or simply made sure all their ticket tabs were closed. This made sure that when they came back and started the Play Button process it would make sure to grab the refreshed view and also made sure that they weren't hovering on a ticket and thus preventing another agent from landing on the ticket through their use of the Play button.
Can you tell me how you get the escalation metric that is shown above?
Hi Amber! I don't know how we set up the custom metrics, but you can find the Zendesk on Zendesk where we outlined how we set up workflow here. That will get you the data points that you'd need; then hopefully one of the Insights experts here in the Community can help!
is there a way to disable "skip ticket" on Play Mode?
I'm trying to avoid my agents to skip tickets they don't want to answer.
Unfortunately, there is currently not a way to disable 'skip ticket' when agents are using Guided mode. There is also no indication of changes being made to this behavior on our timeline. The only alternative I can think of at that point is to analyze the skipped ticket data via a third-party application. There is an app within our marketplace that is aimed at being a dashboard for skipped ticket data named Skipper. Do note this app does have a monthly charge associated with it (and a 10 day free trial) and would require direct communication with the developer for support.
If disabling the button is necessary for your workflow, my recommendation would be to provide product feedback as it's the best way our customers' voices can be heard regarding product changes and feature requests. I apologize that I don't have an exact solution for your inquiry. Let us know if you have any other questions.
In regards of the usage of the Play Button I have a few questions:
1. Is it auditable?
2. How to check when Skip Ticket is used, the reason why was skipped?
Thanks in advance!
You won't be able to audit what tickets are selected while using the Play Button. You may want to look into the Guided Mode feature which will force the agents to only select tickets with the Play button.
You can view what and why the ticket was skipped directly from the agents profile as mentioned in the above article as well. There will be a Play only tab on the users profile where you can see this information.
Hope this helps!
I'll add a caveat to Brett's second answer. The Play only tab is only available to your Zendesk admins. You can access that data using an app like Skipper or by using the Ticket Skips API. I found in a past role that I needed managers to have this access, but I couldn't give them admin and ended up building an internal app for us that used the Ticket Skips API. If you don't have a developer to do that, Skipper is a very mature offering to help you stay informed on your skips.
We are using the play mode quite extensively. Usually an agent uses it from the Home dashboard. However, the play-button disappears from the Home dashboard once an agent clicks on "YOU" or "GROUPS" (so that all open tickets assigned to him/her or his/her groups are visible). Is this something that can be enabled?
Thanks in advance!
This is something that is not apart of the base platform, the best way to work around this would be to create a view that supplements the YOU and GROUPS section. I've included an article that breaks this process down in more detail.
I find that when agents use Play Mode, it does not go to the next unassigned ticket. Instead it goes to the next ticket? (Even if it is assigned to another agent)
Is there a way that the Play function on presents unassigned tickets? This is to avoid having multiple agents potentially updating the same tickets.
Unfortunately the Play Mode is always showing the next available ticket.
I think the best approach for you is to create a separate view with unassigned tickets and use Play Mode in that view.
I hope this helps a little bit...
I would like to re-activate @...'s comment. If you make use of different categories/specializations you are limited to the 12 max views. It would be very useful to be able to include/exclude within the play-button settings.
Currently we're using 'play' button function in Zendesk to automatically feed the next ticket in the Queue.
However, we are wondering if we use the Grouping feature to filter group based on value of a custom fields in a tickets (example: Assignee) and then ordering those tickets with another fields like Latest update or something. Can the 'Play' mode still be used to handle the ticket in the same queue?
Any information that you could share would be greatly appreciated.
Play Mode works with whatever grouping and sorting you have defined in a given View – it starts with the first ticket at the top of the View, and proceeds down the list. Does that answer your question? For more information, see Using Play mode
Thanks for the speedy response, Dave!
Yes, you have really helped me find an answer to my question and thank you for that resource.
Glad I could help, Kuldeep!
By clicking the play button, does it automatically assign to the agent all the tickets on the current view?
Hi Jules, and welcome to the community!
The play button will take the agent using it to the next ticket in the View that isn't being looked at by another agent, so it doesn't assign all the tickets in the View. For more information, see Using Play mode
Is it possible to set a rule that automatically assigns the tickets on the view to the agent who clicked the play button?
Clicking the Play button isn't an event that can be detected by triggers or other business rules in Zendesk, so there's not a way to do that. If you're looking for an automatic-assignment solution, you might want to take a look at the (paid) Routing app in our Apps Marketplace.
Hey there Zendesk team!
Are we allowed to use the "Play Button" to "skip" between groups ? like took tickets from other agents
The play button will help you go from ticket to ticket and not from group to group unfortunately. I'd recommend sharing this as feedback in our Feedback on Support topic for our product managers to review.
Thanks for taking the time to share this with us!
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.