Voice of Customer Template: Keep Source Links

A voice of customer template keeps feedback tied to its source, context, and meaning. Use it to keep what someone said, the need you think it points to, and the next step the team will review. A clear record lets another person check the claim without relying on your summary alone.

This guide gives you a record to copy and a made-up table about meal orders. It keeps quotes distinct from the needs you infer and leaves unknown impact unknown. Atlas can help compare source text you are allowed to use; human owners check the claims and choose what to do.

What a voice of customer template does

Start by deciding which job the template serves. A survey form collects new responses, while an internal table keeps track of feedback you have. A priority scorecard makes a further judgment about what to do. This guide focuses on the source table so that later choices have a trail to follow.

Formbricks' template guide advises teams to choose between a project summary and an ongoing tracker. That choice shapes the fields you need. A one-off research note may need a review date; an ongoing tracker may also need an owner and a record of what happened next.

Voice of customer work includes finding needs, grouping them, and choosing which come first. Griffin and Hauser's research abstract treats those as distinct tasks. A table that groups quotes has not, by itself, shown how much each need matters or which product idea should come first.

Keep the customer's words close to the need you propose. ASQ's table guidance starts with the statement and the situation in which it was made. That context helps you tell whether a request points to a broader need, a one-off problem, or a preference that differs across people.

Set fields that preserve the source

Use a short record you can copy for each item. The format below is a working template written for this guide, not a tested survey or scale. Add fields when the task needs them. Avoid a large form whose empty columns tempt the writer to fill gaps with guesses.

Record ID:
Source link and passage location:
Date, channel, and relevant customer context:
Exact quote or clearly labeled paraphrase:
Proposed need and theme:
Support, counterexample, and open question:
Permission and sharing boundary:
Review status, next step, and owner:

The source link should lead to the record you can share, with details that help a reviewer find the passage. A transcript paragraph, ticket reply, or dated survey response is clearer than a link to a folder of files.

Keep access controls suited to the source; the table should not expose names or private data to a wider group.

Label whether you copied exact words or wrote a summary. Check unclear speech against the recording when you are allowed to do so, and mark where you are unsure. GOV.UK's analysis process separates what the team saw or heard from what it thinks the source means. This also helps you keep quotes faithful to the source.

Context can change the need: a person waiting at home for a meal box may want timing details for a different reason from a person leaving it with a neighbour. UserVoice's template includes source and account context.

Use checked facts that matter to the task without adding a sales-value field just because another template has one.

Build a fictional customer evidence table

Imagine a made-up meal service reviewing feedback about when boxes arrive. All labels, quotes, dates, and source details below are invented to teach this process. They are not real customer words, Atlas user records, or measured results.

The table shows how to keep distinct roles in the source material.

The team is checking a draft theme that people need text messages to avoid cancelling. This wording mixes a feature request, a need the team inferred, and an outcome it has not checked.

The record keeps those parts separate so the team can revise the theme without losing the request.

Table 1: Fictional teaching table: quotes, source locations, and review states are invented to demonstrate a traceable record.

A better theme is that these accounts point to a need to know when the box will arrive, with different views on the channel. The first two records support that candidate need; the third limits a claim that text messages are the only answer.

None shows that an update feature would reduce cancelled orders or lead to more sales.

In a real record, keep the supporting text and opposing case alongside the theme. Our completed user research insights guide shows how a claim tied to sources can keep a case that does not fit.

The aim is a checked account that the team can challenge, rather than a polished slogan that hides the support.

Check the need behind the request

Use three criteria to review a need you infer: fit with the source words, fit with the situation, and room for more than one way to meet it. These are editing checks for the table, not a scoring method. A feature request may help while still leaving the underlying need unclear.

ASQ's guidance distinguishes customer needs from specific features and technologies. In the fictional example, a text message is a possible way to help someone plan around delivery. It is not the need itself. Keep the candidate need separate so the team can compare options without erasing the customer's request.

Check the meaning you propose against the source context. Did C1 say they missed a box, needed to leave home, or preferred text over email? If those details are absent, do not add them to make the story clearer. Mark the claim as a draft and seek more context where consent and the research plan allow it.

Group statements by the need they may express, while keeping different contexts visible. Formbricks' guide includes themes and real customer words among its core fields. Our inductive thematic analysis guide covers a fuller approach to developing patterns when the task requires more than a quick evidence note.

Retain a theme's open question until you have resolved it. GOV.UK's process records findings and possible actions separately. Your next step could be to clarify a need, test an idea, or gather missing context.

None of those proposed actions should appear as a completed customer finding.

Keep frequency and business impact separate

Count the right unit if you record frequency. Three ticket replies may concern one customer and one incident. The same quote may also appear in a transcript, a sales note, and a report. Keep those links together so several copies do not look like several independent voices.

Channel choice shapes who appears in the record. Support tickets show the people who asked for help, not all those who had an issue. An interview set reflects who was recruited and its scope. The VoC research abstract examines frequency versus importance and reports self-selection concerns in satisfaction measures.

Do not turn raw mentions into a rule for all priority choices.

Record business context only when it matters, has been checked, and is allowed to be shared. UserVoice's guide uses account and impact fields in its own format. That choice does not show that your customer will churn or that a feature will earn more than it costs.

Leave missing impact unknown. A complaint about timing can give you a reason to look into the problem without proving lost sales. If the business needs an outcome estimate, get the right data and analysis through its owners.

The table can link to that work later, but it should not create a number to make the note look complete. If the next decision compares products, use the checked needs as criteria for competitive product analysis, then verify each product claim against its own sources.

Check quote support in Atlas

Use only consented records that you are allowed to process in the tool. Check privacy terms and access before you upload them. Remove names or restricted details where required, while keeping the context needed to judge meaning. A source link should help reviewers with access without making private content open to a wider group.

Open the project with the records you need and mention the chosen sources with @. State the template's purpose and the theme you want to check. Choose Project only to prevent new web or literature searches; earlier chat context remains available. Keep track of which sources the response uses.

Ask Atlas to compare the draft need with the named feedback. For example: "Keep exact words distinct from paraphrases. Cite support for each need, keep opposing views, and flag impact claims these sources do not support." Treat the response as a draft reading aid.

A missing passage may mean the tool did not find it rather than prove the claim has no support.

Existing Atlas screenshot about ColPali: it illustrates source inspection, not the fictional meal-delivery feedback or a customer-analysis accuracy test.

Open citations and read the source context yourself. Check the quote, who said it, the situation, and any limits nearby. Our citation tracking guide explains why a link still needs review.

Reject a claim about cancelled orders when the source only asks to know when a box will arrive.

Save the checked table and the reasons for each theme in a note. Select New, then Note, and wait for Saved before closing. Our research synthesis guide covers connecting claims across larger source sets. Humans check facts, source quality, meaning, and the final priority choice.

Review the note before sharing

Review the source links, exact quotes, scope of each theme, and the cases that do not fit. Check that permission and access match the audience.

A colleague should be able to trace the need back to the feedback and see which parts remain in doubt without being shown private details they do not need.

Agree on the next step and its owner, then keep the review status current as the team learns more. The template supports a choice by keeping the source trail and its limits clear. It does not choose for you, prove a business outcome, or replace a review with the person who owns the decision.