PostHog
Can we run support/triaging per team?
Problem: Question volume is gradually increasing and occasionally require extensive context. There's a pretty apparent split between product+deployment type questions.
Proposal steps:
- Update support flow to push relevant tickets to the small team that has context
- Zendesk + github + community slack + squeak will be tag based (one tag per small team/feature) and the tags will trigger a notification in a team based support channel
- Rotations are within teams. The person per team on rotation should either choose to squash the bug if possible or wrap it into the planning that will be coming up for the team. They just need to make sure to respond to the user as to what to expect.
- This person should still be able to participate in sprint work depending on how low/high the incoming request count is
- Note: This is purposeful as it incentivizes the team to build with quality in mind so their own support shifts are much lighter :)
- Customer Success folks can do the tagging that lands the tickets in the right place. Or we could keep a designated overall support rotation too (one of the people who are on rotation within a team)
Why?
- Faster time to resolution because the right team can handle it/answer the question
- Better visibility on patterns of issues that are occurring
- Doubles down on small team/self run team
- Better load balancing so people who are currently in sprints wanting to build stuff don’t get interrupted by constant pinging
- Make sure support scales as the team/product grow
- Encourage ownership between team and users who are struggling with problems related to the feature. Right now support shift feels more like a necessary evil rather than a productive experience
Note:
- Teams will need to be slightly larger than they are now (which we're working on anyway)
- Issue over PR before I go ahead adding all the channels and updating the format since it impacts all teams
- Zendesk + github + community slack + squeak will be tag based (one tag per small team/feature) and the tags will trigger a notification in a team based support channel
Re-raising the idea of finishing the Slack support bot (which @benjackwhite was kind enough to spend some time on previously, with some help from community).
Originally the Support Bot would do two important functions to improve the support experience:
- Set appropriate expectations for users, so they know (for example) how we prioritize and what timezone a support hero is in.
- Automate basic information gathering. Wouldn't it be nice if you no longer had to ask if someone is self-hosting, what version they're running, etc? This would speed up some exchanges.
But with this proposal, it may be possible to automate some of the tagging too?
Strongly in favour as this makes small teams closer to startups (who do their own support for good reasons as per above - feel the user response to what you ship) AND this will bump quality. We'll be quicker to solve stuff too as it will just go to the right place.
I'd want to avoid CS doing this though - maybe we should get users to self tag somehow? Or one engineer covers the company as you suggest
I like this idea a lot - means customers will get support from people closer to the problem they are having and an overall better experience for customer and PostHog team alike.
Re self-tagging: Zendesk does allow for the submission of tickets via a form, or via in-app chat (similar to Intercom) which has routing capabilities. It does change our workflow a bit but might give a better experience long term.
We already have a secondary support rota for each team. I've noticed we don't use it (or talk about it in planning) much. So the rota already exists.
it incentivizes the team to build with quality in mind
Strong +1 to things that improve this. And a good way to check in if this is working.
+1 to all the ideas around small teams and focus etc.
Devils advocate thoughts:
- For very small teams (e.g. session recordings) this means half the team is constantly having to watch support which is likely to be overwhelming.
- Only focusing on my team is great but could force me into a silo. When I was support hero last I learned so much about other areas of the product which positively impact my decision making in my area.
I would vote for keeping a company wide support hero but making that hero a pure triage role, focused on tagging the right team, assigning tickets etc. That way you still get a bit of an insight into the overall customer journey but are able to immediately offload to the team with the relevant feedback / focus.
The side-goal of a support hero could then be to improve the tooling (bot work was coming along if I'd simply dedicated more time to it) to automate the tedious part of their job.
I'm in favor of support requests being directed to those best positioned to solve them. We do sort of advertise this, after all (talk to the engineers that built the product). A couple thoughts.
They just need to make sure to respond to the user as to what to expect. It's fine to tag CS if you need some quick outreach/expectation setting/this is a blocker for commercial convo (or just to keep us in the loop). But generally this is a better approach from the perspective of delivering support than: Customer Success folks can do the tagging that lands the tickets in the right place. Or we could keep a designated overall support rotation too (one of the people who are on rotation within a team)
Some combination of a bot for #community-support and a dedicated support hero (whose role would be to get a high-level perspective on what issues users are facing / triage, as @benjackwhite says above, and to work on tooling) could work. The bot would have to cover a lot of surface area across workspaces/connect channels etc.
I am somewhat concerned that the volume of deployment-related support requests could really stop team-infra dead in their tracks if they handled every one of these going forward. Product teams can easily say "great we'll look into this, thanks for submitting", but deployment-related issues are usually total blockers and take a lot of back and forth to figure out. I'm still for tagging these so we can get a better sense of what the downstream problem is (it may just be that we need to be more strict about supporting deployments for only commercial opportunities)
I am somewhat concerned that the volume of deployment-related support requests could really stop team-infra dead in their tracks if they handled every one of these going forward. Product teams can easily say "great we'll look into this, thanks for submitting", but deployment-related issues are usually total blockers and take a lot of back and forth to figure out.
Longer term we may need to think about having a dedicated customer-facing role for assisting with deployments.
Cool, some responses
- Don't want to shift burden too far over to customer success so we should prefer some solution such as the bot to collect more information and retain an overall support hero rotation who is primarily responsible for triage. This person also continues to get exposure on company wide issue trends
somewhat concerned that the volume of deployment-related support requests could really stop team-infra dead in their tracks if they handled every one of these going forward. Product teams can easily say "great we'll look into this, thanks for submitting, but deployment-related issues are usually total blockers and take a lot of back and forth to figure out. I'm still for tagging these so we can get a better sense of what the downstream problem is
Agreed on volume issue. Though, depending on who's doing support that week, someone in infrastructure takes the hit with being the backup support anyway. This system should just acknowledge that this is happening first so it's clear secondary support hero on infra will probably expect some workload and/or we also draw the line on how well supported infrastructure requests are
Next steps:
- Will open the necessary feature/team specific channels and start moving tickets into them
- Update handbook regarding the split of responsibilities
+10000000 to this as it’s something I’m trying to push since forever. When you go to a hospital, the nurse doing the triage is not the same person also doing the heart surgery (that is also not the same person also doing an eye surgery operation, etc…). By having dedicated people working on scoped issues, we will raise the quality of our support and our product.
I’m looping @timgl as afaik, he has been historically against this proposal (apologies if I’ve misunderstood your position, Tim!)
Some follow up clarifications/discussion points:
Who's responsible for what now:
- Main support hero does triaging, answers quick questions, is the secondary support for their team also. This justifies being the dedicated support hero for the week still
- Anything beyond the surface questions, main support hero will communicate to the requester "Tagging in X to take a look", and the secondary support hero will take the ticket from there either being able to fix immediately or communicating when this will be addressed and how
Are all the bases covered?
- zendesk should wrap github issues, squeak, and emails
- user slack needs a solution. As @joethreepwood mentioned, the support bot seems like the best option here where the bot can field an initial question like "what feature is this related to" and we can automate that to be sent to the relevant support channel
Where do grabbag questions go?
- example: security vulnerabilities
I’m looping @timgl as afaik, he has been historically against this proposal (apologies if I’ve misunderstood your position, Tim!)
I'm still a little bit worried about the impact and distraction for the small teams. Team product analytics has 3 people in it right now, and depending on how many interruptions there are this might take away an entire person. Hence...
Main support hero does triaging, answers quick questions, is the secondary support for their team also. This justifies being the dedicated support hero for the week still
... i would make this a bit stronger. Support hero should still do a good chunk of the debugging, back and forth with customers to get to the root of the problem etc, rather than immediately pass things on to the secondary.
