Pineapple on pizza

No data available

Members

Goals

Q2 2026

This quarter we're driving SLA attainment and response times in one direction: up. We want consistent week-on-week improvement, with our Q2 average beating Q1. Every goal below is pointed at making that happen — through deeper product knowledge, faster investigations, and fewer tickets raised in the first place.

1. Deepen SME expertise and reduce ticket friction

A core focus this quarter is turning our SMEs into genuine product experts — people who can spot patterns, advocate for fixes, and proactively prevent tickets before they're raised.

Objectives
  • Identify most common investigation steps that could be surfaced onto tickets automatically
  • Identify proactive interventions (e.g. docs, in-app prompts, automatic checks) that could prevent recurring tickets
  • Identify top user pain points or bugs and feed these back to the relevant engineering teams
  • Begin establishing an SME for analytics products
Owners

2. Ship improvements that make support faster and smarter

2.1 SDK Doctor improvements

Owner: Steven Shults

Objective: Add a couple of additional features to SDK doctor - including alerts, and understanding how PostHog is being initialised. Implement a couple of fixes for existing known issues. If we have time we will look into doing tasks to get SDK doctor into GA.

2.2 Surface useful context for support investigations

Owner: Kyle Swank

Objective: Start by enhancing information captured at the bottom of Zendesk tickets with additional context and information that could help the support engineer during the investigation of the ticket. We will also investigate what the future of this should look like, considering things like enhancing the health overview. The intention with the investigation is to understand what this should look like for us internally as we start to use different tools, and then later consider how we might be able to make this diagnostic information available to users to proactively help them.

2.3 Surface information about the state of replay capture from events

Owner: Christian Rafferty

Objective: Currently we store properties on events which provide information about the state of replay capture at the time of the event. These properties are frequently used when trying to diagnose recordings and whether a recording should have taken place. We plan to investigate ways that this information can be:

  1. proactively surfaced to users to prevent the need for them to raise a ticket
  2. available to support members while working on tickets to reduce investigation time
2.4 Quality of life improvements to account impersonation

Owner: Xander Jones

Objective: Make initial improvements to account impersonation, making switching between impersonated users within the same organization easier. We will also investigate what improvements and enhancements can be made to make impersonation easier when answering customer queries via conversations.

3. Billing support readiness

Owner: Eleftheria Trivyzaki

3.1 Complete the Billing Support Superday task

Objective: Build on the Q1 work to deliver a ready-to-use Superday task for the Billing Support role. We'll know we're ready when the task has been through at least one round of feedback and the team feels confident it'll help us hire the right person

3.2 Stay ahead of billing launches this quarter

Objective: Get up to speed on upcoming billing changes by testing new features, attending relevant conversations, and building context before launch. We'll know this is working when launch day doesn't cause a spike in unresolved tickets or SLA breaches, and feedback is being routed back to the right people in real time.

4. Raise the bar for high-paying customers and team clarity

Owner: Abigail Richardson

4.1 Improve response times and coverage for high-paying customers

Objective: Define and document when it makes sense to share a ticket across timezones vs. take care of it yourself, with the goal of reducing response and resolution times for managed accounts. We'll know this is working when we can point to a clear, agreed process and response times for these customers are improving.

4.2 Clarify the boundary between Sales/CS-owned tickets and support-owned tickets

Objective: Create clarity around which tickets should be picked up by support vs. managed by Sales/CS. We'll know this is done when these tickets are handled more efficiently and fewer of these tickets remain breaching (but answered) in the queue.

4.3 Get the team working from their SME queues

Objective: Ensure every support engineer is primarily working from their dedicated SME Zendesk view, with the shared queue as overflow. We'll know this is working when engineers can spend more time on their SME tickets and point to deepening knowledge in their product area.

Handbook

What makes us great

We communicate clearly and don't hide behind jargon. We're relentlessly curious - pulling at every thread when investigating an issue, and seeing the bigger picture beyond the immediate problem. We're always looking for ways to improve, whether that's our processes, our docs, or our own skills. We're thorough without being slow, thoughtful without overthinking, and we genuinely care about getting things right for our users.

Our values

Take ownership

Own your work from start to finish. Be proactive and self-driven. Don't wait to be told what to do. When you see a problem, jump in and solve it. Be resourceful, curious, and hands-on. If something needs doing, figure it out and make it happen. Taking ownership means being accountable for outcomes, not just tasks.

Delight users

Go beyond solving problems. Create moments that make users' days better. Be genuinely caring, reassuringly human, and empathetic in every interaction. Surprise users with your thoughtfulness and responsiveness. Bring positivity and warmth to technical conversations. When users walk away from an interaction with you, they should feel helped, valued, and hopefully a little bit delighted.

Stay humble

Check your ego at the door. Take feedback as a gift and be open to learning from anyone, regardless of their experience level or role. Share knowledge freely with the team and communicate with transparency and honesty. We get better together by staying curious, admitting what we don't know, and helping each other grow. No one has all the answers, and that's okay.

Ship fixes

Be deeply technical and hands-on. Don't just log bugs or pass tickets along - write the fix yourself. Raise PRs for docs improvements, patch code, and solve problems end-to-end. We're engineers who happen to do support, not support agents who escalate to engineers. If you can fix it, ship it. That's what makes PostHog support special.

What we do

We help users through in-app support (which routes to Zendesk), community questions, and Slack channels for enterprise customers. But we don't stop at answering questions:

  • Ship code: We write and merge small bug fixes and improvements ourselves.
  • Improve docs: We contribute fixes, clarify sections, and add missing information.
  • Build internal tools: We create tools like HogHero for internal efficiency, SDK Doctor for proactive customer help, and automations to streamline our work.
  • Share product feedback: We surface patterns and pain points we see from users.
  • Answer community questions: We respond to questions in our community forums.

We provide support Monday through Friday, 9am GMT to 5pm PST. We focus on being consistently excellent during our coverage hours, with clear expectations set for users.

What we don't do

  • Route tickets: We solve problems ourselves rather than passing them along.
  • Hide behind processes: We care more about outcomes than following rigid procedures.
  • Work in silos: We're integrated into product development and actively contribute to company discussions.
  • Accept "that's not my job": If we can help, we do. If we can't, we figure out who can and make the connection.

Our long-term vision

Support should be a competitive advantage for PostHog. Users choose us partly because they know they'll get exceptional support. They stay partly because they feel valued and helped. They recommend us partly because they've had great experiences with our team.

As PostHog grows, we're scaling thoughtfully. We prioritize keeping the team technical, staying true to our values, and maintaining our user-first culture. We value attitude and aptitude over experience - we need people who can jump into the unknown and figure things out. We want to contribute code and build tools, while keeping quality and user-centricity at the core of everything we do.

The benchmark we're aiming for: other companies should measure themselves against PostHog support - not because we answer tickets quickly, but because we genuinely help users succeed.

How we work

We work in bi-weekly sprints, with a sprint planning meeting every two weeks. You can find what we're working on in the company-internal repo, where we put together a planning issue for each sprint.

Like other teams, we plan our goals quarterly. Every goal gets assigned an owner who then puts an issue together outlining some of their ideas and steps towards that goal. These issues go in the Meta repo.

Every week, on Monday morning, we put together a weekly report on the main support metrics for the Blitzscale team, which is posted in the #team-blitzscale Slack channel along with comments from CSAT surveys. The report is put together from the metrics we care about:

Slack channel

Questions about this page? or post a community question.