Improve FRT: notify response crew channel when new tickets are created
Problem Statement
What is the problem?
Currently our First Reply Time (FRT) SLA achievement is not as good as we would like:
This was highlighted in the most recent Support key meeting.
Why is this a problem?
- The customer experience is not as good as we are aiming for.
- Our team don't have a clear way to make the metric better because we don't get notifications about new tickets. We have to manually look at the First Response Hawk view. New tickets are not visible in a timely way for the response crew. (Related issue comment)
Context
We recently introduced the Support Response Crew to help prevent ticket breaches.
The initial iteration of this is purely reactive - the crew focuses on 'soon to breach' tickets. This reduced our previous focus on 'First Response Hawk' (see discussion here).
We have heard from Support Engineers that this makes working in the crew feel 'hectic'. As @mhuseinbasic says here:
The fact that right now, we are providing very poor experience for both engineers and most likely customers as a lot of our work is reactive and not proactive (we're working starting from tickets that are on fire instead of those that are new).
We heard similar feedback in the EMEA team call.
When the response crew was designed, a second iteration was already in mind to switch the focus to be more proactive by responding to new tickets when they arrive (rather than leaving them until they are about to breach). The proposal on this issue is a planned evolution. It is part of a broader approach (including case management skills) to help us make our work feel calmer and less reactive.
Proposal
-
Create alerts in
#support_response-crew
when new tickets are created (this should be done using outgoing webhooks from Zendesk to Slack - it will exclude tickets without an SLA (free tickets) and tickets that get an autoresponder) -
Update the Response Crew process so that the crew knows to respond to these new tickets using the
👀 (I'm looking at it) and✅ (I've replied) emoji conventions - Strongly recommend assigning to self on first reply so that the ticket has an owner from the first reply (see FAQ below for nuance on this)
FAQ
1. Won't this make more work for the response crew?
No. The amount of work is the same. We're changing 'when' we get alerted about tickets. This way we hear about tickets at the time they're created instead of when they're about to breach. This gives us more time. We still have the same number of tickets to reply to.
2. Which is most important to do - First Replies or Next Replies?
Preventing First Reply breaches is the most important. This is the contractual part of our SLAs. NRT is 'aspirational' More context on this from Jason here. Balance your work in the crew between preventing breaches and replying to new tickets as they come in.
3. If I assign tickets I send first replies won't I end up with too many assigned tickets?
Since each person does the crew for one day a week, you'll pick up most of your tickets to work on during your crew day. If you find you have too many you can find another owner. Talk to your team mates and offer to swap tickets or find new owners. We encourage assigning to your manager if you have too many tickets and can't find someone to take ownership from you.
4. I've got a nice new ticket I want to reply to, but it'll take a few hours to investigate. What should I do?
If you see a new ticket and it's one you'd like to take on, but it'll require some time to get a full reply out to the customer, you should send the customer a reply letting them know that you've received their ticket, ask any clarifying questions and let them know when you plan to work on it and when they can expect a reply. You should then assign to self and put on-hold. If it's not an urgent ticket it might be that you'll work on it the next day. The customer has an opportunity to reply to you if this isn't soon enough for them.
4. Can I reply to new tickets when I'm not in the crew?
Absolutely! Any team member is welcome to pick up new tickets even when not on a crew day. For picking up new tickets, we do recommend the 'Needs Assignee' views in preference to the 'First Response Hawk' view or the alert in the response crew channel. We imagine you'll pick up most new tickets on your crew day, but not all. It's up to you do decide based on your case load.
5. What about the 'First Response Hawk' view?
We can still use this view. If the process outlined in this proposal is successful we imagine the need for the 'First Response Hawk' view will go away and it could be removed at a later date. We would then rely on new ticket alerts in Slack for timely first replies, and the 'Needs Assignee' views for locating new tickets to work on.
5. More questions? Please ask below!
Why replying to tickets as they arrive is a 'good thing'
Replying quickly to a ticket when it arrives improves the customer experience. Put yourself in the customer's shoes: You've just spent time writing in to get help. Your mind is currently focused on that. It's a graet feeling to hear back from a human soon after. Especially if we let them know what to expect from us and clarify any misunderstanding quickly.
There's a lot of research that shows a timely first reply improves customer satisfaction. e.g. see this from Zendesk
If you reply when the ticket comes in, there's a strong likelihood that you're in a similar timezone to the customer. This means that most of the time you'll be a good person to own the ticket (at least initially). If we leave the ticket for 4 to 8 hours before replying, the customer is probably in a different timezone.
Another benefit is that it helps us quickly see an influx of SaaS tickets that might indicate an incident. e.g. I was able to declare this incident based on seeing new tickets arrive in the #support_response-crew channel
DRI
@tatkins will act as the DRI for this issue.
Required Resources
If a decision is made to implement this:
-
@jcolyer and Support Ops will help with creating Zendesk alerts to the
#support_response-crew
Slack channel - @tatkins will update the handbook to clarify the process
Potential Roadblocks/Things to consider
- If this has the (unexpected) effect of disrupting how the response crew works we will need to adapt. It is easy to stop the new alerts and go back to what we have. After an initial four week experiment we will make a decision about whether to continue.
- Making sure all Support Engineers are aware of this iteration and know how to respond to new tickets in collaboration with the team. We will need to communicate multi modally.
- APAC currently don't have 'Response Crew' like there is in EMEA and AMER. We need to make sure this approach is usable by team members in APAC.
Desired Outcome
What does success look like?
- FRT SLA achievement improves
- Support engineers are happy with the iteration
- Side effect - more tickets have an assignee / owner from the first reply.
How do we measure success?
- Make sure FRT SLA achievement has improved
- Survey Support Engineers to make sure we're happy with the approach
Decision making by 2021-03-05
I've set an initial due date on this issue for Thursday 4th March. We should make a decision by then and implement from the 1st March. (Updating the process and implement alerts is straightforward. We can iterate on getting the message out when it's up and running. Nothing will break if people aren't fully aware.)
Four week experiment starting 2021-03-08
If this proposal is approved, we plan to begin the new system from 2020-03-08 (Monday).
After four weeks we will look at data and survey the team to decide whether to continue or not.
Global change
This needs to be a global change to be effective. Doing this in just one region would shift work and concentrate it in unbalanced ways as one region would be in a 'proactive' mode and another in 'reactive'.
What about APAC - we don't do Response Crew
APAC use the First Response Hawk rotation and view to reply to new tickets. We expect that process to be unchanged and you can safely ignore the Response Crew channel. If you're in First Response Hawk role in APAC and find the alerts for new tickets in the channel useful, then that's an added bonus, but no need to look at the channel if you're happy with your existing workflow.
Where would future feedback go?
On this issue until the four week experiment period is over.
Related Issues/MRs/Epics/Tickets
- AMER Crew: Explore auto-assigning tickets to active crew members
- AMER CREW: Improve guidance on prioritizing tickets (FRT vs NRT)
- Hypothesis - FRT Improvements
- Determine feasibility to implement a flavor of Support Response Crew in APAC