|
1 | | -### Implement two way sync for community questions with Zendesk |
2 | | -- **Owner:** <TeamMember name="Christian Rafferty" photo /> |
3 | | -- **Rationale:** A centralised tool for managing both community and non-community tickets will give the support team full visibility into all customer questions without splitting focus across multiple platforms. This also creates the groundwork for being able to offer some level of support to free customers. |
4 | | -- **What we'll ship:** When a community question is posted, ensure that it is raised in Zendesk and assigned to the correct agent group. When follow up replies are posted on the community question thread, ensure that these are posted onto the Zendesk ticket and the ticket status changes appropriately. Allow agents to post their reply in Zendesk as a public comment which will be posted to the community thread (internal comments will remain only in Zendesk). Ensure that the desired behaivour is achieved relative to existing triggers and automations that exist in Zendesk. |
5 | | -- **We'll know we're successful when:** All community tickets and their replies are tracked in Zendesk, community tickets follow the same status rules as non-community tickets, and we are able to start considering target response times for community questions. |
6 | | -- **Stretch Goal:** Set the `Org plan level` on the ticket. |
| 1 | +### Get SDK Doctor out of beta and leveled-up |
| 2 | +- **Owner:** <TeamMember name="Steven Shults" photo /> |
| 3 | +- *Rationale:* Officially moving SDK doctor out of beta and into general availability will help our customers trust SDK Doctor for staying up to date with the latest version of our SDKs. Further extending functionality will help customers keep their data in good shape, and enhance the support we provide. |
| 4 | +- *What we'll ship:* Additional functionality (new debug properties in events for use by SDK Doctor, subscriptions, SDK info added to support tickets, improved internal tracking), moving from beta to official general availability, continued improvements based on feedback |
| 5 | +- *We'll know we're successful when:* SDK doctor is further enhanced, out of beta, and helping customers keep their PostHog integration humming along smoothly |
7 | 6 |
|
8 | | -### Create a reliable way to surface if we are experiencing a customer facing incident |
9 | | -- **Owner:** <TeamMember name="Joshua Ordehi" photo /> |
10 | | -- **Rationale:** Being able to surface incidents faster means that we as a company can jump on those incidents and fix them sooner. |
11 | | -- **What we'll ship:** Improvements to the existing reporting and alerting that Joshua has created which looks at support tickets created from customer facing errors. The goal is to make the detection more accurate (considering both specific product areas and being able to identify cross-functional issues) and less noisy. The next stage of implementation will also look at the related error tracking issue to discover if more customers are experiencing this error/incident (within a specific timeframe) but aren't reporting it in support tickets. |
12 | | -- **We'll know we're successful when:** We feel confident enough in the accuracy of the incident identification to put the alert into #tell-posthog-anything. |
| 7 | +### Allow some customers to be able to view and respond to tickets from the support sidebar |
| 8 | +- **Owner:** <TeamMember name="Ben Lea" photo /> |
| 9 | +- **Rationale:** Allowing customers to view their tickets from the sidebar provides an easy access source of truth for the status of their tickets. This should make it clearer when we are waiting on information from a customer and hopefully prevent situations where customers don't see responses that get lost in their email filters. |
| 10 | +- **What we'll ship:** A way for customers to be able to view their tickets from within the support sidebar. They should be able to see the status of the ticket, respond to the ticket directly within the sidebar, and link out to the Zendesk help center. We will get this live behind a feature flag and roll it out to customers who are keen to test out this feature. |
| 11 | +- **We'll know we're successful when:** Some customers are able to reliably view the status of their tickets and respond from the sidebar, and we are receiving feedback from these users. |
13 | 12 |
|
14 | | -### Make it more obvious how to submit tickets during the login workflow |
15 | | -- **Owner:** <TeamMember name="Eleftheria Trivyzaki" photo /> |
16 | | -- **Rationale:** Prevent customer frustration and improve support experience by making it more obvious how to submit tickets during the login workflow. |
17 | | -- **What we'll ship:** Implement a more obvious prompt to the user for how to submit a support ticket. |
18 | | -- **We'll know we're successful when:** Fewer tickets with the `email-closed` tag that have been created due to issues encountered during the login workflow. |
| 13 | +### Develop a framework for how support apps and tools are deployed |
| 14 | +- **Owner:** <TeamMember name="Ben Lea" photo /> |
| 15 | +- **Rationale:** Having a known and consistent way of deploying our support apps makes us more efficient in the development of our tooling. |
| 16 | +- **What we'll ship:** Consider the best approach for deploying our support tooling and support apps. We'll create and document a deployment framework and test this on at least one of our apps. |
| 17 | +- **We'll know we're successful when:** We have a clear and understood way forward for how we'd like to deploy our support apps, and we've deployed at least one app using this framework. |
19 | 18 |
|
20 | | -### Develop a framework that will give us confidence in how PostHog AI is being used as a support tool |
21 | | -- **Owner:** <TeamMember name="Luke Belton" photo /> |
22 | | -- **Rationale:** PostHog AI is being used as a support tool and we don't really know what the quality of that support is. We want to ensure that users are receiving the best support experience and that PostHog AI is monitored with that in mind. If PostHog AI gives bad support advice then we will confuse our customers and worst case leave them looking for solutions from PostHog alternatives. |
23 | | -- **What we'll ship:** This is a research piece that will outline a future framework for evaluating PostHog AI as a 'member' of the support team. |
24 | | -- **We'll know we're successful when:** We have a clear route forwards on how we want to be testing PostHog AI support output. We'll have a good understanding of how to feedback PostHog AI performance on support and iterate to improve it. |
| 19 | +### Improve the ticket creation experience to be simpler, smarter, and more PostHog |
| 20 | +- **Owner:** <TeamMember name="Ben Haynes" photo /> |
| 21 | +- **Rationale:** Creating tickets is the primary way that customers get in contact with us and it's important that this experience is as seamless as possible. We should be looking for ways to automatically capture as much context and data as we can, without the need to ask additional questions of the customer. As PostHog grows and ships more products, this experience should evolve to stay clear, efficient, whilst also continuing to spark joy. |
| 22 | +- **What we'll ship:** Investigate, design, and ship improvements to the ticket creation flow. This includes: simplifying or rethinking product selection, improving how context and urgency are captured, and exploring where relevant context can be automatically surfaced. |
| 23 | +- **We'll know we're successful when:** We've begun implementing improvements to the ticket creation flow which gives more context to our support team, and requires less manual input from customers. |
| 24 | +- **Stretch Goal:** We may consider dynamically asking the customer additional questions or gathering additional context for particular types of support tickets. |
25 | 25 |
|
26 | | -### Get SDK Doctor into active beta and collecting feedback from users |
27 | | -- **Owner:** <TeamMember name="Steven Shults" photo /> |
28 | | -- **Rationale:** Getting SDK doctor into active beta will help our customers understand if they are staying up to date with the latest version of our SDKs or if they are trying to call feature flags too soon. Having this in active beta will allow us to see how users respond (and address some feedback) before extending the functionality of SDK doctor. |
29 | | -- **What we'll ship:** We'll complete all beta prep including creating public documentation, getting the code reviewed by engineering, tightening up and extending our test cases, and generally shipping SDK doctor into an active beta state. We can also implement any feedback we receive from customers that we think is reasonable. |
30 | | -- **We'll know we're successful when:** SDK doctor is in active beta and feedback tickets about SDK Doctor are coming into Zendesk from customers. |
| 26 | +### Explore how product tours can be used as a support tool |
| 27 | +- **Owner:** <TeamMember name="Joshua Ordehi" photo /> |
| 28 | +- **Rationale:** It's important that we continue to consider new and better ways that we can help and share information with our customers to improve the support experience. |
| 29 | +- **What we'll ship:** Consider where product tours can be used as a support tool and where they could be used as a replacement for screenshots that we provide to the customer. Additionally consider the ways we could use product tours as a way of enabling/helping customers, leading to a reduction in ticket creation. |
| 30 | +- **We'll know we're successful when:** We've determined how useful product tours can be as a support tool and identified use cases that have been shared with the support team. |
| 31 | + |
| 32 | +### Explore AI accessibility for product capabilities |
| 33 | +- **Owner:** <TeamMember name="Joshua Ordehi" photo /> |
| 34 | +- **Rationale:** Keeping AI tools in sync with product changes currently requires manual updates. If we expose which operations are valid and what parameters they require as queryable product capabilities, AI could inherit this automatically and stay consistent with the API and UI. Improving PostHog AI to keep up to date with the latest changes in the product helps improve PostHog AI's answers and in turn should reduce the support load. |
| 35 | +- **What we'll ship:** Extract domain rules for one product (surveys) into a layer that both existing surfaces and AI tools can consume. Design validation flows that let PostHog AI query what operations are valid. |
| 36 | +- **We'll know we're successful when:** PostHog AI is able to validate against shared domain rules for our surveys product, and those rules update automatically when the product changes without requiring manual sync. |
31 | 37 |
|
32 | | -### Investigate and design a tool that will become our omnisearch and source of knowledge that we use while solving tickets |
33 | | -- **Owner:** <TeamMember name="Ben Lea" photo />, <TeamMember name="Ben Haynes" photo /> |
34 | | -- **Rationale:** Having better AI tooling and search ability for support engineers makes us more efficient in diagnosing issues and answering support tickets. |
35 | | -- **What we'll ship:** Do investigation into approaches we can take to create this tool (whether we use a third party or something homegrown). Design and implement a minimum prototype of this tool that can be used by the support team. |
36 | | -- **We'll know we're successful when:** We have a design for this tool and have a prototype we can build on. |
| 38 | +### Capture more context at the time a ticket is raised |
| 39 | +- **Owner:** <TeamMember name="Luke Belton" photo /> |
| 40 | +- **Rationale:** The more context that we can capture when a ticket is created, the less time we spend investigating and going looking for that information, and the fewer back and forths we need to have with the customer. This puts us in a better position to deliver a high quality, efficient, and enjoyable support experience. |
| 41 | +- **What we'll ship:** Get the 'feedback recording' hackathon project into production (#2571 and #41380) so that customers can provide a screenshare with voiceover as a new way to talk us through an issue they're facing. Also investigate other ways to automatically gather context around an issue - for example using PostHog Signals. |
| 42 | +- **We'll know we're successful when:** We find ourselves having to ask clarifying questions on fewer tickets. Correspondingly, we may see a reduction in average responses per ticket and faster time to resolution. |
37 | 43 |
|
38 | | -### Design a tool that helps us to troubleshoot customer implementations of PostHog |
| 44 | +### Implement a tool that helps us to troubleshoot customer implementations of PostHog |
39 | 45 | - **Owner:** <TeamMember name="Kyle Swank" photo /> |
40 | 46 | - **Rationale:** Having better tooling for support engineers makes us more efficient in diagnosing issues and answering support tickets. |
41 | | -- **What we'll ship:** Design a tool (we'll consider browser extensions, using the toolbar, implementations in PostHog, etc) which helps support engineers to more easily troubleshoot customer's implementations of PostHog. Consider two of the most common things we as support engineers need to surface from a customer's implementation when troubleshooting, and design a tool which can more easily surface these things. |
42 | | -- **We'll know we're successful when:** We have a design for this tool and have begun implementing a minimum functioning version of it. |
| 47 | +- **What we'll ship:** Continue work on the support browser extension that begin in the previous quarter and refine it for use by the support team. We'll ship the support browser extension, along with appropriate documentation (readme, handbook), and get it into general use by the support team, gathering team feedback. |
| 48 | +- **We'll know we're successful when:** This tooling is streamlining support investigations for the team, and the team is providing feedback and suggestions for new features. Extra credit if released to sales and customer success. |
| 49 | +- **Stretch Goal:** Ship changes to the events view to allow for saved views and built-in debug based views. |
| 50 | + |
| 51 | +### Streamline security and impersonation logic |
| 52 | +- **Owner:** <TeamMember name="Christian Rafferty" photo /> |
| 53 | +- **Rationale:** Enhance existing impersonation security logic to enable a smoother, more controlled process for requesting data access from organizations that have explicitly opted out of impersonation. This should enable us to work on support tickets quickly and efficiently whilst maintaining our security procedures. |
| 54 | +- **What we'll ship:** Options in the support sidebar for customers who have opted out of impersonation, allowing time-bound access to their data (for example, the duration of an active support ticket). We should also consider a direct mechanism for requesting data access from customers who have opted out of impersonation. |
| 55 | +- **We'll know we're successful when:** Users who opt out of impersonation feel confident their data remains protected, while support teams can still provide fast, hands-on assistance when needed. |
| 56 | +- **Stretch Goals:** |
| 57 | +* Launch two-way community ticket sync, address smaller follow-up issues, and provide continued support post-launch. |
| 58 | +* Enable updates to support messaging in the sidebar without requiring a pull request. |
| 59 | + |
| 60 | +### Ensure all tickets have up-to-date and complete organization information (organization, plan, priority) |
| 61 | +- **Owner:** <TeamMember name="Eleftheria Trivyzaki" photo /> |
| 62 | +- **Rationale:** Having this information automatically set for all tickets improves ticket workflows, management, data accuracy, and saves support engineer time. |
| 63 | +- **What we'll ship:** An automation that updates missing organization, plan, and priority information for tickets in Zendesk, ensuring tickets are complete when they are created. |
| 64 | +- **We'll know we're successful when:** There are almost no tickets without the required details (org, plan, priority), SLAs are applied correctly and the team spends less time updating fields manually. |
| 65 | + |
| 66 | +### Create a Superday task for the Billing Support role |
| 67 | +- **Owner:** <TeamMember name="Eleftheria Trivyzaki" photo /> |
| 68 | +- **Rationale:** Creating this superday task allows us to be better prepared for future hiring and expansion of the billing support specialists on the team. |
| 69 | +- **What we'll ship:** A Superday task for this role that simulates close-to-real-life work, with clear instructions, and expectations. |
| 70 | +- **We'll know we're successful when:** We have a ready-to-use Superday task for future hiring, and the hiring team feels confident it reflects the real work of the role and makes it easier to evaluate candidates fairly. |
43 | 71 |
|
44 | 72 | ### Things <TeamMember name="Abigail Richardson" photo /> is focusing on this quarter: |
45 | | -- Implementing Support Zero weeks to enable the team to reach more of our quarterly goals |
46 | | -- Outlining a strategy for SMEs and how we get there to enable the team to deal with the rising complexity in tickets |
47 | | -- Outlining a strategy for products coming out of beta and into support |
48 | | -- Outlining a strategy for community support |
| 73 | +- Implementing a strategy for community support |
| 74 | +- Implementing a strategy for SMEs and how we get there to enable the team to deal with the rising complexity in tickets |
49 | 75 | - Hiring and onboarding to improve support coverage |
50 | | -- Improving reporting, especially on coverage and where tickets come from |
| 76 | +- Outlining a strategy for products coming out of beta and into support |
| 77 | +- Improving reporting, especially on accounts/billing related tickets, and when tickets should be flagged |
0 commit comments