Customer Feedback Analysis: Worked Example and Template

Start with a decision question

Choose the decision the analysis will inform. “What do customers want?” is too broad to guide a small review. In this illustrative example, a PM asks which obstacle to address in the next improvement cycle: failed exports, confusing export columns, scheduled delivery, or inviting a teammate. The scope is the account-activity workflow, and the input is eight fictional feedback records from seven fictional companies.

The dataset is deliberately small so you can inspect every conclusion. It is not a survey of Vantage customers, a representative market sample, or proof of demand. The objective is to demonstrate a repeatable method. Productboard describes feedback analysis as connecting themes with impact and product initiatives. GOV.UK's research guidance separates recorded observations from the interpretation and actions built from them.

Preserve the evidence before summarizing

Keep a stable feedback ID, date or research round, customer or participant identifier, source, exact observation, and relevant context. Do not replace the source with an AI summary. A reviewer should be able to reopen the original note and see whether the interpretation is fair. Store sensitive source material with appropriate access and put only the necessary identifiers into a shared analysis worksheet.

The downloadable raw CSV records F-01 through F-08. Company A reports an export failure and later sends a support follow-up about the same unresolved issue. Company C reports the same problem independently. Company B objects to column names, D asks for scheduled delivery, and E and F describe invitation friction. Company G works alone and explicitly does not want an invitation prompt added to every visit.

That last observation is a counterexample to a blanket onboarding change. It should remain visible even if most of the discussion focuses on collaboration. Feedback that challenges a proposed solution is evidence to explain, rather than noise to discard. The team may need a conditional prompt, a different segment, or a smaller experiment.

Code problems separately from proposed solutions

Create a short codebook. Each code needs a definition, inclusion rule, and an example. In this dataset, Export reliability means a requested export does not produce a usable file. Export format means the file exists but its naming or structure causes difficulty. Collaboration setup means an invited or inviting user cannot understand how to complete the intended team workflow.

A request for a scheduled email is a proposed solution. Code the underlying need as recurring access to an activity report, then retain scheduled delivery as the suggested option. The problem might also be addressed through a repeatable saved export or a reporting integration. Keep those possibilities open until the workflow and constraints have been checked.

Allow more than one code when a record contains genuinely different observations, but do not split one sentence into several votes. Ask a second reviewer to code a small sample independently. Disagreement often reveals an unclear definition or lost context. Resolve the rule and recode affected records before comparing totals, rather than forcing agreement on the desired conclusion.

Deduplicate demand without deleting history

F-03 is Company A's follow-up to F-01, so it stays in the raw dataset with Duplicate of F-01 in the analysis field. It is useful evidence that the issue remains unresolved. It contributes no additional company to the demand count. The reliability theme therefore has three raw records from two distinct companies, A and C.

Choose the unit appropriate to the question and state it. Distinct companies can be useful for a B2B product decision, while individual users or distinct incidents may be better for another analysis. A single company can have several users experiencing different failures. Deduplicate only clear repeats of the same unit, and retain the links that let reviewers check the decision.

Build a theme table that keeps the caveats

The visible table and completed analysis download show four problem themes. Export reliability affects two of the seven companies in the sample. Invitation friction also affects two. Export format and recurring report access each have one. Company G supplies a separate counterexample to an unconditional invitation prompt. These counts summarize this dataset only and do not estimate prevalence across all customers.

Add severity and workflow context alongside frequency. A blocked export used for a deadline can deserve faster attention than a convenience request with more mentions. Conversely, a frustrated tone does not establish technical severity. Ask what task was prevented, what workaround existed, and whether the failure can be reproduced. In this sample, failure consequences remain claims to validate with a support reproduction and a product check.

Make a bounded prioritization decision

The example decision is to investigate and address export reliability first, while running a focused invitation usability check. The reason is the blocked core task and two independent reports, with a clear reproduction question. Scheduled delivery remains a discovery candidate. Column naming receives a small clarification check rather than an immediate redesign. These are editorial decisions within the fictional scenario, not observed customer outcomes.

Record what could change the ordering. If the reliability issue is an unsupported file format already documented clearly, or if invitation failures prevent account activation for a broader segment, the team should revisit the decision. An explicit reversal condition makes the analysis testable and prevents a provisional interpretation from becoming permanent roadmap truth.

The handoff should contain the source IDs, problem statement, affected segment, uncertainty, next action, owner, and success check. For export reliability, the next step is to reproduce the two reported failures and confirm the expected output. The success check is successful completion of the defined task under the previously failing conditions, followed by observation after the change reaches users.

Use AI with a checkable audit trail

An AI assistant can suggest codes, cluster similar observations, or draft a theme table. Require source IDs for every theme and keep the underlying feedback available. Manually inspect a sample of included and excluded records. Check whether the assistant merged different problems, treated a follow-up as a new customer, or converted an unsupported opinion into a fact.

Avoid sending sensitive feedback to a tool without checking your organization's data-sharing rules. A sanitized sample can be enough to test an analysis approach. The final product decision still requires accountable human judgment about strategy, effort, risk, and the limits of the evidence. Automating summaries does not remove those responsibilities.

Close the loop and repeat consistently

Tell the relevant customers what the team learned and what action was chosen when appropriate. Preserve a link from the decision to the source feedback and eventual delivery work. Use the same definitions on the next comparable dataset, recording any taxonomy changes. Otherwise an apparent trend may simply reflect a new coding rule or collection channel.

The blank worksheet, raw example CSV, and completed theme CSV make those steps reproducible. Import them into Excel or Google Sheets, adapt the codebook, and work through one decision before scaling the process. Keep new intake separate from this frozen example so a reviewer can reconstruct the reasoning that supported the original decision.

Continue the workflow

• Feature prioritization template
• Decision log template