We aim to delight
You can build a good company by focusing on getting lots of customers. To build a great company, you must delight your existing customers. This means that the journey doesn't simply end once we sign up a user - even more important is to ensure that PostHog is consistently delivering value for them.
How we ensure amazing customer support at PostHog
It's easy for customers to reach us
We have a few different routes for users to contact us. As an open source company, our bias is towards increasing the bandwidth of communication with our users and making it easy for them to reach us through a clearly defined, simple set of channels.
These are the ways in which customers can currently reach us:
- Support ticket - Customers can create a support ticket directly within the PostHog app, under the help menu. This offers both users and PostHog engineers the best possible experience as Zendesk is automatically populated with a bunch of helpful context that makes troubleshooting easier. When in doubt, customers should be directed here.
- Community questions - users can also search previously answered questions that have been asked anywhere on posthog.com in our Docs. This is a great way to help us improve our Docs for simpler use-case type questions, but more complex questions should be re-routed via a support ticket.
- Dedicated Slack channels - For higher-paying (or potential higher-paying) customers, we offer a dedicated channel on our main company Slack.
Sometimes people reach out to us with support issues on Twitter/X. Regardless of whether someone reaches out to your personal account or to the company account the broad approach should be as follows:
- Check first if they already have a ticket in Zendesk (either in-app or via /questions). There is nothing more annoying for a user than being asked to create a support ticket if they already have. If you don't have Zendesk access, ask someone in CS.
- If no tickets exist, explain that we can't provide support over social media and ask them to create a support ticket within the app - this is much better than trying to solve their problem over Twitter as Zendesk pulls in a bunch of contextual information and is easier to collaborate in. Do this from the PostHog Twitter account - otherwise you will get personally contacted every time this user wants help.
- If yes, say that we can see their ticket and reassure them that all tickets are triaged and responded to. Let CS know that you have done this. Again, use the PostHog Twitter account.
Your objective should be to get the conversation into Zendesk ASAP, because it's easier to help the person there and to avoid setting a precedent that complaining visibly on social media results in an expedited response. An exception to this rule is if you are engaging with someone who has provided general feedback about PostHog - feel free to use your personal account if someone has a feature request or similar. If a user engage in a way which causes you any distress, you can skip all of the above and just highlight it in Slack for CS to deal with.
Sometimes users ask about the progress of certain issues that are important to them on GitHub. We don't consider GitHub to be a proper 'support' channel, but it is a useful place to gauge the popularity of feature requests or the prevalence of issues.
Response Targets
We have a high volume of tickets created, and some require more attention than others. Here we have our targets for initial response/acknowledgement to issues by Customer Priority and Issue Severity, along with an indication of who is responsible for the initial response (CS = Customer Success, SH = designated Support Hero for the impacted team)
| Customer Priority | ||||
|---|---|---|---|---|
| High | Medium | Low | ||
| Issue Severity | Critical | 1 hour (CS) | 1 hour (CS) | 1 day (CS) |
| High | 1 hour (CS) | 1 day (SH) | 1 day (SH) | |
| Medium | 1 day (SH) | 1 day (SH) | 2 days (SH) | |
| Low | 1 day (SH) | 2 days (SH) | Automated Response (See below) | |
Note for Low Priority/Low Severity tickets we should auto-respond letting customers know that they can ask questions in Community Questions
Support Engineers
We hire Support Engineers once a product reaches a significant level of scale and/or product-market fit. This is a subjective judgement. Right now, Marcus is our only support engineer, and he covers:
- Product Analytics
- Pipeline
He responds to as many queries as he can for these products, and escalates others to those teams as needed. For all other products, the engineers on those teams are directly responsible for support. The support runbook is maintained on the Support Hero page.
Engineers are Support Heroes
The direct interaction between our engineering team and our users is hugely valuable, and an important part of building trust in our community is the ability for users to talk directly with the people who are actually building the product.
Providing support across most products is a responsibility shared across our engineering teams - we expect everyone to jump in and help a user if you see they have a question or problem. Once you have made the initial contact or response, it is your responsibility to see it through or explicitly hand over to someone else if they are better-equipped to help.
One person on each product team takes on the Support Hero role each week. This is a rotating responsibility, where the person involved spends a significant chunk of their time responding to support queries across Slack, email and Zendesk, and sharing that feedback with the team and/or building features and fixes in response. We have found that each stint as Support Hero has thrown up a lot of really valuable feedback.
Community
Support =/= community - we consider them to be separate things. Learn more about how we think about community.
Tutorials
We want to help teams of all sizes learn how to ask the right product analytics questions to grow their product. To help, we create content in the form of tutorials, blog posts, and videos.
We've also created a bunch of useful templates that cover many of the most popular PostHog use cases.