Understand the quality of support customers get from PostHog AI (Christiaan HendriksenChristiaan Hendriksen and Luke BeltonLuke Belton)

• Rationale: PostHog AI is already acting as first-line support, but it's a black box. We don't know how much support it's doing, the quality of those customer interactions, or where they're getting stuck.
• What we'll ship: A plan for what to capture (how many conversations are support questions, common topics, wrong or suboptimal recommendations, tickets caused by earlier AI advice, frustrated conversations, etc), run a time-boxed 2–3 week deep dive once the new PostHog AI harness is live, then use the findings to decide what ownership should look like.
• We'll know we're successful when: We have a way of surfacing analysis and customer-related feedback from AI conversations, and gaps are reaching SMEs as skill and docs fixes.

Deslop the Slop Before It Slops (Phillip RamirezPhillip Ramirez)

• Rationale: AI agents draft and file tickets on a customer's behalf with no guidance on what a useful ticket contains, or how to make one readable by a human.
• What we'll ship: guidance and a skill that AI agents can use while drafting a ticket. We'll look to tackle verbosity in AI tickets by outlining an ideal ticket structure, steer agents to obtain information we might need (like links, errors, etc), and specific information (like what the user asked for, what they tried, and why they are asking support for help)
• We'll know we're successful when: tickets submitted by AI agents are concise and useful, without needing to ask for more information as a first step.

Use AI to make AI-written tickets less tiring to read (Ben HaynesBen Haynes)

• Rationale: Plenty of the tickets we receive are AI-written text pasted into the support sidebar: long, with unnecessary questions or statements, missing error messages, product areas or repro steps. Reading them all day is slow and wears the team down.
• What we'll ship: Tooling in HogDesk that uses AI to cut received slop tickets down to what the customer actually needs, and flag what's missing.
• We'll know we're successful when: The team spends less time and energy reading AI-written tickets.

Let customers show us the problem with feedback recordings (Luke BeltonLuke Belton)

• Rationale: AI fatigue is growing, and customers respond well to a human conversation. A recording tells us more than an AI summary.
• What we'll ship: A way for customers to record and attach a short Loom-style video of their problem when raising a ticket.
• We'll know we're successful when: we are receiving tickets from customers with recordings showing us their issues.

Stop customers getting ignored: fewer SLA breaches, especially on escalations (Abigail RichardsonAbigail Richardson)

• Rationale: Q3 SLA attainment dropped to 81.2%, enterprise first response went from ~7 hours to 29 hours, and a number of escalated tickets have been left too long. Some of this will be due to the change from Zendesk - but we need to do better.
• What we'll ship: Team notifications for upcoming SLA breaches, call out teams with the tickets that are breached by the longest, a way of pulling breached escalated tickets back into the support queue so that the team can follow up, and a way of flagging tickets where customers are checking in on the ticket with no reply.
• We'll know we're successful when: SLA attainment for Q4 is better than SLA attainment for Q3, response times for top customers are improving, and the average length of breached tickets is decreasing.

Give logged-out users a better support experience (Eleftheria TrivyzakiEleftheria Trivyzaki)

• Rationale: Customers who can't log in get a preview of our reply and a button that makes them log in, which doesn't help if logging in is the problem.
• What we'll ship: A logged-out experience where customers can read and reply without logging in, likely by using cross-channel replies so a ticket raised in one channel can be answered from another (i.e. widget to email).
• We'll know we're successful when: Logged-out customers can get help end-to-end without logging in, and the feedback about it stops.

Make data deletion and retention tickets go away (Ben LeaBen Lea)

• Rationale: Deletion and retention are one of our biggest ticket sources, self-serve deletion doesn't work well.
• What we'll ship: Ben will own the deletion and retention tickets. We will provide input into the owning team's self-serve deletion work, and make sure we have clear answers on the new retention model.
• We'll know we're successful when: Deletion and retention tickets drop, and customers can delete their own data without us doing it for them.

Improve incident handling for support and experience for Slack customers (Chris ShineChris Shine)

• Rationale: More efficient incident handling makes customers more happy.
• What we'll ship: Better automatic identification and tagging for tickets related to an ongoing incident. An easy way to bulk assign incident tickets (or maybe auto-assign to the watcher), create a standard response draft for all tickets related to the incident, link out to the incident Slack channel, and look into syncing the support watcher with incident.io. Look into the use of Sherlock and HogDesk.
• We'll know we're successful when: Incident tickets are tagged automatically and accurately, anyone can find and easily answer them from one place, and Slack customers understand when an outage would affect raising tickets.

Improve docs from a support perspective (Alin-emanuel CîciuAlin-emanuel Cîciu)

• Rationale: We've put in several docs updates recently where the information was wrong or out of date, and customers' AI agents rely on our docs to help them. We also lost support's feedback loop into docs when we moved from Zendesk to PostHog support.
• What we'll ship: fixes and improvements to the docs and the workflows/processes that update them. We need an understanding of what's allowing docs to get out of date, and a way to comb through the docs and find where they're now wrong. We'll also look to reinstate support feedback into the docs team, and consider self-driving docs updates off the back of support tickets.
• We'll know we're successful when: We know which docs are wrong and why, support feedback reaches the docs team again, and tickets caused by outdated docs go down.

Spot data sync issues and tell customers before they write in (Kyle SwankKyle Swank)

• Rationale: The warehouse sources team already spots sync issues and Tom's bot raises PRs for them, but nobody tells the affected customers.
• What we'll ship: A way to pick up detected sync issues, find the affected customers, and either make it clearer in-app and/or raise proactive tickets on the customer's behalf.
• We'll know we're successful when: We let customers know about sync issues before they contact us, and inbound sync tickets go down.

Let customers debug their own replays with PostHog AI (Christian RaffertyChristian Rafferty)

• Rationale: customers frequently ask why their replay looks incorrect. This involves us inspecting the customer's website or tracing through their JSON by hand, which could be automated.
• What we'll ship: A "Debug this replay" button that opens PostHog AI with the replay's JSON attached, new skills to read the JSON effectively, and the diagnosis is saved back to the replay to help all users in the project. We'll do a flagged rollout starting with ourselves.
• We'll know we're successful when: customers are using this functionality and Replay ticket numbers are reduced.

Build a PostHog CLI for support (Xander JonesXander Jones)

• Rationale: There are repeated tasks that support perform which are currently being done via MCP, as a one-off script, or via an AI session. A deterministic, tested CLI would be faster, do the same thing reliably every time, and save us tokens.
• What we'll ship: Xander's existing CLI tooling made generic, with robust testing, so the team can add targeted tools to it, starting with bulk property pruning and smoother impersonation.
• We'll know we're successful when: The team uses it for repeat tasks instead of scripts or AI sessions

Give our support agents a memory of tickets (Steven ShultsSteven Shults)

• Rationale: Our agents learn things on every ticket, but they write to sandboxes that get wiped on restart, so knowledge never builds up and the same mistakes repeat across agents. Giving them more shared context means fewer iterations, and faster resolution, even if the investigation is continued by a different team member.
• What we'll ship: A shared, persistent ticket memory. Notes would be stored alongside each ticket, corrections that every agent learns from, and personal preferences per engineer, as well as notes stored in a shared place for knowledge that can be applied to later tickets.
• We'll know we're successful when: AI agents build on earlier investigations and corrections instead of repeating them, and the team spends less time iterating with agents on each ticket.

The big shift this quarter is the switchover from Zendesk to conversations, so every goal below assumes we are working in conversations. SLA attainment will be harder to measure and easy to let slip, so our overriding aim is to protect the customer experience through the transition: hold response times and SLA attainment as steady as we can, and keep CSAT high. Success this quarter looks like customers barely noticing the switchover.

1. Improve the proactive and in-app support customers get

Surface why a replay won't play (Christian RaffertyChristian Rafferty)

• Rationale: reduce number of replay tickets by providing more context around our most asked question: "why is my replay not playing / infinitely buffering?"
• What we'll ship: our events already carry debug information to be able to answer this. We will use that information and surface it in a way that customers can self-solve rather than needing to raise a ticket.
• We'll know we're successful when: fewer "replay won't play" tickets reach the ticket queue.

Build out experiments ticket investigation skill (Phillip RamirezPhillip Ramirez)

• Rationale: we receive a number of common questions around experiments that we can help customers to self-serve the answers to. The plan here is to reduce the number of these tickets we recieve.
• What we'll ship: we'll build a skill that defines how experiments tickets can be investigated. This can be a skill to be used internally and we can even consider making this a customer-facing skill.
• We'll know we're successful when: we've shipped at least one troubleshooting skill for experiments and can see those recurring tickets reducing.

Improve the experience of getting support via PostHog AI (Christiaan HendriksenChristiaan Hendriksen)

• Rationale: we want customers to receive correct and reliable information via PostHog AI and we want them to be able to seamlessly raise tickets from wherever they are, without having to switch to the PostHog sidebar.
• What we'll ship: collect and build data analysis of support quality via PostHog AI. Ship improvements to the way that AI hands-off to support tickets and ship ways for customers to raise tickets via the AI.
• We'll know we're successful when: we have a data-backed picture of AI support quality and customers can raise tickets via AI.

Define signals for proactive support (Luke BeltonLuke Belton)

• Rationale: if we spot something customers might need help with before they do, we can create a ticket and reach out to them - creating a support experience that sparks joy and prevents churn in a very proactive way.
• What we'll ship: define a set of data-backed signals we could use to proactively help customers. This should be based on churn data, information from tickets where customers are getting stuck, changes in customer usage, or ways that we can determine something is not right in the customer's set up.
• We'll know we're successful when: we have a set of concrete signals we could use to create proactive tickets from.

2. Make support faster and smarter in the Support product

Bring valuable HogDesk features into the Support product (Xander JonesXander Jones)

• Rationale: the Support product is our new home for support, and as a team using it every day we're well placed to make it better.
• What we'll ship: ship two features we find most valuable in HogDesk and bring them across into the Support product - getting it right for ourselves as much as for our customers.
• We'll know we're successful when: our productivity in conversations is improved by these new features

Tidy up the customer support experience and sidebar (Ben LeaBen Lea)

• Rationale: we want it to be easy for customers to raise tickets with us (from the sidebar, from error messages, as feature feedback), and be able to see what ongoing tickets they have open. At the moment the sidebar is a long, unwieldy scroll of tickets that needs fixing.
• What we'll ship: ship changes to the ticket sidebar so that customers don't see all of their tickets at once - resolved tickets can be hidden or available somewhere else. Ship changes so that conversations tickets are raised from error messages and feature feedback.
• We'll know we're successful when: customers have a clearer, faster experience raising and following up on tickets.

Better information captured on tickets (Kyle SwankKyle Swank)

• Rationale: the more information we can capture at ticket creation time, the quicker it is for us to investigate a ticket and get solutions to our customers
• What we'll ship: we'll create a skill that is invoked when a ticket is created to gather additional information and helps the customer submit a better ticket for us to investigate
• We'll know we're successful when: we are receiving better constructed tickets and more immediate context on tickets

Feedback recordings in the Support product ticket flow (Luke BeltonLuke Belton)

• Rationale: customers being able to submit recordings with their ticket will allow them to show us exactly what they think is going wrong. This makes it easier for customers to raise a ticket and gives us richer context up front.
• What we'll ship: the ability for customers to submit a recording with their ticket.
• We'll know we're successful when: we are receiving tickets from customers with recordings showing us their issues.

More efficient impersonation (Steven ShultsSteven Shults)

• Rationale: we want account impersonation to be fast and seamless so that we don't lose time while investigating tickets.
• What we'll ship: Steven ShultsSteven Shults will add MCP impersonation to HogDesk - if time allows, we will extend this to conversations and PostHog code. Xander JonesXander Jones will ship the ability to switch between impersonated users in the same org.
• We'll know we're successful when: when engineers can get into an impersonated MCP session with a less clunky re-auth than the impersonation-toolkit steps, and switching users is quicker.

Surface ticket trends and potential incidents (Ben HaynesBen Haynes)

• Rationale: spotting ticket patterns and trends helps us to identify incidents and prominent bugs faster, leading to faster fixes.
• What we'll ship: implement functionality in conversations that identifies ticket trends and surfaces potential incidents.
• We'll know we're successful when: we are alerted of prominent bugs and possible incidents from conversations tickets, rather than relying on one person to spot them.

Complete the move to the Support product and retire Zendesk (Abigail RichardsonAbigail Richardson)

• Rationale: move 100% into conversations for all of our support. This helps us to give feedback into our own product and help it grow.
• What we'll ship: handbook updates, workflows and notifications in place, and reporting and CSAT working again
• We'll know we're successful when: support tickets are entirely in conversations, Zendesk is retired, and reporting is in place for conversations

3. Billing and legal self-serve

Make the BAA process self-serve for startup-plan customers (Eleftheria TrivyzakiEleftheria Trivyzaki)

• Rationale: BAAs require the Boost add-on, but startup credits don’t cover BAAs. Startups on credits shouldn’t be able to sign a BAA in-app without a separate subscription. We also don't currently track BAAs for startup customers or have a defined process, so handling is ad hoc.
• What we'll ship: a self-serve path for startup plan customers to request Boost and get a BAA, plus a documented process for handling these requests. Nice to have: visibility into how many existing startup plan customers already have a BAA in place without a separate subscription.
• We'll know we're successful when: startup plan customers can resolve the BAA/Boost limitation on their own, we have a repeatable process for handling these requests, and we can report on BAA coverage across the startup plan.