Back to notes

May 26, 2026 · 5 min read

Restarting a Voice-of-Customer Program That Had Quietly Died

A client's VoC program had been "running" for two years on paper. In practice, nobody had read a survey response in fourteen months. Here's how we brought it back without starting from zero.

ResearchCase Study

The client's VoC program technically still existed — the survey was still sending, responses were still landing in a dashboard, the subscription was still being paid for. What had died was the loop between a response coming in and anyone acting on it. Fourteen months of open-text feedback had accumulated with zero tagged themes and zero summaries sent to a single stakeholder.

Why it died quietly instead of loudly

Nobody made a decision to kill it. The person who used to summarize responses weekly left the company, the task wasn't reassigned, and because the survey kept technically running, nobody noticed it had stopped functioning. This is the common failure mode for VoC programs — they don't get cancelled, they get orphaned.

A survey that's still collecting responses nobody reads isn't a dormant program, it's an active liability with a dashboard attached.

What we didn't do

We didn't relaunch with a new survey tool or a new question set — the existing questions were fine, and starting over would have lost fourteen months of comparable trend data. We fixed the loop instead: assigned a named owner for a biweekly theme summary, built a lightweight tagging pass over the backlog using a simple LLM-assisted classifier to bucket the open-text responses into themes, and set up a recurring fifteen-minute readout to the product team.

  • Named owner for the readout, not a rotating responsibility.
  • A fixed cadence short enough that skipping it is obviously noticeable.
  • A backlog triage pass instead of discarding historical data.
  • One visible metric — number of themes acted on per quarter — to prove the loop is closed, not just running.

Within two months the product team had already shipped one small fix directly traceable to a theme surfaced from the backlog. That single win did more to keep the program alive than any amount of process documentation would have.