Voice of Customer

Key Takeaways

- A voice of customer programme is the standing arrangement for reading what customers say and doing something about it. - The feedback you already own beats the feedback you have to go and collect. - Most programmes fail at the last step, where a finding needs an owner. - Maturity is measured by what happens after the analysis, not by how much feedback you gather.

Voice of customer is the practice of collecting what customers tell you, working out what it means, and changing something as a result. The term covers surveys, but the useful part is usually the feedback that already exists: support tickets, reviews, sales calls, cancellation reasons and in-product comments.

A programme is what turns that into a routine. Without one, feedback analysis happens when someone has spare time, which means it happens before a planning cycle and nowhere else.

THE VOC EVIDENCE FRAMEWORK

01

Evidence

Tickets, reviews, calls and comments in customers’ own words.

02

Signal

Themes, volume and severity—enough context to decide what matters.

03

Decision

A named owner, a due date and a decision tied to the evidence.

04

Response

Fix the cause where possible, then tell customers what changed.

A programme becomes useful only when evidence moves through all four parts.

What a programme actually contains

Four things, in order of how often they are missing.

Sources. The channels you read, and the rule for what gets included. Most teams start with surveys because the data is tidy, then discover that tickets and reviews carry the specific complaints.

A taxonomy. The set of themes feedback is sorted into. This is the part that decides whether the programme produces numbers anyone trusts. A taxonomy built from your own feedback describes your customers. A taxonomy borrowed from a template describes somebody else’s.

A cadence. When the analysis is read, by whom, and what decision it feeds. A monthly review that lands two weeks after the planning meeting will be ignored no matter how good it is.

An owner for follow-through. The person accountable for turning a finding into work. This is the step that programmes skip, and skipping it is why so many produce dashboards and no change.

Source

What it is good for

What it misses

Support tickets

Specific, urgent problems in the customer’s words

Only people who bothered to contact you

Reviews and app stores

Unprompted, comparative, public

Skewed to extremes

Surveys

Comparable over time, targeted at a question

What you thought to ask

Sales and churn calls

Reasons behind a decision, with money attached

Filtered through a rep’s summary

In-product feedback

Tied to the moment and the feature

Sparse, and biased to active users

Closing the loop

Closing the loop means going back to the person who raised the issue and telling them what happened. It has two forms, and teams conflate them.

The inner loop is the individual response: someone complained, someone replied, the case is closed.

The outer loop is the systemic one: forty people complained about the same thing, the cause was fixed, and the change was announced. The outer loop is where the value is, and it is the one that requires an owner outside the feedback team.

Maturity, described honestly

Stage one: feedback is read when someone asks a question. Analysis is manual and starts from scratch each time.

Stage two: feedback is categorised consistently and reported on a schedule. Themes have volumes attached, and the numbers survive scrutiny.

Stage three: findings have owners and due dates, and the loop is closed on the systemic issues. Somebody can name a change that shipped because of feedback.

Stage four: the programme is used before decisions rather than after them, and roadmap arguments cite theme volume the way they cite revenue.

Most programmes sit at stage two and describe themselves as stage three.

Who owns it

Ownership sits in one of three places, and each has a failure mode. Under research or insight, the analysis is strong and the follow-through is weak. Under support, coverage of tickets is excellent and product feedback goes unread. Under product, the roadmap gets fed and service problems disappear from view.

The arrangement that works is a single named owner for the programme and a standing agreement that findings route to whoever owns the cause.

What to measure

Measure the programme, not the sentiment. Useful numbers: share of feedback that gets categorised, time from a theme appearing to somebody owning it, number of systemic loops closed in a quarter, and contact volume for the drivers you fixed.

Satisfaction scores measure the business. These measure whether the programme works.

FAQ

The practice of collecting customer feedback from every channel you have, analysing it for themes, and acting on what it shows. It is a programme rather than a survey.

Anything where customers describe their own experience in their own words: tickets, chats, reviews, survey verbatims, sales and churn calls, and in-product feedback. Structured scores are useful for tracking and weak for explaining.

Market research asks people who might buy. VoC reads people who already did. Research is project based; VoC runs continuously.

One named person, senior enough to route findings to teams they do not manage. The function matters less than the authority.

Continuously for categorisation, monthly for review, and aligned to whatever planning cycle the findings are meant to influence.