Voice of customer that explains why

Say your quarterly NPS slides four points and the leadership review is on Monday. Everyone can see the drop; nobody can say why. Voice of customer (VoC) is the standing practice of capturing what customers say, need and expect, analyzing it, and getting it to the teams who can act. This guide covers the sources, the steps, the metrics and the tools, and shows how to get the reason behind a score.

What voice of customer means

You will also see it written as voice of the customer, or just VoC. All three mean the same thing.

A VoC program differs from a one-off study. A study answers one question and ends. A program keeps listening, so you can spot a change early, connect it to a cause and check whether your fix worked. It runs across the business and outlives any one survey.

The idea took shape in product development. Quality function deployment (QFD) is a quality-management process that turns what customers need into design and engineering decisions, and its first stage is the voice of the customer. Abbie Griffin and John Hauser's 1993 study in Marketing Science breaks that stage into three tasks: finding out what customers need, putting those needs into a structure, and deciding which matter most. The same study found a self-selection bias in the satisfaction measures firms commonly used, an early sign that the customers who answer are not always a fair picture of the customers a company has.

The modern practice keeps the discipline and widens the scope from a design project to the whole customer relationship. Customer experience (CX) is the whole experience a customer has with you, and the work of improving it. VoC is the listening part of that work: collecting and analyzing what customers say, so CX teams know what to fix.

VoC also overlaps with customer research, and differs from it in rhythm. A research study answers a specific question at a point in time. VoC is a continuous flow of customer input, read every week and every month. The two work best together. VoC shows where attention is needed, and research explains why and what to change.

An insurer's claims process shows why the wider scope matters. For most policyholders the claim is the first time they use the product they have been paying for, and it is the moment the insurer's promise is tested. It also involves more voices than one customer. The policyholder reports the loss, a third party may be claiming against them, a broker may handle the case for them, and a repair shop deals with the insurer's assessors. Each sees a different part of the process.

The practical difficulty is ownership. In the claims operation, the team that takes the first report of a loss, the assessors, the settlement team, the payments team and the approved repairers each own a piece of what the claimant experiences, and they often report to different leaders. VoC sits across all of them. It needs a way to send each finding to the team that owns the cause, and a way to show that team what its part of the journey looks like from the claimant's side.

That is why the first thing to write down is the decisions VoC should inform, such as which journey to fix first or why renewals fall in one segment. Goals like "understand the customer" are too vague to tell you what to collect.

Where VoC data comes from

VoC data comes from three kinds of source. Direct sources are what customers tell you when you ask. Indirect sources are what they say without being asked. Behavioral sources are what they do. A strong program uses all three, because each covers the others' blind spots.

Start by mapping the listening posts you already have: surveys, support tickets, reviews, sales notes, analytics. Note who owns each and how often anyone reads it. Sources nobody reads are often the cheapest to fix.

The volume in each channel reflects who chose to speak in it. Calls and complaints come mostly from customers with a problem, so they describe pain far more than satisfaction. Reviews lean toward the very pleased and the very angry. None of this makes the sources less useful. It means a count of comments says as much about who chose to speak as about how common an issue is, so a theme's size is checked with a representative question before it goes to leadership.

Counts of coded complaints hide as much as they show, so someone reads the raw material too. An analyst who reads fifty complaints end to end each month, chosen at random, sees what a category label flattens: the claimant who complains about a payment delay but is really upset that nobody explained the excess, or the complaint filed as rude handling that turns out to describe a handler reading a script the claimant could not follow. Those readings sharpen the topics, and they give the analyst the specific examples that make a trend believable.

What customers do is part of their voice too. In a claims operation, a claimant who calls three times in a week to ask where their claim stands is describing a failure of communication, whether or not they use the word. A theme that shows up in both what customers say and what they do is stronger than one that appears in only one.

Frontline staff hear a great deal that no system captures. A quick way to log what they hear, a short tag in the claims system or a two-line form, turns thousands of daily conversations into a source you can read. A short weekly review of those notes, with the most frequent items added to a watch list, keeps them coming and shows staff that someone reads what they write.

These sources become far more useful under one set of topics, applied the same way to calls, complaints, reviews, notes and surveys. Customers who call or complain did not agree to take part in research, so their words are used within the company's privacy notice, and personal details are removed before feedback is shared beyond the team that handled it.

Why scores need reasons

Three survey measures do most of the work in VoC. Net Promoter Score (NPS) asks how likely someone is to recommend you on a 0 to 10 scale, then subtracts the share of 0 to 6 answers from the share of 9 and 10 answers. Customer satisfaction (CSAT) asks how satisfied someone was with an interaction. Customer effort score asks how easy it was to get something done. Frederick Reichheld proposed the recommend question in Harvard Business Review in 2003.

All three are useful for tracking. All three share a limit. Each turns an experience into a number and leaves the reason behind. Nielsen Norman Group's article on NPS makes the same point, that the score shows how an experience is perceived but not why, and adds that grouping answers into three bands ignores much of the information in the ratings. It recommends supplementing the score with lower-level measures, which sit closer to the cause. Showing the shares of promoters, passives and detractors beside the score helps as well, because the same score can come from very different mixes of customers.

Surveys come in two kinds. Relationship surveys ask now and then about the customer's overall view of the company; transactional surveys ask about one interaction shortly after it happens. In claims, the transactional moments are clear: the first report of the loss, the assessor's visit, the settlement offer and the payment. A short survey after each shows which step lowers a claimant's view.

Nielsen Norman Group's guidance on requesting feedback, by Anna Kaley in 2023, suits a journey like this. Ask only after the person has finished a real task, and ask in the channel where the interaction happened. Keep to rating and multiple-choice questions, with an optional open field at the end for anything the customer wants to add, and keep the whole request to about a minute.

A score shows that sentiment moved. It does not show why. A team that only has the number ends up guessing, and teams guess in the direction of what they already believed.

Open-text boxes after a survey help a little. But most customers type a few words and stop, and nobody can ask a follow-up. "Too slow" could mean the app, the claim, the callback or the refund.

Interviews with the customers behind a score supply the reason in their own words. The interviewer can ask what "too slow" meant, when it happened and what they expected instead. Kaley's article divides the work the same way, with feedback used to direct and prioritize in-depth research.

Add follow-up interviews with customers who gave a low or a changed score, and with customers you never hear from. Interviewing only the angriest customers hides the contrast, so include a few satisfied ones.

The practical problem has always been scale. A program that wants reasons every month cannot book a fresh round of calls by hand each time. AI-moderated interviews fill that gap. The customer joins by link, and the AI asks the follow-up questions.

Analyzing feedback into themes with evidence

Group what customers said into themes, and keep the quotes behind each theme. A theme nobody can check is a weak one. A simple test is whether someone can open the passage behind any theme in the readout.

A common set of topics, applied across every source, lets feedback be compared across channels and tracked over time. A first set of topics for a claims operation might have six, each with a few subtopics:

• Reporting the claim: forms, documents requested, first contact.
• Communication: status updates, handler availability, clarity of letters.
• Assessment: assessor visits, repair estimates, specialist reports.
• Settlement: amount offered, explanation of the offer, disputes.
• Payment: speed, method, errors.
• Repair and replacement: approved repairers, quality of work, rental cars.

Open survey answers, call notes, complaints, reviews and transcripts are then coded to these topics, usually with a sentiment. Programs can use natural language processing and AI to find themes in open responses. Automated coding handles volume, provided it is set up with the company's own topics and checked regularly. A monthly check does this: a person codes a hundred randomly chosen comments, and the result is compared with the tool's. If most disagreements fall between communication and assessment, the fix is usually a clearer rule for where a delayed assessor report belongs.

The most frequent topics are not always the most important, so frequency is read beside impact. For each topic, compare the share of detractors among the customers who raise it with the share across all respondents. A topic that one customer in twenty mentions, but mostly detractors, deserves as much attention as a large topic with a mild effect on the score.

Root causes matter more than surface topics. One cause, such as settlement letters that state an amount without showing how it was reached, can produce complaints about the settlement, calls to the handler and angry reviews. Conversations with claimants and handlers usually find that cause faster than the text alone.

Analyze by claim type, channel, region, broker against direct customers and stage of the claim, because an overall trend can hide opposite movements in different groups. Track key topics over time: a sudden rise can point to a new problem, and a steady fall can confirm that a fix worked. Reading competitors' reviews with the same topics shows which complaints belong to the company and which the whole market shares.

The monthly report that carries this is short and repeatable. For each of the five topics that moved most, it shows the count, the change, the share of detractors among the customers who raised it and two quotes chosen to show the range of what was said. A line under each names the owning team and whether an action is under way. Keeping the format fixed lets a claims director read it in five minutes and compare it with last month's at a glance, and it keeps the analyst's own reading separate from the numbers and the words it rests on.

Closing the loop with customers and teams

Closing the loop has two halves. The inner loop goes back to the customer who raised an issue, with a reply or a fix. The outer loop takes the pattern to the team that owns it and gets a decision. A program can close the inner loop every day and still never close the outer one.

In the inner loop, when a claimant gives a low score or files a complaint, someone contacts them, resolves what can be resolved and thanks them for saying so. A call from a senior handler soon after a low settlement score can recover a relationship that would otherwise end at renewal. Giving handlers the authority to fix common problems on the spot, such as reissuing a payment or arranging a callback from the assessor, resolves many issues without escalation. It also leaves the outer loop free to deal with causes.

The outer loop is the response to patterns. When feedback reveals a recurring problem, the company fixes what causes it: a process, a letter, a system, a gap in training. That depends on getting findings to the teams who own the causes. Each topic has an owning team, findings reach that team without anyone having to forward them, and owners meet regularly to review their topics and agree actions.

Give every finding an owner, a decision and a date. Present themes with the customer quotes behind them, because teams act faster on evidence they can check.

Not everything can be fixed at once. Rank the fixes by the number of customers affected, the effect on outcomes such as renewal and complaints, and the effort involved. Share that order with the teams concerned, so each team knows why its topic is waiting.

Then tell customers what changed because of their feedback, through letters, in-app messages, release notes or personal replies. When the company decides not to act on a request, because it conflicts with underwriting rules or would help very few customers, explaining that to the customers who raised it, where it is appropriate, is also a way of closing the loop. Note the reason, so it can be revisited if the evidence changes.

After each change, check whether the related feedback, scores and behavior move. Two intervals are worth timing once each finding carries a date: from the finding to the action, and from the action to telling customers. Tracked across every finding, they show where things slow down. A long first interval usually points to a fix that depends on another team's system or budget. A long second one usually means nobody was asked to write to customers at all. A simple log of each finding, with its date, owner, decision and the date customers were told, gives both intervals without extra work.

How to measure whether VoC is working

Measure two things: the customer outcomes the program is meant to move, and how well the program itself works. Many programs track only the first, which makes it hard to tell whether the program helped.

Goal metrics are the customer outcomes. Typical ones are retention, satisfaction by journey stage and customer effort on key tasks.

Program metrics show whether the machinery works. Track the time from a signal to a decision, the share of findings that led to an action, and the share of loops closed with customers and with internal teams.

Be careful about credit. If satisfaction rose after a fix, say the rise coincided with the fix unless you ran a test that isolates it. A before-and-after comparison on the affected journey, with an untouched journey as a check, is a fair middle ground.

Keep the outcomes you control apart from the ones you don't. A claimant whose claim was refused will usually score the experience low whatever the process did, and folding those scores into the total can hide improvements elsewhere, or blame a process for an outcome set by the policy wording. Survey declined claimants separately, ask them about the parts of the experience the insurer controls, such as how clearly the decision was explained and how long it took, and report their results on their own line.

Check who answers, too. If claimants with small property claims answer at twice the rate of those with large motor claims, weight the results or report each group separately, so the picture is not set by the customers most willing to answer.

Connecting VoC to business outcomes gives it a case for budget. If claimants who waited more than two weeks for a settlement offer renew at a lower rate than those who received one sooner, and a change to the assessment step shortens the wait, the renewal rate of the next group of claimants is the measure the finance team will look at.

Coverage deserves a check of its own. Pick twenty claims closed in the past quarter at random and ask what you hold from each claimant: a survey answer, a coded call, a complaint, an interview, or nothing. If most of the twenty left no trace, you are hearing from a self-selected minority. The next source to add is the one that would have caught the silent claimants, often a short text at payment.

Once a year, review the program as a whole. Check which sources earned their place, which decisions the program changed and which questions it still cannot answer. Retire what nobody uses, and add questions where the journey itself has changed since the last review, such as a new claims app or a new way of paying out. Keep word for word the questions that year-over-year comparisons depend on, and write down every change, so anyone reading a trend knows where a question changed.

Time the review to finish before the annual planning cycle begins. A theme that has lasted four quarters then goes into next year's plan with its quotes, its cost and its trend, while the budget to fix it is still being divided.

Choosing the tools

Choose tools by what each one adds to your program. Most programs end up with a survey or feedback suite, an analytics tool and a way to run interviews. The question is how well they cover your sources and how traceable the findings are.

An interview platform works beside a survey or feedback suite. The suite tells you where and how many. The interviews tell you why, and they should feed the same place your team reads findings. Ask, too, how findings leave each tool: whether themes, quotes and transcripts can be exported or sent to where the team already reads, so the evidence is not trapped where only one team looks.

Data privacy deserves its own check. Feedback carries names, account details and health or financial information. Ask how personal data is redacted, who has access by role and whether the vendor trains AI models on your data.

Before buying anything new, map where feedback lives today and who reads it. Connecting what already exists often brings the first gains, and it shows which of the criteria above matter most for your sources.

Start narrow. In claims, that could mean one stage first, settlement, with its complaints, handler notes and post-settlement survey read together and one team to send findings to, before the other stages join. A narrow start keeps the topics and the routing simple enough to get right, and it shows what the next stages will need from the tools.

The tools also need people who can use them. The work calls for survey and interview design, text analysis, data integration and reporting, and someone able to persuade other teams to act. A small team can borrow the first four from research, analytics and operations, but the last has to sit with the person who owns VoC. That owner often sits in customer experience, research or operations, with a sponsor in leadership who backs them when a team is slow to act on a topic it owns.

An insurer explains a falling score

Say an insurer's claims team sees satisfaction with the claims journey fall two quarters in a row. The business question is which part of the journey to fix first, with budget for one change this year.

The team checks its existing sources first. The survey confirms the drop and shows it is sharpest after the first payment. Support tickets mention delays, but tickets come mostly from customers who are already upset. Journey data shows a longer wait between claim approval and payment.

Each source establishes part of the picture. The survey sizes the drop. Tickets suggest a theme. Journey data shows where time went. None of them says what customers expected, or whether the wait itself is the problem or the silence during it.

So the team adds interviews with customers who scored the claim low and a few who scored it high. Whom to interview deserves thought. Talking only to unhappy claimants shows what they went through, but it cannot show what is different about their claims. The contrast with satisfied claimants does: if both groups describe the same wait, the cause may lie in what nobody told them during it.

Where consent allows, each conversation is read beside the claimant's other feedback: their survey scores, their contact history and the claim's own timeline. A claimant who gave the claim a low score and called four times in ten days might explain that nobody said the payment was waiting on a final check. She has told the insurer which step failed, why it felt worse than it was and what a single message would have prevented.

Brokers need a guide of their own. A broker who handled many claims last year can compare the insurer with the others it places business with, stage by stage, which no single claimant can do. But a broker's account is also shaped by commercial interest and by the clients who complained loudest. Asking about the last two claims the broker handled with the insurer, and the last one with another insurer, keeps the conversation on events rather than impressions.

The team weighs the themes from those interviews, each traced to its transcript, alongside the journey data. The next decision, whether to speed up payment or add status updates, rests on what customers said they needed.

A round like this can run on Pulse, with the customers behind a score invited from the insurer's own list, or people recruited to a profile, and fraud checks on every participant. Customers take the AI-moderated interview by opening a link on a phone or laptop, with no call to schedule. When the moderator follows up, it draws on what the customer said earlier in the conversation, and when an answer is vague it asks a second question, so "too slow" becomes a specific reason. Surveys run alongside the interviews in the same study, so the number and the reason arrive together, and every quote in a theme links to its transcript. Programs that span markets can run interviews in 240+ languages, enabled on request. Each study is kept in the Insights library, queryable across projects, so the next time the score moves, the team starts from what customers already told it.