Customer Experience

What is the job to be done?

"When a customer tells us something is broken, we see the whole story in one place, fix it, and ship the fix, without bouncing between multiple tools or wasting engineering time trying to reproduce it."

• Give support one inbox for every customer conversation, with the sender's session, events, and errors already attached
• Build a repeatable debugging workflow where support, product, and engineering share the same context
• Give support teams the ability to see what actually happened, not just what the user reported
• Connect technical debugging (errors, logs) to user behavior (replay, analytics) and satisfaction signals (NPS, CSAT)
• Trace AI-powered workflows end to end when things go wrong
• Turn recurring tickets into shipped fixes instead of a growing backlog

Most companies don't have a customer experience system. They have tickets in one place, errors in another, logs somewhere else, analytics owned by product, and engineers manually trying to reproduce bugs. The goal of this use case is to collapse that into one workflow, where the conversation, the evidence, and the fix live in the same platform.

Support is what makes this a system rather than a collection of tools. It's our customer support product — a chat widget, a shared inbox, and email, Slack, and GitHub channels — and because PostHog already captured what happened in the product, each ticket arrives with the sender's session replay, recent events, and exceptions attached.

You can sell this use case without moving their helpdesk. Plenty of good-fit accounts have a helpdesk they aren't replacing this quarter, and the use case still works: they keep tickets in Zendesk or Intercom, and PostHog becomes the context and debugging layer their agents open alongside it. Their helpdesk is also already a self-driving signal source, so recurring tickets can become PRs without moving the inbox at all. Lead with Support where the helpdesk is in play, and lead with Session Replay where it isn't.

What PostHog products are relevant?

• Support (core) — One inbox for every customer conversation, whether it arrives from the in-app widget, email, Slack, or GitHub issues. Each ticket carries the sender's session replay, recent events, exceptions, and previous tickets. Statuses, priorities, assignment, tags, private notes, and saved views. The core — widget, inbox, all channels, workflow automation, and imports — is free with no per-seat charge.
• Session Replay — See exactly what the user did, not what they think they did. Capture console logs and network calls alongside the visual recording. Widget tickets attach the customer's session automatically, so replay is one click from the conversation.
• Error Tracking — Capture frontend and backend exceptions tied to users and releases. Exceptions from the customer's session surface directly on the ticket, and you can see whether other users hit the same issue.
• Product Analytics — Understand what a user was trying to do before something broke. Identify patterns in drop-offs, error frequency, and issue clustering across users or accounts. Support emits $conversation_ticket_created and related events, so ticket volume is queryable next to product behavior.
• Group Analytics + Person Profiles — Give support and CS a clean, holistic view of a user or account. Tickets link by distinct ID, so a ticket, a person, and an organization are the same object across products.
• Workflows — Rules the customer controls, with no autonomous AI involved: set SLAs by channel or priority, auto-assign by customer email domain, auto-tag, reopen on customer reply, escalate. This is how a growing support team keeps the inbox sane.
• Logs — Inspect structured backend logs connected to the same user session. When replay and error tracking show what happened on the frontend, logs show what happened on the server, and a log line links straight back to the replay it came from.
• AI Observability — See prompts, outputs, latency, and token usage for AI-powered workflows. When an AI feature misbehaves, trace it back to the specific generation.
• Surveys — Capture frustration signals (NPS, CSAT) and tie them directly to broken flows. When someone leaves a low score, you can click through to their session and see what went wrong.
• Experiments — Validate that fixes actually improved the experience. After resolving a class of issues, measure whether user satisfaction and completion rates improved.
• Replay Vision — The support-scale version of session replay. Instead of a human watching recordings one at a time, a scanner reads all of them and tags what happened: task completed, abandoned, blocked by an error. For a support team, that turns "we think a few customers hit this" into a number. Findings land as queryable events.
• self-driving — Support conversations, error tracking, session replay, and logs are all signal sources, and external helpdesks (Zendesk, Front, Intercom-likes, Gorgias, Plain) can feed the same inbox. A recurring ticket theme becomes an investigated report with a pull request, so the fix happens instead of the ticket being closed with a workaround.

Adoption path and expansion path

Entry point

Usually Support or Session Replay. Common entry scenarios:

1. "We pay per seat for a helpdesk and our agents still can't see anything": They have a helpdesk but no product context, so every technical ticket becomes an engineering escalation. Support is the direct answer, and the consolidation math is easy.
2. "We can't reproduce bugs": Support needs to see what happened instead of relying on screenshots and user descriptions. Session Replay is the direct answer, whether or not tickets move.
3. "We don't have a support tool yet": Early-stage teams running support out of a shared Gmail inbox or a Slack channel. Support's widget plus the email and Slack channels replaces the mess, for free.
4. "Something is breaking but we don't know why": Product notices drop-offs or support volume spikes and needs visibility into what's causing them. Product Analytics surfaces the pattern, Session Replay provides the detail.

Primary expansion path

Support → + Session Replay → + Error Tracking → + Logs / AI Observability → + Surveys → + self-driving

The logic of each step:

• Support → Session Replay: The ticket tells them what the customer said. Replay shows what actually happened. This is the highest-value connection in the use case, and it's the reason Support is worth switching to.
• Session Replay → Error Tracking: Seeing something break visually isn't enough. They want structured, queryable errors tied to users and releases, surfaced on the ticket. Error Tracking makes debugging systematic instead of ad hoc.
• Error Tracking → Logs / AI Observability: Now they want to see what happened server-side or inside AI workflows. Logs provide backend context. AI Observability traces AI-specific issues (hallucinations, prompt regressions, latency spikes).
• Logs / AI Observability → Surveys: After stabilizing debugging, they want to detect frustration from users who never file a ticket, and measure whether reliability improvements are being felt. Surveys close the feedback loop.
• Surveys → self-driving: They're resolving tickets fast but seeing the same issues recur. Recurring conversations become investigated reports with pull requests, so the fix ships instead of the ticket being closed with a workaround.

This expansion happens naturally because each step removes a layer of uncertainty, then removes a layer of work.

Alternate expansion paths

The helpdesk stays where it is (the complement motion). They aren't replacing Zendesk, Intercom, or Front this year. Sell the context layer instead: Session Replay, Error Tracking, Group Analytics, and Person Profiles, with agents pasting replay links into their existing tickets, plus their helpdesk wired up as a self-driving signal source. Land it, prove the resolution-time win, and revisit Support when their helpdesk contract comes up. Note that the Zendesk import is a one-time historical backfill in open beta, not live two-way sync — don't promise a hybrid steady state for the Support inbox itself.

Starting from Session Replay as a replacement for another session recording tool. They adopt Session Replay to replace Hotjar, FullStory, or LogRocket. Expand by introducing autocapture (Product Analytics), Error Tracking for structured bug data, Group Analytics for account-level views, and then Support once support is already living in PostHog day to day.

Starting from GitHub issues. Dev-tool and infra companies where "support" is really an issue tracker. The GitHub channel turns issues into tickets with two-way comment sync, which gets Support adopted without changing anything for their users.

Business impact of solving the problem

Engineering time savings. If bug reproduction drops from 2 hours to 30-60 minutes, teams get fewer context switches, fewer escalations, and more roadmap velocity. Even modest improvements here can justify the cost of the PostHog contract.

Escalation reduction. When support can view replay, check errors, and inspect logs from inside the ticket, they resolve more issues without pulling in engineering. That means the roadmap doesn't stall and customer response times improve.

Helpdesk cost consolidation. Per-seat helpdesk pricing is one of the easier line items to attack. Support's core is free with no per-seat charge, so a growing support team stops paying more every time it hires. Combined with replacing a separate replay tool and a separate error tracker, this is often the clearest hard-dollar case in any use case we sell.

Fixes actually ship. The usual failure mode is the same ticket coming back because nobody prioritized the underlying bug. Recurring conversations become investigated reports with PRs, which converts support volume into product improvement.

Revenue protection. When enterprise customers report issues, speed and clarity matter. Being able to say "here's exactly what happened and here's the fix" builds trust. Slow, unclear debugging erodes it.

AI risk mitigation. For AI-powered products, AI Observability catches the things that would otherwise go unnoticed: hallucinations that are hard to trace, prompt regressions, and latency spikes. Without it, product credibility degrades quietly.

Personas to target

Signals in Vitally & PostHog

Vitally indicators this use case is relevant

PostHog usage signals

Health score implications

• Event volume: Should stay relatively similar (this use case doesn't fundamentally change event instrumentation)
• User engagement: More users spending more time in PostHog (support, CS, and product teams joining engineering). Support is a daily-active surface for agents, which makes it one of the stickiest things we can land.
• Product count: Should drive adoption of Support, Error Tracking, Group Analytics, Logs, Surveys, and more

Command of the Message

Discovery questions

• Where do customer conversations land today, and what does that tool cost you per seat?
• How do you currently investigate a reported issue? Walk me through the workflow.
• When a ticket comes in, what does your agent already know about that customer, and what do they have to go ask for?
• How long does it take to reproduce a bug reported by a customer?
• How many tools do you open to debug one ticket?
• Can support see backend errors or do they escalate everything to engineering?
• What percentage of your tickets are the same handful of issues coming back?
• Can you trace an AI output back to its prompt and context?
• When someone leaves a low NPS score, can you see what went wrong in their session?
• How do you confirm that a fix actually worked for the users who were affected?

Negative consequences (of not solving this)

• Paying per seat for a helpdesk that can't tell agents anything about what the customer was doing
• Engineering time wasted on reproduction instead of shipping
• Constant escalations and interruptions from support to engineering
• The same bugs generating tickets month after month because nobody closed the loop back to code
• Enterprise deals slowed or lost due to reliability concerns and slow issue resolution
• AI features degrading silently with no visibility into output quality
• Customer frustration that shows up only at churn, not when it's actionable

Desired state

• Every conversation lands in one inbox, with the customer's replay, events, and errors already attached
• Support shares one link (replay + errors + logs) and engineering has full context in seconds
• Engineers see replay + errors + logs without switching tools or asking "can you try that again?"
• Support resolves technical tickets without escalating, because the evidence is already in the ticket
• SLAs, routing, and tagging are handled by rules the team controls, not by manual triage
• AI output is traceable end to end: prompt, context, output, user reaction
• Recurring issues turn into reviewed pull requests instead of a backlog nobody grooms
• Fixes are validated against real user behavior, not just "it works on my machine"
• Frustration signals (low NPS, rage clicks) are visible immediately and tied to specific sessions
• Debugging becomes fast, predictable, and systematized

Positive outcomes

• 30-70% reduction in debugging time (reproduction to resolution)
• Fewer escalations from support to engineering
• Helpdesk seat costs removed from the stack
• More roadmap velocity (engineering spends time building, not debugging)
• Recurring issues actually get fixed, so ticket volume trends down
• Higher customer trust through faster, more transparent issue resolution
• Clear signal when users are frustrated, tied to exactly what went wrong

Success metrics

Customer-facing:

• CSAT/NPS improvement tied to faster issue resolution
• Mean time to resolution (MTTR) and first-response time decrease
• Reduction in support-to-engineering escalation rate
• Reduction in repeat tickets for the same root cause
• Helpdesk seat spend eliminated

TAM-facing:

• More active users in PostHog (support, CS, product teams joining engineering)
• Multi-product adoption growth (Support + Session Replay + Error Tracking + Logs + Surveys)
• Ticket volume in Support growing, with replay and error context attached
• Session Replay usage increasing as debugging workflows mature

Competitive positioning

Our positioning

• The conversation and the evidence in one place. Every other helpdesk is a text box with a CRM attached. Support ships with the customer's session replay, events, and exceptions on the ticket, because the same platform captured them. No integration to configure, no sampling gaps, no "can you send a screenshot?"
• Unified visibility stack. Tickets, behavior, replay, errors, logs, AI observability, and surveys tied to the same user. Click from an NPS score to a session replay to an error to a log line to the conversation. No other platform connects all of these.
• The loop closes in code. Recurring conversations become investigated reports with pull requests the team reviews and merges. Helpdesks generate tickets; we generate fixes.
• Developer-first tooling. Built for teams that want control, not black-box dashboards. HogQL, API access, a JS API for building a fully custom widget, and a transparent data model.
• Consolidation play, with real dollars. Replace a helpdesk + Hotjar + Sentry + separate logging + survey tool. Support's core is free with no per-seat charge, so the savings grow as their support team grows.

Where we are strongest: We win when teams want the conversation and the technical context in one place, when engineering and product work closely with support, when their helpdesk is priced per seat and their team is growing, when AI is part of the product, and when speed and simplicity matter more than enterprise ceremony.

Where we are weaker: We're not the right fit when they need a mature enterprise CX suite (advanced routing, omnichannel voice, a knowledge base and self-serve help center, CSAT surveying built into the ticket flow), when mature distributed tracing, profiling, or infrastructure monitoring is required, when enterprise ITSM workflows (ServiceNow, Jira Service Management) dominate the support stack, or when security policies prohibit session replay. In those cases, sell the complement motion: keep their helpdesk, add PostHog as the context layer.

Competitor quick reference

Where PostHog stands: Our strongest position is against product-led companies already using PostHog for analytics or feature flags who are paying separately for a helpdesk and a replay/debugging tool. Consolidating removes two line items, and Support's free core removes the usual "another line item" objection. We're weaker against teams who bought Zendesk or Intercom for the parts we don't have yet — help center, advanced omnichannel routing, a mature AI resolution agent — and against teams with deeply embedded ITSM workflows (ServiceNow, PagerDuty integrations) or teams that need enterprise-grade distributed tracing. Our sweet spot is companies where engineering, product, and support are closely aligned and want one platform for the full loop from conversation to fix.

Pain points & known limitations

Exceptions / edge cases:

• Healthcare/regulated with strict PHI requirements: Session replay may require significant masking configuration or may not be feasible. Recommend focusing on Support + Error Tracking + Logs + Analytics without replay, or ensure their compliance team reviews PostHog's privacy controls and HIPAA BAA (available with Boost package).
• Large enterprise with ServiceNow-centric workflows: If their entire support operation routes through ServiceNow with complex escalation rules, PostHog is a complement (providing the debugging context), not a replacement for their ITSM platform.
• High-volume consumer support with omnichannel requirements: If they need voice, SMS, and a large agent pool with skills-based routing, Support isn't there yet. Sell the context layer and keep the door open.

Getting a customer started

What does an evaluation look like?

• Scope: Turn on the Support widget on their primary application and connect one more channel (usually email). Enable Session Replay and Error Tracking so tickets arrive with context. Set up Person Profiles so support can look up individual users. Optionally run the Zendesk import to bring history across.
• Timeline: Under a day to have the widget live and tickets flowing. 1-2 days to start capturing replays and errors. 1 week to have enough data for support to work real tickets end to end in PostHog.
• Success criteria: When a ticket arrives, can the agent see the customer's session, recent events, and errors without leaving the ticket? Can they resolve a technical issue without escalating? Can engineering pick up an escalated ticket with full context? Is first-response time at least as good as their old tool?
• PostHog investment: Support's core (widget, inbox, all channels, workflow automation, imports) is free with no per-seat charge. Session Replay free tier covers 5K recordings/month. Error Tracking free tier covers 100K exceptions/month. Product Analytics free tier covers 1M events/month.
• Key requirement: They need the PostHog SDK integrated with user identification so tickets, replays, and errors are tied to specific users. If they're already using PostHog, this may just require enabling Support, replay, and error tracking. For logged-in users, walk them through Support's identity verification so tickets persist across devices.

Onboarding checklist

• Enable the Support widget on the primary app, with identity verification configured for logged-in users
• Connect at least one more channel: email, Slack, or GitHub
• Enable Session Replay with user identification so tickets attach the customer's session
• Enable Error Tracking in the SDK configuration so exceptions surface on tickets
• Set up Person Profiles so support can search for individual users
• Configure privacy controls for any sensitive fields (forms, PII)
• Set up Workflows for SLAs, auto-assignment, tagging, and reopen-on-reply
• Agree on ticket statuses, priorities, and saved views with the support team
• Run the Zendesk import if they're migrating history (org admin required)
• Walk support through opening a ticket and using replay, events, and exceptions (training session)
• Build a "Customer Health" dashboard: ticket volume by account, error trends, replay volume, NPS scores
• Set up alerts for error spikes or new error types
• Enable Logs for backend context alongside replays, and show the log-line-to-replay link
• If applicable, connect Surveys (NPS/CSAT) and tie responses to session data
• Once tickets are flowing, enable Support as a self-driving signal source and review the first reports together

Objection handling

Cross-sell pathways from this use case

Internal resources

• Support docs: Support · Get started · Inbox · Widget · Channels · Workflows · Pricing
• Support migration: Imports · Zendesk import
• Session Replay docs: Session Replay
• Error Tracking docs: Error Tracking
• Product Analytics docs: Product Analytics
• Person Profiles docs: Persons
• Group Analytics docs: Group Analytics
• Surveys docs: Surveys
• AI Observability docs: AI Observability
• Logs docs: Start here · Link to session replay
• Replay Vision docs: Overview · Quota and limits
• self-driving: How to pitch self-driving · Signal sources
• Privacy controls: Session Replay Privacy
• PostHog AI docs: Enable PostHog AI · Example prompts
• How we do support ourselves: Support team — we're migrating off Zendesk onto this product, so our own experience is the reference story
• Competitive battlecard: To be added: Zendesk / Intercom / Front / FullStory / LogRocket / Hotjar competitive positioning

Appendix: Company archetype considerations