Review survey findings in PostHog Desktop

Contents

Open beta

PostHog Desktop is in beta. This page is a work in progress.

PostHog Desktop is where you read the Self-driving reports your survey responses produce. A dedicated scout watches your active surveys, and when it finds something real – a score regression, an abandonment spike, or a theme several people keep raising – it files one report and routes it to a named human reviewer.

Unlike error tracking, this scout stops at the report. It doesn't open a draft pull request – see why below.

How feedback becomes a report

Surveys are direct user voice, so the bar for a report is deliberately high: a handful of converging open-text answers can outweigh a much larger analytics signal, but a wobble in a small NPS sample is not a report.

  • Recurring themes – open-text answers clustered into one finding. Five people describing the same checkout step becomes a single report with a few verbatim quotes attached, not five you never read.
  • Score regressions – NPS, CSAT, and rating drops measured against that survey's own baseline, with small samples held to a tighter bar than large ones.
  • Response-volume drops and abandonment spikessurvey dismissed rising as a share of survey shown, or impressions stepping away from their usual range.

Every report names the surveys and questions behind it, the response counts, and the score deltas, so you can judge the finding against its own sample rather than taking it on trust. A theme the inbox already covers gets the new responses appended to the existing report instead of being filed again, so a problem that keeps coming up stays one item.

Why there is no pull request

A survey finding is user sentiment, not a defect with a known fix. Someone telling you checkout felt confusing doesn't tell you whether the answer is different copy, a different flow, a different price, or nothing at all. That's a product decision a person has to make, and it's rarely a mechanical code change a coding agent could make on its own.

Survey responses are also personal data, and the cost of getting a "users hate feature X" report wrong is high. So the scout is built to hand you an investigation with the evidence attached and a reviewer already assigned, and to stop there. Other signal sources, like error tracking, do open pull requests.

What you can do here

  • Read the report – the theme or regression, the survey and question it came from, the response counts and score deltas, and the replays and events behind the feedback.
  • Ask questions – start a research task against the report to dig further before you decide anything.
  • See the history – a theme that keeps recurring is one report with each run appended, so you can tell whether it's growing or fading.
  • Decide what happens next – change the product, rewrite the copy, ask a follow-up question, or mark it as expected. Nothing happens until you decide.

Community questions

Was this page useful?