How to categorise customer feedback without losing the meaning

Categorise customer feedback by separating what the customer experienced, the part of the product involved and the outcome they wanted. Keep the original comment and its source alongside those labels. Then review related comments together, count distinct customers separately from mentions, and decide what deserves investigation.

You do not need a large taxonomy to start. You need categories that two people can apply consistently, a place for uncertain cases and a way to trace every conclusion back to the evidence.

This guide shows how to build that system for recurring feedback from customer conversations, support and other channels. The examples are fictional. They illustrate the method, not findings from Weeve customers.

What you need before you start

Choose a small, bounded collection to organise: for example, feedback about onboarding from the last month. Have the original comments, links or recording references available, plus a spreadsheet or feedback repository where you can maintain the categories.

Define the decision the work should support. “Understand what stops new accounts completing setup” is useful. “Analyse all our feedback” leaves the scope and the stopping point unclear.

Keep three things separate:

• The evidence: what someone actually said or did, with its source.

• The classification: the labels you apply to make related evidence retrievable.

• The decision: whether to investigate, fix, explain, defer or decline something.

A category is an organisational choice. It does not prove a cause, establish how widespread a problem is or promise a place on the roadmap.

1. Choose one issue as your unit of feedback

A single message can contain several useful observations. Do not force all of them into one label.

Consider this fictional comment:

I eventually found the export button, but the file had no dates. Could you send the report to my team automatically every Friday?

There are at least three different points:

• Finding the export control was difficult.

• The exported file did not contain dates the customer expected.

• The customer requested scheduled delivery.

Create three linked entries if those points need different investigation or owners. Preserve the full original comment once, and give each entry the same source reference. This avoids losing context while making the individual issues sortable.

Do not split every sentence mechanically. “The button was hard to find, so I asked support” describes a problem and its consequence. Those details usually belong together.

The expected result is a collection of issues that can each be classified sensibly. You should be able to say what every entry is about without rereading an entire conversation.

2. Use separate fields for separate questions

“Negative”, “billing” and “feature request” answer different questions. Putting them into one category list creates combinations that are difficult to compare.

Use a few independent fields instead.

Feedback type: what kind of statement is this?

A practical starting set is:

• Problem: something prevented or complicated the customer's task.

• Request: a proposed addition or change.

• Question: something the customer does not understand.

• Praise: something that worked well or delivered value.

Add types only when they change how you handle an entry. A reported defect may deserve its own type if your team has a separate verification process. Until it has been reproduced or otherwise established, label it “reported defect” rather than treating the report as a confirmed diagnosis.

Product area: where does it happen?

Use names your team can apply consistently: onboarding, search, recording, exports or billing, for example. An area should be broad enough to contain multiple related issues.

Avoid using the name of an individual customer as a product category. Customer identity belongs in a separate, appropriately restricted field.

Customer goal: what were they trying to achieve?

Write this in the customer's terms. “Send a dated report to colleagues” is more informative than “use export”.

The goal helps you recognise related needs when people propose different solutions. One customer might request an email attachment, another a shared link. They may be trying to achieve the same outcome, but you still need to check whether access, timing and recipients differ.

Evidence and context: how do you know?

Keep a short excerpt or faithful paraphrase, source reference, date, relevant product version and the context needed to interpret it. Mark paraphrases as paraphrases. Record unknown details as unknown.

Sentiment can be an additional field when it helps your analysis. It should not replace the problem description. A polite comment can describe a serious obstacle, and an enthusiastic customer can still identify a defect.

For another view of this separation, Canny's feedback organisation guide discusses themes, tags and customer segments as different ways to organise feedback. The workflow here adds explicit classification rules and checks before you use the resulting counts.

3. Write rules for your categories

A useful taxonomy is a small set of labels with definitions. Each definition should explain what belongs, what does not and how to handle a borderline case.

For an Export — missing information category, a definition might be:

Use when the customer says information they expected is absent from an exported file. Do not use for difficulty finding the export control. Keep a request for a new delivery method separate.

Add one included example and one excluded example. That is often more useful than a long abstract definition.

Keep an Unclear — needs review option. “It doesn't work” is not enough information to distinguish a defect, an expectation mismatch and difficulty using the interface. Preserve the comment and identify the question needed to classify it.

Avoid a permanent “Other” bucket that becomes the largest category. Review its contents periodically. Repeated, meaningful patterns may justify a new label; unrelated one-off comments do not automatically need their own categories.

The expected result is a category guide another person can use without asking you to interpret every item.

4. Trial the categories before classifying everything

Apply the draft categories to a small, varied sample. Include short comments, multi-issue messages, praise and ambiguous reports.

If two people are available, have both classify the same sample independently. Compare the disagreements. If you are working alone, classify the sample, return to it later and check whether your own choices remain consistent.

Discuss the reason for each disagreement:

• Did the entry contain more than one issue?

• Were two category definitions overlapping?

• Was essential context missing?

• Did someone label the requested solution rather than the underlying goal?

Revise the definitions and try the difficult items again. Do not present a small internal check as a validated reliability benchmark. Its purpose is to expose confusing rules before those rules affect a larger collection.

Keep the trial entries after the rules are settled. They can become examples for the next person who joins the process.

5. Use recorded conversations without expanding the scope accidentally

Customer interviews and calls often contain useful context that a short ticket loses. For recorded feedback in Weeve, use Chat to work with the relevant recordings and inspect the sources behind its answer. The customer feedback workflow explains that product use case.

Genuine Weeve interface with synthetic demonstration content.

Start with a bounded request:

Review the selected customer conversations for problems with exporting reports. Separate the reported problem, requested solution and customer goal. Keep each finding linked to its source. Mark missing context as unknown and do not infer how many customers are affected.

Check the recording selection before relying on the answer. A finding from a different product version or a much earlier conversation may need a separate entry.

Open the relevant source and read the surrounding discussion. A brief quotation might omit a workaround, a condition or a later correction. Verify names, dates and important wording against the recording when needed.

Use the reviewed findings in your feedback repository. This does not mean Weeve automatically imports every support ticket, labels your entire customer database or maintains the taxonomy for you. Keep those responsibilities explicit.

Choose the AI provider appropriately. Weeve supports local Chat; optional external providers receive relevant messages and source text. Anonymisation can miss details, so review what will be shared rather than treating it as a guarantee.

If your task is a one-off study with research questions and themes, the separate guide to synthesising user research covers that broader process. An ongoing feedback taxonomy needs additional ownership and maintenance.

6. Deduplicate without erasing independent evidence

Three mentions are not necessarily three customers. A person might describe the same issue in a call, repeat it in an email and have it copied into an internal ticket.

Link those entries to the same underlying issue while retaining their source references. Keep at least two counts distinct:

• Mentions: the number of recorded references to the issue in your chosen collection.

• Distinct customers or accounts: the number of identifiable, separate sources of feedback represented.

Choose customers or accounts according to the decision you are making, and state which you used. Several people from one organisation are several people, but not several customer organisations. If you cannot establish identity, report it as unknown rather than silently deduplicating or assuming independence.

Also distinguish a duplicate from a recurrence. A customer who reports the same failure again after a supposed fix has supplied new information about whether the problem persists.

Do not calculate a percentage of all customers from an incomplete feedback collection. “Five of the twelve accounts represented in this reviewed set mentioned export dates” describes that set. It does not establish the rate across your customer base.

7. Work through a complete example

Imagine reviewing six entries about a reporting feature:

• Account A mentions missing dates in a customer call.

• The same person repeats that issue in a support email.

• Account B asks for dates in an exported report.

• Account C cannot find the export control.

• Account D asks for automatic weekly delivery.

• Account E says the current report is useful and asks whether weekly delivery exists.

After classification, you have three issues and a positive observation, rather than one broad “export complaints” pile.

The missing-date issue has three mentions from two accounts. Difficulty finding the control has one report. Weekly delivery has a request from one account and a question from another. The praise should remain visible alongside the requested change.

Next, review what is still uncertain. Were dates missing for both accounts under the same conditions? Does the delivery question describe a real unmet need or simple curiosity? Would a clearer control label help Account C, or was a permission setting hiding the option?

These questions turn classification into investigation. They prevent the category name from becoming a diagnosis.

8. Prioritise after you understand the categories

Do not turn the largest category automatically into the highest priority. Examine the effect on the customer's task, available workarounds, frequency within the reviewed evidence, affected segment and confidence in the explanation.

Keep requests separate from commitments. A reviewed category can lead to a discovery conversation, a support explanation, a defect investigation or a decision to defer. None of those outcomes requires promising the customer's preferred solution.

For each issue you advance, record:

• A concise statement of the customer problem.

• The evidence and the limits of the sample.

• What remains uncertain.

• The next check or decision, with an owner.

• How the customer will receive an appropriate update.

Use counts to describe evidence, not to disguise a judgement as a formula. If you choose an uncommon but severe problem over a frequent inconvenience, explain that choice.

9. Maintain the taxonomy as the product changes

Assign someone to review unclear entries, duplicate labels and categories that no longer reflect the product. Choose a review cadence that matches how much feedback arrives.

When you rename or merge a category, record the mapping and the date. Otherwise, a trend may appear to change simply because the classification changed.

For example, merging “Report downloads” into “Exports” can increase the apparent export count without any new customer problem. Reclassify earlier entries for a fair comparison or clearly mark the change in your report.

Keep an archive of retired definitions. Historical feedback should remain interpretable even when your current product areas are different.

How to check the result is usable

Take an unfamiliar entry and follow it through the system. You should be able to find the original evidence, understand why its labels were chosen and see whether it is a repeated mention or an independent report.

Then take a category and ask whether it supports a sensible next action. If it contains unrelated problems, split it. If two categories always require the same explanation and owner, consider merging them. If the evidence is too vague, improve the intake questions instead of inventing precision.

The first useful outcome is a small, understandable set of customer problems with traceable evidence. Start there, test your category rules, and expand only when the next decision needs more detail.