How to Analyze Customer Feedback: Example and Template

To analyze customer feedback, define the decision you need to make, collect relevant comments, remove duplicate cases, group the remaining feedback by problem, and compare each problem's reach and impact. Finish with a decision record that links your recommendation back to the original feedback.

The useful output is specific: “Investigate stalled imports before adding report customization: two customers describe being unable to finish setup.” A label such as “onboarding issues” does not explain what to do next.

This guide walks through a small dataset from raw comments to a prioritized investigation. You can repeat the process in a spreadsheet using the template below, then use AI to assist with larger batches.

1. Define the question and collect relevant feedback

Choose one question before collecting data. For a product team, that might be:

What prevents new workspace administrators from completing and sharing their first report?

Set a time window, product version, and audience. For this example, assume the team is reviewing one week of feedback from new administrators using the same release. Those boundaries keep an old bug or an unrelated purchasing complaint from changing the answer.

Choose sources that can answer the question:

• Support tickets reveal specific failures, but miss people who never ask for help.
• Surveys and interviews let you ask about the workflow directly, but the questions and participant selection affect what you hear.
• Public reviews and community discussions can reveal expectations and workarounds. The writer's customer status, version, or account may be unknown.

Keep source groups identifiable even when combining them. Ten replies in one public thread are not necessarily ten independent customer experiences. Public comments about a competitor can inform research, but should not be counted as feedback from your own customers.

For each record, preserve its ID, original text, source reference, date, and known customer or account context. Use “unknown” when information is missing. Keep private feedback in an approved workspace and remove identifying details before sharing examples outside the team.

Example: eight feedback records

The dataset below is fictional and created for teaching. The comments, customer IDs, and later decisions are illustrative; they are not EvidSeek customer data or results from a product test. In this scenario, A–F are six distinct, confirmed customers. F02 is a follow-up to F01 about the same incident.

ID / customer	Original feedback
F01 / A	“My CSV import stayed at 80%. I restarted twice and still couldn't create the first report.”
F02 / A	“Following up on the same import ticket: it's still stuck at 80%.”
F03 / B	“The import never finished. There was no error message, so I gave up on setup.”
F04 / C	“The import took five minutes, but it completed and I made my report.”
F05 / D	“Please add CSV export. I copy the numbers into a spreadsheet for my manager's weekly report.”
F06 / E	“We need CSV export to keep a dated record for our internal audit.”
F07 / F	“I'd like more chart colors. The current reports work, but they don't match our brand.”
F08 / F	“My import was slow, though it finished. After that I could build the report.”

2. Clean the records and decide what you are counting

Retain F02 in the source log, but mark it as a follow-up to F01 and exclude it from independent-case counts. It adds context about persistence, not a second affected customer. Keep F07 and F08: they come from the same customer but describe different problems.

The cleaned dataset contains:

• 8 raw records, including the follow-up.
• 7 independent feedback records after excluding F02 from counts.
• 6 distinct customers, because customer F contributes two different observations.

These numbers answer different questions. Use independent records to describe the material you analyzed and distinct customers to describe observed reach. If your business operates at account level, also track accounts; several people from one organization do not establish several affected organizations.

Remove spam and out-of-scope records using explicit reasons. Do not discard positive or mixed comments: F04 and F08 will help us distinguish a slow import from one that prevents completion.

3. Code the comments by problem, then infer the need

A code is a short label with a definition. Start with labels precise enough to guide a decision. In this dataset, “import blocked” and “import slow but completed” should stay separate even though both belong to onboarding.

Here is the first coding pass. The final column is an analyst interpretation to check, not another customer quote.

Records	Code and inclusion rule	Need or question to validate
F01, F03	Import blocked: customer reports being unable to complete the import.	Complete setup and understand what to do when the import stops.
F04, F08	Import slow: customer describes a delay but confirms completion.	Understand expected waiting time; check whether the delay causes additional friction.
F05	External reporting: manually copies data for a manager.	Share report data outside the product without retyping it.
F06	Audit record: asks for an export to retain a dated record.	Keep a retrievable record; confirm the required format and controls.
F07	Chart appearance: reports work but colors do not match the brand.	Present reports in a preferred visual style.

F05 and F06 both request CSV export, but their intended outcomes differ. You can count two requests for that feature while keeping separate need labels. A shareable report might help D without meeting E's record-keeping requirements. Do not promise that a CSV file satisfies an audit requirement without investigating it.

One comment can receive multiple labels when it contains separate observations. If that happens, explain that category totals can exceed the number of records or customers. Do not force a multi-issue comment into one bucket just to make a chart add up to 100%.

Review ambiguous labels against the source. For example, F03 supports “reported import failure,” but does not establish whether the cause was a server error, an unsupported file, or something else. Leave the root cause unresolved.

4. Summarize patterns with explicit denominators

For this example, divide the number of distinct customers mentioning a problem by the six customers in the cleaned sample:

Two customers reporting blocked imports ÷ six sampled customers = approximately 33% of this sample.

That is not a 33% failure rate across the product. These customers were selected through feedback, and the dataset contains no count of all import attempts or all active customers.

Pattern	Independent records	Distinct customers	Supported conclusion
Import blocked	2: F01, F03	2 of 6	Two sampled customers describe setup failure; investigate cause and reach.
Import slow but completed	2: F04, F08	2 of 6	Two others report delay with successful completion.
CSV export requested	2: F05, F06	2 of 6	Two requests share a format but serve different needs.
More chart colors	1: F07	1 of 6	One customer wants visual customization and says reports work.

Customer F appears in both the slow-import and chart-color rows, so do not add those customer counts to estimate unique reach. At the broader onboarding level, four distinct customers mention import behavior, but only two describe being blocked.

For larger datasets, keep source, segment, and version filters available. A rise in complaints after collecting more reviews may reflect collection volume rather than a worsening product. Report counts alongside the relevant denominator and compare equivalent windows.

5. Prioritize the next investigation, not just the most requested feature

The blocked-import and CSV-request rows have equal counts. Their consequences differ: A and B cannot finish setup, while D has a manual workaround and E has an unresolved record-keeping need.

Given our question about completing and sharing a first report, a reasonable initial order is:

1. Investigate blocked imports first. Inspect the two cases and relevant import logs. Determine whether they share a cause and whether other attempts are affected. The feedback supports investigation, not a specific fix.
2. Clarify the two export needs. Ask D who receives the report and how often. Ask E which record must be retained and what makes it usable. Then compare possible solutions.
3. Check slow imports separately. F04 and F08 show that a delay can still end successfully. Measure duration and inspect user expectations before treating slowness and failure as one defect.
4. Keep chart colors in the backlog for this decision. F07 describes a preference with a working report, so it does not currently outrank setup failure.

This order is a judgment for the fictional dataset, not a universal scoring formula. New evidence could change it: a time-critical export requirement, for instance, would require reassessment.

If you use scores, define what each level means and attach a reason. “Severity: high, because setup could not be completed in F01 and F03” is more useful than an unexplained 9/10. Keep uncertainty visible: confidence that two customers reported a problem can be high while confidence about its cause and prevalence remains low.

Only compare implementation effort after identifying the problem. A progress indicator might help someone understand a long-running job, but it cannot be assumed to fix a failed import.

6. Turn one finding into a decision record

Here is a filled-in handoff based on the same fictional example. Suggested ownership and timing illustrate how to make the next step accountable; they are not evidence from the comments.

Field	Example decision record
Problem	Some new administrators report being unable to complete their first CSV import.
Evidence	F01 and F03: two distinct customers. F02 adds follow-up context to F01 but is not counted again.
Observed impact	A restarted twice without creating a report; B abandoned setup.
Contrasting evidence	F04 and F08 describe slow imports that completed. They challenge a claim that all slow imports fail.
Underlying need	Finish setup and receive a useful explanation or recovery path when an import cannot complete.
Unknowns	Root cause, affected file types, total failed attempts, and whether A and B share the same defect.
Next action	Ask the engineering owner to inspect the two cases and compare failed and successful import attempts.
Review point	Revisit at the next weekly product review, sooner if investigation reveals an active widespread failure.
Success check	Confirm affected users can complete the workflow, then compare completion rates for equivalent import cohorts after any fix.

Where appropriate, tell the people who reported the problem what changed and ask whether they can now complete the task. Fewer complaints alone do not prove success: fewer users may have attempted the workflow. Pair follow-up feedback with the relevant behavior or outcome measure.

Copyable customer feedback analysis template

Use the first CSV block as a header row in your spreadsheet. Preserve original text and source references in the working file; use a separate row for each feedback item. duplicate_of identifies records retained for context but excluded from independent counts.

feedback_id,customer_id,account_id,source_reference,date,segment,product_version,original_text,duplicate_of,theme,problem_code,requested_feature,inferred_need,observed_impact,analyst_notes

Keep a separate sheet or document for findings. Copy this template once per important problem:

Decision question and scope:
Problem statement:
Affected segment:
Supporting feedback IDs and source references:
Independent supporting records:
Distinct customers or accounts, with denominator:
Observed consequences:
Contrasting or contradictory feedback:
Inferred need:
Unknowns and confidence rationale:
Priority and reason:
Next action and owner:
Review date:
Outcome measure:

For a small batch, read and code the comments manually first. This helps establish what the labels mean before asking software to apply them repeatedly. As the dataset grows, keep the same source IDs so a summary can always be checked against individual records.

Where AI helps with customer feedback analysis

AI can assist with candidate labels and summaries, but review its treatment of ambiguity, negation, duplicates, and mixed outcomes. In our example, “slow, though it finished” must not become “import failure,” and two CSV requests must not become one proven business need.

For an approved AI tool, this prompt provides a starting point:

Analyze the supplied feedback for the stated decision question.
Use only the supplied records and retain their IDs.

Return a table with:
- Feedback ID
- Proposed problem code
- Exact supporting excerpt
- Observed consequence
- Inferred need, explicitly labeled as an inference
- Unknowns requiring follow-up

Distinguish failed tasks from slow but completed tasks.
Flag possible duplicates; do not silently remove them.
Allow multiple codes when a record contains multiple problems.
Do not invent customer identities, causes, counts, or product capabilities.
Separate requested features from the outcomes people want.

Review the labels before calculating totals. Recompute counts from the accepted records rather than trusting a generated summary, and check important findings against their original wording. Use only data your organization permits you to share with the chosen tool.

For public review research, the EvidSeek review analyzer analyzes supported content loaded in your browser and provides source references where available. Its findings describe the selected content, not every review about a product. If your source is a supported Trustpilot company page, the Trustpilot review analyzer provides a focused entry point for that workflow.

Start with one decision and one bounded batch of feedback. Produce a finding someone can verify, assign a next action, and revisit it when new evidence arrives. You then have a repeatable analysis process rather than a growing list of untested feature requests.