chore: update support handbook with community and free support #14265
Conversation
Expanded the community and free plan support documentation to clarify processes and guidelines for handling community questions and free plan tickets.
Updated guidelines for community question handling and support notifications.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
abigailbramble
requested review from
HaynesPostHog,
clr182,
corywatilo,
darkopia,
eleftheriatrivyzaki,
kyleswank,
luke-belton,
ordehi and
slshults
clr182
left a comment
clr182
left a comment
There was a problem hiding this comment.
community 2-way sync section LGTM 👍
luke-belton
left a comment
luke-belton
left a comment
There was a problem hiding this comment.
sounds great - just had a few questions/thoughts
also one other related thing that crossed my mind is - do we do anything to identify community questions from paid customers (even if just sales top 20)?
| - If you're making assumptions or suggesting approaches, be clear about that | ||
|
|
||
| **When responding in Zendesk:** | ||
| - Write your response as a public reply |
There was a problem hiding this comment.
worth adding something like this?
| - Write your response as a public reply | |
| - Check whether the user has already raised a support ticket (this should be simple in Zendesk if they sign into the community using their PostHog user email) | |
| - Write your response as a public reply |
| **How to convert:** | ||
| 1. Reply on the community thread with something like: "This needs some account-specific investigation, so I've created a support ticket for you. Check your email - we'll follow up there." | ||
| 2. Create a new ticket in Zendesk on the customer's behalf | ||
| 3. Archive the community question (this hides it from the forum listing and removes it from search indexes) |
There was a problem hiding this comment.
I'm not totally convinced by this - I could see there being cases where there could still be learnings we could share publicly on resolution?
There was a problem hiding this comment.
or e.g. 'we ultimately identified there was a bug here, here's the link to GitHub'
|
|
||
| Free plan support is achieved via community questions. Free plan customers are entitled to community support and are not entitled to in-app support. | ||
|
|
||
| There are certain circumstances, however, where free plan tickets can exist within Zendesk via other means (such as through email or other channels). Free plan tickets are given the same target response time as community questions: **two weeks**. |
There was a problem hiding this comment.
should we be a bit more vague here and not say we have an email channel?
| - **Included in all support views in Zendesk** including: [Technical Support Shared View](https://posthoghelp.zendesk.com/agent/filters/32900756121627), [Billing & Accounts Support Shared View](https://posthoghelp.zendesk.com/agent/filters/38698822910875), and dedicated [Technical SME views](https://posthog.com/handbook/support/support-smes) | ||
|
|
||
| **Why two weeks?** This extended timeline serves two important purposes: | ||
| 1. It gives the community a chance to answer questions peer-to-peer before we jump in |
There was a problem hiding this comment.
if we are on top of our response time SLAs for 'paid' support, should we be running down the timers on community tickets to avoid answering too quickly and discouraging peer engagement?
| - We are building our community around our _website and content_, rather than the product itself. This is because a) PostHog is a product that you add after you have already built something, and b) 90% of community activity turns into support queries, which is not what we want community to be. | ||
|
|
||
| - We are focusing on building the community _platform_ itself - creating the tools that enable the community to interact with each other, rather than hiring a community manager whose job it is to go out and talk to everyone on other platforms/social media - this is not scalable. | ||
| - We are building our community around our _website and content_, rather than the product itself. This is because a) PostHog is a product that you add after you have already built something, and b) 90% of community activity turns into support queries, which is not what we want community to be. |
There was a problem hiding this comment.
PostHog is a product that you add after you have already built something
I don't think this is still valid - we want customers to add PostHog as early as possible so they get immediate feedback, even if their product is in early alpha/beta etc?
90% of community activity turns into support queries
maybe we just say 'the majority of'?
I know you've not added this wording, but it seems like the changes we're making aren't doing anything to address lack of engagement in the community - do we still feel the wording here best reflects our community approach?
I've added a handbook page that introduces how we'll be handling community support this year 🎉
I've also attempted to update our existing community pages to align with this.
Feel free to add comments, or let me know if there's anything I've missed or not thought about.
@clr182 I'd especially like you to look this over and consider if anything is missing or if anything needs adding from the two-way sync perspective 🙏