Voice of customer (VoC) examples are the words, observations and ratings customers provide about their needs and experiences. A useful example preserves what the customer said, explains the situation and connects the evidence to an action the team can investigate.
This guide covers seven ways to collect that evidence, with sample wording, follow-up questions and possible actions. It also includes a voice of customer table and a copyable feedback record. All customer quotes and cases below are fictional illustrations, not testimonials or documented company results.
What counts as voice of the customer?
A support message, survey comment, interview answer, public review or observed struggle can all contribute to VoC. A customer’s rating can show their assessment; their explanation helps identify the need behind it. A team must distinguish the evidence from its own interpretation.
For example, “Add a bigger export button” is a proposed feature. The underlying need might be “I need to find the export action while completing a report.” Ask about the task before assuming the requested design is the only solution. ASQ’s voice of customer guidance describes collecting feedback from multiple channels and translating statements into customer needs.
VoC does not mean treating every comment as representative of the customer base. Record who provided the feedback, when and in which context. Look for corroborating evidence while preserving unusual but important problems, such as a barrier that prevents a customer from completing an essential task.
Seven voice of customer examples
1. NPS survey comment: learn why the customer gave the rating
NPS collects recommendation likelihood on a zero-to-ten scale. Bain’s NPS calculation subtracts the percentage of detractors, who score zero to six, from the percentage of promoters, who score nine or ten. Ratings of seven or eight are passives. The score is a summary; a follow-up comment provides context.
Fictional example: a customer gives a score of six and writes, “The product works, but I need help every time I set up a new teammate.”
Follow up: ask the customer to describe the last setup attempt, where they needed help and what happened next. Record their role and the setup steps involved.
Possible action: review the invitation and permission workflow, then test clearer instructions or interface changes. Track whether new users can complete setup with less assistance. Do not label every low recommendation score a support failure; pricing, product fit and other experiences may also influence it.
2. Journey-map feedback: connect the comment to a stage
A journey map places feedback along a customer’s experience, such as sign-up, onboarding, routine use and renewal. It helps show where an issue occurs and which team owns the next step. Use evidence from the specific segment you are mapping.
Fictional example: during onboarding, a new account administrator says, “The confirmation email arrived, but I did not know what to do after signing in.”
Follow up: ask what the administrator expected to accomplish first and which screen they saw. Compare their account’s starting state with the documentation.
Possible action: investigate the handoff between the confirmation email and the first task. Test a clearer next-step prompt with new administrators. Use our customer journey mapping template to organize stages, evidence and ownership; do not fill the map with assumed emotions presented as observed facts.
3. Social listening: investigate unsolicited feedback
Social posts and forums can reveal questions customers do not bring to support. Monitor the product name and relevant task terms, then check whether a post concerns your product, the current version and the customer’s actual use. Public mentions can include jokes, speculation or duplicated complaints.
Fictional example: a forum post says, “Does anyone know if this report saves automatically? I keep taking screenshots before closing it.”
Follow up: investigate the save behavior and visible confirmation for the relevant workflow. If you engage publicly, answer the question and move private account details into an appropriate support channel.
Possible action: test whether the saved state is clear and whether help content explains it. Automated sentiment labels can help sort messages, but review the original wording before interpreting uncertainty as anger or treating a viral repost as another independent customer.
4. Post-interaction CSAT: distinguish the answer from the experience
CSAT asks about satisfaction with a defined experience, such as a completed support interaction. In a common five-point calculation, four and five count as satisfied; satisfied responses divided by valid responses gives the percentage. Qualtrics explains the scoring method. Keep the question, scale and survey timing consistent.
Fictional example: a customer rates a support interaction two out of five and writes, “The answer was correct, but I had to explain the same problem to three people.”
Follow up: review the transfers and conversation history. Ask what information the customer repeated and whether the next agent could see it.
Possible action: improve the handoff note or ownership process, then review repeat explanations and satisfaction with similar cases. The comment points to an experience problem; it does not automatically show that the final answer was wrong. Our CSAT calculation guide covers denominators and worked examples.
5. Advisory board or focus group: understand the workflow behind a request
An advisory board provides ongoing input from selected customers; a focus group brings participants together to discuss a defined topic. Both can generate detailed explanations, but their selected membership and group dynamics limit conclusions about all customers.
Fictional example: in a customer discussion, an operations manager says, “Before approving a change, I need to see who changed the setting and when.”
Follow up: ask for a recent approval example, which records the manager needed and how they found them. Invite other participants to describe their own process rather than agree with the first speaker.
Possible action: clarify the audit-history requirement and check whether the current workflow meets it. Validate the finding with additional users from the relevant roles. A request from a large customer can be important without representing every segment.
Prepare a discussion guide and use open, neutral questions about actual experiences. GOV.UK’s interview guidance recommends a tested structure, follow-up questions and attention to real examples. Explain how notes or recordings will be used, obtain the appropriate participant agreement and store research material with controlled access.
6. Support interaction analysis: turn recurring problems into evidence
Support messages can expose repeated friction without another survey. Define the issue categories, review a sample for consistent tagging and connect messages about the same underlying problem. Include unresolved and escalated cases as well as successful ones.
Fictional example: a ticket says, “I exported the file twice because nothing appeared after I clicked Download.”
Follow up: collect the steps, browser, time and expected result, then verify what happened. Determine whether the request failed, completed slowly or provided an unclear completion message.
Possible action: investigate status feedback or a software defect based on the evidence. A customer’s description is important context, but “nothing appeared” alone does not establish a root cause. Use a bug report template when the evidence points to a reproducible defect.
An optional recording can help demonstrate a sequence that is difficult to describe. Ask the customer to show a safe example and avoid private information. Preserve a written summary so the finding remains understandable without watching the entire recording.
7. Online reviews: separate a public rating from the specific need
Reviews can reveal recurring complaints or strengths. Capture the relevant text, date, product context and source reference. Analyze the written reason alongside the rating, and distinguish a review of your service from feedback about a reseller or another product.
Fictional example: a review says, “The app is easy to use, but I could not find weekend support when our rollout got stuck.”
Follow up: check the published support hours, the customer’s plan and the instructions available outside those hours. Confirm what the review can establish before changing staffing.
Possible action: clarify service coverage and the escalation route, then investigate whether the affected customer segment needs a different service model. Public reviewers are self-selected; their rating average is not interchangeable with your post-interaction CSAT survey.
Voice of customer table: statement, need and next action
This table summarizes the fictional examples above. The need column is an interpretation to validate, not an additional quote from the customer. Keep the original evidence available to the reviewers who need it.
| Source | Illustrative customer statement | Need to validate | Next action |
|---|---|---|---|
| NPS comment | I need help setting up a teammate | Complete setup independently | Review the last setup attempt |
| Journey feedback | I did not know what to do after signing in | Understand the first useful task | Test the onboarding handoff |
| Social post | Does the report save automatically? | Know that work has been saved | Check save-state feedback |
| CSAT comment | I explained the problem to three people | Continue support without repeating context | Review transfers and handoff notes |
| Customer discussion | I need to see who changed a setting | Verify changes before approval | Validate the audit-history workflow |
| Support ticket | Nothing appeared after Download | Know whether an export completed | Reproduce the task and inspect status |
| Online review | I could not find weekend support | Understand available help during rollout | Check coverage and escalation guidance |
Copyable voice of customer template
Feedback ID: [Internal reference] Source / date: [Channel and date] Customer segment / role: [Relevant context] Journey stage / task: [What the customer was doing] Original statement or observation: [Exact words or factual notes] Record reference: [Restricted link where appropriate] Rating, if any: [Question, scale and answer] Need to validate: [Your interpretation, separate from the evidence] Follow-up question: [What remains unclear] Related evidence: [Other cases or research] Issue category: [Defined tag] Impact: [Task blocked, delayed or made harder] Owner / next action: [Responsible team and investigation] Review date: [When to check progress] Decision: [Action, investigation, deferred or declined with reason] Customer update: [What was communicated and when] Outcome evidence: [What changed and how it was checked]
When quoting a real customer internally, preserve their meaning and label paraphrases. When publishing feedback externally, use the appropriate permission and attribution process. Never turn sample wording into a supposed testimonial or substitute a generated quote for a real customer’s evidence.
Build a feedback loop that leads to decisions
- Capture context: retain the original statement, task and source.
- Clarify the need: ask about the experience behind the request.
- Connect related evidence: group issues consistently and avoid counting duplicates as independent customers.
- Prioritize deliberately: consider impact, frequency, affected segment and confidence in the evidence.
- Assign an owner: record the investigation or change and a review date.
- Close the loop: explain the decision and, where relevant, how the customer can use the resulting change.
Closing the loop does not require promising every requested feature. A clear explanation of a limitation, a better workaround or an honest decision to defer can also be useful. Check whether the original problem remains before marking the feedback addressed.
What belongs in a voice of customer dashboard?
Show the period, segment and number of eligible records alongside recurring themes. Include affected tasks, unresolved high-impact needs, owners and overdue reviews. Keep survey scores attached to their questions and response counts, and use source links so a reviewer can inspect the context behind a summary.
Comment frequency is not necessarily prevalence across all users. A sudden rise in contacts may reflect an outage, a new release or changes in collection rather than a long-term trend. Review a sample when automated tagging or summaries are used, especially before presenting an inferred cause as a confirmed finding.
Start with one feedback source and one customer problem, then expand when the team can act on what it collects. For tooling considerations, see our customer feedback analysis tools guide. Screendesk can add visual context through screen recordings and video support, helping a customer show the task behind a comment. Use that context alongside their words and verify the need before deciding on a solution.
