Does PostHog Conversations Replace a Dedicated Feedback or Helpdesk Tool?
Not yet, for most teams. PostHog's Support product, built by a team the codebase and API still call Conversations, is a genuine support inbox. An in-app widget, inbound email, a Slack bot, and GitHub issues all land as tickets in one place, each one auto-attached to the session replay and events around it, and it can import your ticket history from Zendesk. But the import pipeline is young enough that PostHog's own engineers were filing tech-debt tickets against it on August 31, replies still can't carry a Cc or an attachment, and there's an open bug where a customer's own ticket list can hide dozens of their tickets. If you're running Zendesk or Intercom for support today, plus something separate that turns feedback into a prioritized, deduped backlog, nothing in Conversations' current state gives you a reason to drop either.
That's a different question from "is Conversations any good," which is a fairer one and mostly yes for what it's built to do. It reduces the reproduction tax on a support team by handing an agent the replay and the error alongside the ticket. It's a helpdesk feature. It was never trying to be the tool that clusters "checkout is broken" across Slack, email, and a sales call into one counted theme with a requester list, and Conversations doesn't touch that job.
What Conversations actually is
PostHog's docs describe four channels a ticket can come from. The in-app widget auto-attaches session replay, events, and errors. Inbound email lets a team forward support@ and thread replies back to the customer's inbox. A Slack integration called SupportHog turns a message, mention, or emoji reaction into a ticket. Monitored GitHub repos turn an issue into a ticket and post replies back as comments. Tickets also feed PostHog's Self-driving product, where a support conversation can become a "signal," get grouped with related errors into one report, and turn into a draft PR a human reviews.
The product name in the docs is Support, but every other surface still says Conversations. The API endpoint is /api/projects/:project_id/conversations/tickets/, the same path named in a since-fixed API bug from earlier this year, and the GitHub label covering the feature is feature/conversations. Search the codebase or the API docs by the product's public name and you won't find it.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhere it's still being built
A Zendesk historical import does exist. It's a real Temporal pipeline in the codebase, not a rumor, but two engineering tickets filed against it on August 31, 2026 describe a pipeline still being hardened. One notes the importer holds a per-team database lock across each batch of a hundred tickets, so a live ticket created by the widget or Slack while a backfill is running can wait behind it. The other is a refactor to stop threading the same message counts through three functions. Neither is a user-facing bug report; both are the kind of tech debt that shows up in a feature built recently and still moving fast.
The user-facing gaps are more concrete. Two open feature requests, both filed the same day in July, cover basics: agents can't Cc or Bcc anyone on a reply, so looping in a customer's billing contact or an internal teammate without a PostHog account isn't possible yet, and agents can't attach a file to a reply, only inline images, not a real downloadable attachment. A separate, still-open bug reports that Slack message edits don't sync to the ticket. If a customer edits their reply in the connected Slack thread, the ticket keeps showing the original text with no flag that it changed.
The sharpest one is a reported visibility bug where a user's "my tickets" view showed 2 tickets while the API returned 39 unresolved ones for the same person, because tickets opened through the Slack bot attach the requester as an anonymous distinct ID instead of an identified person, and the ticket-list query only resolves identified people. A customer whose renewal-tracking ticket auto-closes from a Slack thread may not be able to find it in the product to reopen it. That's a data-model gap, not a rough edge, and it's still open as of this writing.
Picture what that looks like on the ground: a 20-person field-service scheduling SaaS, call it Vantree, runs a one-week Conversations pilot in a sandbox project, Slack support channel pointed at it, two agents working real tickets there alongside their existing Zendesk queue. The widget and email channels hold up fine, and a ticket that arrives with the session replay already attached saves real back-and-forth. What ends a pilot like that early is exactly this bug: a support lead pulls up a customer's account before a renewal call, the ticket panel shows one open item, and a full API pull shows fourteen, all of them opened through the Slack bot and invisible to the customer too. That's not a new data point, it's the same gap the GitHub issue above describes, just what it costs a team that trusts the panel count over the API. A team in that spot keeps Zendesk as the system of record and checks back once Cc support and ticket visibility land.
Where the native approach stops, and what a dedicated tool does instead
Even once Conversations closes these gaps, it solves a narrower problem than most teams reach for a separate tool to solve. A support inbox, however good, tells you what came in through the channels it owns. It doesn't dedupe a request that showed up as a Zendesk ticket, a Slack message in a customer channel, and a mention on a sales call into one counted theme, and it doesn't attach the person and account behind that theme to a Linear or Jira issue automatically. That's true whether the inbox is Conversations, Zendesk, or Intercom. The gap is structural, not a missing feature one vendor will eventually ship.
That's the point at which teams bring in Modem. Modem's PostHog integration reads product analytics, feature flags, experiments, and error tracking, and Modem separately pulls in whatever helpdesk you actually use, whether that's Zendesk, Intercom, or Conversations once it's further along, plus Slack, email, survey responses, and sales calls, clustering the same request across all of them into one topic with the requester list attached. It doesn't replace your helpdesk. It sits alongside whichever one you keep, and a support inbox and a survey tool both generate raw signal that still needs a place to get counted. That's the same rejoin problem covered in how PostHog's own survey text runs into it. Every seat is included on every plan; the meter that moves is usage past what's included, not a fee for each person who opens a ticket. We build Modem, so weigh the recommendation accordingly. If Zendesk specifically is your helpdesk of record, the options for mining its tickets are compared directly.
The honest recommendation
Keep your current helpdesk. If you're on Zendesk or Intercom and happy with it, Conversations isn't mature enough today to justify a migration. The import pipeline is actively being reworked, replies are missing table-stakes features, and there's an open bug that can hide a customer's own tickets from them. Revisit it in a quarter or two once the July and August issues close out. Either way, the tool that turns support tickets into a prioritized, deduped feedback backlog is a separate job from the inbox itself, and that's true no matter which inbox you land on.
