chore: update support handbook with community and free support

contents/handbook/community/index.mdx

@@ -8,26 +8,25 @@ We want to build a self-sustaining and scalable community of engaged users becau
 
 Our approach to building community at PostHog differs from most devtools in two ways:
 
--   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.
+- 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.
 
 ## Responsibility for community
 
 This is shared across multiple teams and people - we (deliberately) do not have one person responsible for 'community':
 
--   The <SmallTeam slug="brand" /> builds the platform and tools. Rather than using an off-the-shelf community platform, we have rolled our own. This gives us the flexibility to do what we want with it, all without having to depend on third parties or their cookies.
-
--   The <SmallTeam slug="content" /> doesn't 'run community' in the traditional sense, but is instead responsible for ensuring that the content hubs in particular have a steady stream of engaging content and replying to users when they engage. They also proactively respond to questions and use feedback to create new types of content such as tutorials and docs.
+- The <SmallTeam slug="brand" /> builds the platform and tools. Rather than using an off-the-shelf community platform, we have rolled our own. This gives us the flexibility to do what we want with it, all without having to depend on third parties or their cookies.
+- The <SmallTeam slug="content" /> doesn't 'run community' in the traditional sense, but is instead responsible for ensuring that the content hubs in particular have a steady stream of engaging content and replying to users when they engage. They also proactively respond to questions and use feedback to create new types of content such as tutorials and docs.
+- The <SmallTeam slug="support" /> answers community questions through Zendesk as part of their normal support workflow. Community questions are given a two-week response target to allow time for peer-to-peer help before the support team jumps in. See the [community and free plan support handbook page](/handbook/support/community-and-free-support) for details on how the support team handles community questions.
 
-> Support should not considered part of community at PostHog. [Support](/handbook/support/customer-support) is driven by the Customer Success team, primarily using in-app support and decdicated Slack channels. Good customer support helps build positive word of mouth, but replying to support queries is not an engaging or scalable way to build a thriving community.
+> Support should not be considered part of community at PostHog, although we do try to enable the community. The goal of community is to create a self-sustaining environment where users help each other, not to provide a free support channel. Good customer support helps build positive word of mouth, but the community platform is fundamentally about peer-to-peer engagement, not support ticket resolution.
 
 ## Content hubs
 
 We are in the process of building these out. We have created two hubs targeting our ICP:
 
--   [Product Engineers](/product-engineers)
--   [Technical Founders](/founders)
+- [Product Engineers](/product-engineers)
+- [Technical Founders](/founders)
 
 We have a bunch of features we are building here – more details to come!
 
@@ -37,7 +36,7 @@ Our community forums live at [posthog.com/questions](/questions) – but they co
 
 Anyone can ask a question within the forums, but they can _also_ ask a question at the end of any docs page (under the "Questions?" subheading). We've found this to be a great place for people to ask very specific questions after attempting to find an answer in documentation, as it acts as a mini-FAQ section.
 
-Questions that are asked within the docs are also automatically aggreagated to the correct category in the community forums.
+Questions that are asked within the docs are also automatically aggregated to the correct category in the community forums.
 
 ### Asking a question
 
@@ -49,4 +48,7 @@ Anyone can subscribe to thread replies by clicking the bell icon in a thread (af
 
 ### Answering questions
 
-If you're a PostHog team member, [read the guidelines for responding to community questions](/handbook/community/questions).
+Community questions are automatically created as tickets in Zendesk and routed to the support team. If you're a PostHog team member interested in answering community questions:
+
+- **Support team members and Support Heroes**: See the [community and free plan support handbook page](/handbook/support/community-and-free-support) for workflow details
+- **Other team members**: Read the [guidelines for responding to community questions](/handbook/community/questions) for tone and best practices

contents/handbook/community/questions.mdx

@@ -4,42 +4,44 @@ sidebar: Handbook
 showTitle: true
 ---
 
-The Website & Docs team can help in configuring Slack notifications for small teams to receive alerts to questions in a team channel – usually the one designated for support.
-
-Individually, you can also subscribe to topics of your choosing (with your PostHog.com account) by clicking the bell icon next to the topic's title. You'll receive a daily summary of new questions by email, and you'll find open threads for that topic in your personalized [community dashboard](/community/dashboard) (available when signed in).
+Community questions are automatically created as tickets in Zendesk and routed to the support team with a two-week response target. This gives the community time to help each other before the support team jumps in.
 
 ## Who should answer community questions?
 
-**We encourage all team members to watch for new community questions, and answer them if they can.** (Questions are sent into Zendesk for the support hero, but you can help ease the burden _while_ contributing to faster response times, which can lead to more positive interactions with customers (or prospective customers).
+**We encourage all team members to watch for new community questions and answer them if they can.** Questions are sent into Zendesk for the support team, but you can help ease the burden while contributing to faster response times, which can lead to more positive interactions with customers (or prospective customers).
+
+**Support team members and Support Heroes** handle community questions through Zendesk as part of their normal workflow. See the [community and free plan support handbook page](/handbook/support/community-and-free-support) for details on the Zendesk workflow.
+
+Teams should stay on top of community questions within their product areas. Teams can decide if they want their weekly support hero to handle them, or if they want to collectively keep an eye on them.
 
-- Teams should be responsible for staying on top of community questions within their product areas.
+**To stay informed about new questions:**
 
-- Teams can decide if they want their weekly support person to handle them, or if they want to collectively keep an eye on tickets. (We’re adding more info to Slack notifications so they’re more useful.)
+- The Website & Docs team can help in configuring Slack notifications for small teams to receive alerts to questions in a team channel – usually the one designated for support.
+- Individually, you can also subscribe to topics of your choosing (with your PostHog.com account) by clicking the bell icon next to the topic's title. You'll receive a daily summary of new questions by email, and you'll find open threads for that topic in your personalized [community dashboard](/community/dashboard) (available when signed in).
 
-- At our current size and current question volume, teams should be able to stay on top of question notifications in Slack and help out *proactively*.
 
-If a question needs a follow-up later on, tag it with `Internal: follow-up` and the Website & Docs team can make sure there's a resolution.
+If you answer a question and it needs follow-up later, tag it with `Internal: follow-up` and the <SmallTeam slug="brand" /> team can make sure there's a resolution.
 
 ## Guidelines
 
 ### Phrasing & tone
 
-When possible, respond in a phrase that doesn’t directly indicate you work for PostHog. (We can encourage community engagement by intentionally separating ourselves from the image it's a support forum where only PostHog employees respond.)
+When possible, respond in a phrase that doesn't directly indicate you work for PostHog. (We can encourage community engagement by intentionally separating ourselves from the image it's a support forum where only PostHog employees respond.)
 
-- Instead of... _“We are launching a new feature that will solve this - here’s the pull request.”_
-- Try... _“There’s a pull request out for this feature now.”_
+- Instead of... _"We are launching a new feature that will solve this - here's the pull request."_
+- Try... _"There's a pull request out for this feature now."_
 
 ### Various cases you may come across...
 
-Some questions don’t make sense to be public, and some answers should be more widely accessible. Here’s how to handle those:
+Some questions don't make sense to be public, and some answers should be more widely accessible. Here's how to handle those:
 
 - If an answer is worth adding to docs, the moderator has a few options:
     - Answer the question and update the docs directly
-    - Tag the question (`Internal: documentation`) so the Website & Docs Team can triage
+    - Tag the question (`Internal: documentation`) so the <SmallTeam slug="docs-wizard" /> can triage
     - Create an issue in `posthog/posthog.com` with the `technical documentation` label
     - If the topic is worth creating a tutorial, tag it with `Internal: tutorial idea`
 
-- If a question is better off a private support ticket, reply asking them to create a ticket within the app (or better yet: create one for them and reply to let them know!)
+- If a question is better off as a private support ticket, create one for them and reply to let them know! (ask in #team-support if you need help doing this)
     - After responding, use the Archive button. This hides the question from being listed within a forum category and removes the question from search indexes.
     - _Note that free users might not have the option to directly message support in-app, so get context as to who the person is before pointing them there._
 

contents/handbook/support/community-and-free-support

@@ -0,0 +1,119 @@
+---
+title: Community and Free Plan support
+sidebar: Handbook
+showTitle: true
+---
+
+## Overview
+
+This page covers how the support team handles community questions and free plan support tickets. Community support is fundamentally different from paid customer support—we prioritize peer-to-peer help and sustainable support practices while maintaining our commitment to helping all users succeed with PostHog.
+
+## What are community questions?
+
+Community questions are questions posted by users on our docs pages (at the bottom of any page on posthog.com/docs) or directly in our community forums at posthog.com/questions. These questions:
+
+- Are public and searchable
+- Help improve our documentation
+- Build a knowledge base for all users
+- Encourage peer-to-peer support
+
+Community questions are integrated into the support team's workflow through Zendesk, allowing us to provide better coverage while maintaining appropriate prioritization.
+
+For broader context on PostHog's community strategy and how the community platform works, see the [Community handbook page](https://posthog.com/handbook/community).
+
+## How community tickets work in Zendesk
+
+### Ticket creation and routing
+
+When a user posts a community question, a ticket is automatically created in Zendesk. These tickets are:
+
+- Assigned a **PostHog Priority of "Community"**
+- Given a **target response time of two weeks**
+- **Assigned to the appropriate product group** where it can be determined (e.g., tickets from Product Analytics pages are assigned to the Product Analytics group)
+- Defaulted to the **'Support' group** if the product area can't be automatically determined
+- **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
+2. It ensures community tickets don't take precedence over tickets raised via Slack or in-app support
+
+**Note on default routing:** If you notice tickets being defaulted to the Support group that should have been routed elsewhere, consider why the automatic routing didn't work and whether there's a way to improve the routing logic in future.
+
+### How community ticket sync works
+
+Community tickets have a two-way sync between the community forum and Zendesk:
+
+**From community → Zendesk:**
+- Original question creates the ticket
+- Follow-up comments from the customer or other community members add to the ticket
+- When a customer marks a response as the solution, the ticket is automatically solved
+- If a ticket is Pending or Solved and the customer responds, the ticket reopens as normal
+
+**From Zendesk → community:**
+- Public replies from support agents post to the community thread
+- Private/internal notes stay in Zendesk only
+
+**Things to note:**
+- Zendesk is set up so that it doesn't send emails about community tickets (neither ticket creation nor replies). Community handles its own email notifications to users.
+- No CSAT survey is sent for community tickets. Zendesk is purely a way for us to manage these questions and ensure customers get responses—we're not treating them like traditional support tickets.
+- Once a ticket is closed in Zendesk, follow-up tickets don't currently work as expected.
+
+## Answering community questions as a support engineer
+
+### How to respond effectively
+
+For detailed guidance on tone, style, and best practices when answering community questions, see [Answering community questions](https://posthog.com/handbook/community/questions).
+
+**Keep responses public and helpful:**
+- Answer community questions with the same quality and care as paid support, but be mindful of scope
+- Write responses that benefit not just the original poster but anyone who finds the question later
+- Link to relevant documentation whenever possible
+- If you're making assumptions or suggesting approaches, be clear about that
+
+**When responding in Zendesk:**
+- Write your response as a public reply
+- Your response will automatically post to the community thread
+- Use Zendesk statuses in the same way you would for any other ticket
+
+### When to convert to a private support ticket
+
+Use your best judgement when deciding whether a community question should become a private support ticket. Some cases where you might want to convert:
+
+- The conversation involves sensitive information (account details, billing, security, private data)
+- The issue requires deep investigation into a customer's specific setup
+- Multiple back-and-forth exchanges would be needed
+- The customer needs access to their PostHog instance to debug
+
+**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)
+4. Mark the original community ticket as Solved in Zendesk
+
+## Free plan support policy
+
+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**.
+
+### Supporting free users
+
+When helping free users, be genuinely helpful while maintaining appropriate boundaries:
+
+- Point to relevant documentation
+- Answer general "how-to" questions
+- Explain concepts and troubleshooting approaches
+- Be honest if they need more than community support can provide
+
+Avoid getting into deep account-specific debugging, writing custom code for their use case, or providing ongoing consulting-style support. If someone needs more hands-on help, that's a signal they should consider a paid plan.
+
+## Self-hosted and open-source support
+
+**We do not provide customer support for self-hosted PostHog instances.** This is explicit in our documentation and support policies.
+
+When self-hosted users reach out through community questions:
+
+- Direct them to [self-hosting documentation](https://posthog.com/docs/self-host), troubleshooting guides, and GitHub
+- Be clear that hosting environments vary too widely for us to debug effectively
+- We can answer general product questions but can't help with infrastructure, deployment, or performance issues
+- Suggest migrating to PostHog Cloud if they're hitting scaling challenges or need more support (generous free tier: 1M events, 5k recordings, 1M flag requests, 100k exceptions, 1500 survey responses/month)

src/navs/index.js

@@ -1309,6 +1309,10 @@ export const handbookSidebar = [
                     },
                 ],
             },
+            {
+                name: 'Community and Free Plan support',
+                url: '/handbook/support/community-and-free-support',
+            },
             {
                 name: 'Troubleshooting tips',
                 url: '/handbook/support/troubleshooting-tips',