I Shadowed Support Heroes And Here's What I Learned #189
Comments
|
This is great!
I wonder if @MarconLP (or indeed Steven) should do a short support hero onboarding call with all new hires to go through the process? It can be a bit overwhelming to purely rely on the docs, even if they are fully up to date. (This could also be worthwhile for anyone currently on the team who wants extra help/a refresher to be fair) |
|
For my first week @benjackwhite did a couple of things that I think really helped:
|
I did something similar with @tiina303, which was really useful. I think we should focus on this kind of onboarding rather than a simple explanation call. |
|
Great. I'll add this to my todo for the handbook updates and we can start to include it in onboarding processes too. |
|
Regarding lots of tickets in on-hold state: in the pipeline team we had the same problem and decided that we're going to link users to GH issues (potentially creating them) and asking them to follow-up there & closing the issue. Discussed with Simon: high priority tickets should be assigned to CS instead of closing them. |
Over the last few days I’ve shadowed support heroes, including Marcus, to see how they use PostHog and collect their feedback about what we can do better. I wanted to get a hands-on experience to combine with the data side.
The short version
I’m going to add the following actions to my support issue for me to follow up on. Not tracking success or ticking them off here.
The long version
And here's the long version
Product Analytics: Julian
Product analytics seems to handle tickets the best, based on the data. So, I shadowed Julian to see how this team works and where friction is in the process.
Julian had little onboarding into the support hero process and, like most engineers, has little previous experience working on customer support or user-facing issues. There were several things he would have liked guidance on when starting out:
Julian was unsure, for example, if it’s better to solve a lot of tickets quickly or to spend time going deep on specific tickets. He only started looking at tickets based on their priority in the last few weeks and previously would look mainly at new tickets instead.
Julian finds tickets which come from Slack especially difficult to deal with. The Zendesk ticket appears with all of the thread on it, which often includes a lot of discussion with other staff members. The support hero has to read all of this context and, because it’s in a conversational style, often finds users raising multiple questions on a single thread, which means multiple issues on one ticket.
The way that product analytics works with tickets seems to work well. The team only has to look at tickets which are escalated by Marcus, meaning he triages and reduces work. The escalation macro could set better user explanations, but that’s a minor issue. Julian wonders if Marcus may be biasing results for the Prod Analytics ticket performance, however.
We also need additional macros to cover things like feature requests. Currently Julian has to leave Zendesk, create an issue for the request, and return to Zendesk to ask users to subscribe to the ticket. Some don’t do this, and we end up either requiring engineers to know what requests are open (hard for big teams) or make duplicate requests.
Julian didn’t find Kapa helpful at all, for reasons covered here.
A lot of the tickets Julian worked through had very minimal information on them — often a simple ‘this doesn’t work’ statement. He generally had enough information to investigate, albeit often requiring jumping into multiple tools, but further information from the user wouldn’t hurt. He impersonates users for basically every ticket and wasn’t sure what the guidelines were on updating/informing users, etc.
Customer Success: Marcus
Marcus is currently our only dedicated support engineer and triages tickets for other teams, so I shadowed him to see how our Zendesk specialist gets things done.
Marcus has three Zendesk views to tracking non-escalated and personally assigned tickets. He currently tracks product analytics, pipeline, and CS tickets only. His daily workflow involves first prioritizing the tickets he can solve quickly, then he goes by priority.
He has two main problems. The first is the high volume of tickets. The second is the quality of information on the tickets.
The volume of tickets is mainly caused by the low priority free tickets. We get far more of these than anything else. He thinks we can solve this by not offering support to low prio free users.
The main problem he has with Slack support is that these tickets don’t include the replay links and other info which we automatically grab from support modal tickets. This makes them harder to solve.
The low quality of tickets is something he has tried to solve before but the PR was rejected. He feels we need to gather more information up front in order to make solves faster. Our SLAs are only for first replies, but currently many of these may just be asking for more info.
Marcus logs in as users constantly. This is an essential tool for him and, even though he has his own test environments, not all issues can be found this way. If we were to make impersonation an opt-in step on tickets then it would need to be a firm requirement in his opinion - he can’t solve many tickets without it.
Marcus doesn’t think Kapa solves any issues, for the same reasons as Julian.
Feature Success: Juraj
Feature Success currently seems to be the ‘main’ (e.g. engineering, not 1-person) team with the slowest resolution at the moment, so I shadowed Juraj to see if there are improvements we can make.
Juraj actually has some prior experience in customer support roles from his time at Booking.com, during a busy period. His approach is to tackle Critical priority tickets first, and then escalate by priority.
One problem with this approach is that support queries for Surveys have been in limbo since Li left. Li was handling all Survey support on her own and, as a result, the rest of the team isn’t as familiar with that feature. Many Survey tickets just get marked as ‘On-hold’.
When dealing with any tickets which go ‘On Hold’ Juraj only updates the user if they are above Low severity. For Low severity tickets, he rarely gives the user a response. He’s unsure if this is correct.
The ticket volume in feature success is high, especially considering the size of the team. Li’s departure may be skewing some reporting too, as many new survey tickets flooded into the team and weren’t effectively dealt with. Juraj hopes that the upcoming plan to move the Cohorts feature to the Product Analytics team will help this.
Juraj thinks we should be asking users for more information when they file a ticket. 60% of tickets can be solved as they are, but 40% of tickets need more info. In particular, we often need to ask users what cohort/flag/etc they are referring to. We should add a dedicated field for this.
Like everyone else, Juraj impersonates users constantly. It’s an essential tool for solving tickets.
Juraj didn’t know about Kapa until I told him about it. I had to guide him on how to use it and he’ll try it out — we did a sample ticket and the results looked interesting, but were also slow.
Juraj wasn’t familiar with our SLAs, and hadn’t reviewed support hero documentation recently.
Whenever he gets a feature request ticket he creates an issue for it in GitHub himself.
The text was updated successfully, but these errors were encountered: