Customer Feedback Analysis With Themes and Counterexamples

Customer feedback analysis is a review of customer comments to identify needs, recurring patterns, and cases that do not fit. The useful output connects each theme to its source examples, context, and limits, so another person can check the reasoning.

Suppose two messages ask for a narrower delivery window. They may describe two customers, or one person chasing the same order. Both messages matter, but treating them as two customers changes the claim before you have checked the source.

This guide builds a theme-example-counterexample note from a fictional meal-box sample. Atlas can help compare permitted feedback and draft source-linked patterns. You still review the entries, correct the interpretation, and decide what the evidence supports.

What customer feedback analysis should produce

A feedback analysis note should state the question, the text you read, and the main patterns. Beside each pattern, keep an example that supports it, a case that limits it, and a source link. Add any open question and the next check it calls for.

Sentiment describes tone toward part of an experience. A need is what someone is trying to do. A feature request names one way they think the service could help. A negative label alone does not tell a team which problem to solve.

The GOV.UK analysis guide keeps what people said or did apart from what a team thinks it means and may do next. Its advice concerns user research sessions. Apply that distinction to comments while retaining how each was collected.

This page focuses on a supplied text sample. It does not design a full feedback program or select software. For help turning an interpreted pattern into a clear statement, see the user research insights guide.

Define the feedback sample and question

State the decision the review will inform

Choose a question you can answer from the text. For example, ask what needs appear in comments about receiving and managing a meal box. That helps you choose which passages to read closely without assuming the cause of each complaint.

Write down what the review cannot answer. These comments may describe delivery planning, but they cannot show whether a new schedule would work. Our research objectives guide helps connect the question to the choice it should inform.

Record where the comments came from

Keep dates, channel, question wording, and product version where you have them. A reply about delivery may cover different topics from an open chat with support. Mark missing context in the note, rather than filling it in with a guess.

Keep enough text to understand each comment. If someone says a price is fair in reply to a specific offer, leaving out the offer can change the meaning. Thematic's feedback guide shows why short answers need their question context.

Choose the unit before counting

A unit is the thing you count: an entry, a chat, an order, or a customer. Give each kept entry an ID and note known links.

Two follow-ups can stay in the file while counting as one chat if that is the unit your question needs. Keep the counting rule with the note so a reviewer knows what its totals mean.

Do not remove repeated words just because they look alike. One copied export row is a duplicate; two people describing the same issue are separate accounts. Review only text you may process, and keep private IDs out of shared notes.

Code the evidence before naming themes

Label the relevant passage

A code is a short label on a passage, such as delivery window too broad or skip control hard to find. Read the entry first, then mark what answers your question. Keep its ID and source location beside the label.

An entry can discuss more than one thing. Someone may enjoy the meals and struggle to plan for delivery. Thematic's coding examples show why one overall tone label can hide that difference.

Define what each code includes

Write what each label means and where it stops. Delivery timing might cover plans around a window; late arrival might cover a missed promise. Decide whether your question needs them kept apart before adding their counts.

You may start with groups based on your question and add labels as you read. Record each change. Gale and colleagues describe several coding approaches within the Framework Method. Here, we adapt ways to trace claims to their source text.

Interpret the pattern in context

Compare coded passages and write what connects them. A label such as delivery tells you the topic. A note about the need to plan around arrival tells you more. Check that the claim fits the entries and does not go beyond them.

NN/G distinguishes codes from themes: naming a passage and working out a pattern are different tasks. For a full thematic analysis, choose and report a method that fits your study. A quick sort of comments should not carry that claim.

A worked theme-example-counterexample note

Imagine a fictional meal-box service reviewing fifteen short entries from one file. Every service detail and entry below is invented teaching material. No customers supplied these comments, and no study or Atlas test produced them.

The question is what needs appear around receiving and managing a box. The unit is one feedback entry, with IDs F1 through F15. F1 and F2 are known to concern the same customer's delivery; customer relationships for the remaining entries are unspecified.

• F1 likes the meals but cannot plan around the wide arrival window.
• F2 follows up on that same delivery and asks for a narrower window.
• F3 says the broad window suits someone who works at home.
• F4 could not find the option to skip the next box.
• F5 also had trouble finding the skip option before an upcoming trip.
• F6 found the skip option quickly and completed the task.
• F7 asks for more vegetarian choices for household meals.
• F8 wants vegetarian choices when selecting a box.
• F9 says the current meat choices suit the household.
• F10 cannot tell how to return reusable packaging.
• F11 is unsure where to leave packaging for collection.
• F12 understood the return instructions and followed them.
• F13 cannot tell whether a support request is still pending.
• F14 wants an update on an unresolved support request.
• F15 received a clear resolution and knew no further step was needed.

The table below turns those entries into five bounded themes. Its exceptions help explain where each claim stops. They do not cancel the supporting accounts or prove that a proposed fix would help.

Table 1: Fictional theme note: source entries and exceptions retain their IDs. The rows describe this text alone. They cannot establish population rates, observed behavior, or product causes.

In the first row, two entries concern one known customer's order, so a claim that two customers need narrower windows goes beyond the text. Keep the follow-up as context and state what you counted.

Keep F1's meal praise beside the delivery complaint so the entry retains both aspects. Liking a meal does not tell you whether the range of vegetarian choices meets a household's needs.

Check the pattern against its exceptions

Find a case that changes the claim

Read the entries that seem to oppose each theme. F3 shows a setting where a broad delivery window works. Keep that condition in the claim rather than saying all customers need a narrower window. Gale and colleagues' method paper discusses cases that depart from a pattern.

F15 is a weaker test of the pending-support theme because the request was closed. Keep it as a scope exception. Seek a case where a request is still open before explaining why one person had more clarity. Check whether each opposing case bears on the claim.

Keep silence separate from disagreement

An entry that never mentions packaging does not show that its author knew how to return it. People answer different questions and raise different concerns. Mark an absent topic as absent, rather than treating it as proof that the process worked.

Read the source again when a pattern seems too neat. Look for a condition, a change over time, or an example you left out. The official GOV.UK guide starts from what was recorded. Keep useful single cases as well as repeated points.

Leave a memo a colleague can inspect

Write how you grouped the entries and why an exception changed the wording. Keep uncertain links visible. The Framework Method authors use memos as they work out what the data mean. Their original example below comes from healthcare research.

Gale and colleagues, original submitted figure 6, Framework Method paper, 2013, CC BY 2.0. Complete unchanged memo; the healthcare accounts are unrelated to the fictional feedback sample.

Notice the separate areas for the definition, codes, data, deviant cases, and further questions. Keep your claim beside the evidence and what remains unclear. This healthcare memo says nothing about meal-box customers; it shows a way to make the reasoning visible.

Choose a next step from the evidence

Separate the need from the requested feature

F2 asks for a narrower delivery window to make planning easier. Several changes might help, but the file does not compare them. Keep the request as one person's idea rather than presenting it as the fix the team must build.

The GOV.UK analysis workflow moves from findings to possible actions. Make that step clear in your note. A proposed test, a follow-up question, and a check of the current service have different purposes.

Review urgency as well as repetition

A rare report can describe harm, loss of access, or a failure that is still open. Give it the review it needs even if it appears once. Repeated mentions help you judge the pattern, but they are not the only basis for deciding what needs work first.

For this fictional sample, inspect the current skip path before assuming it needs a redesign. Ask which screen and version F4 and F5 used, and whether the instructions differed. The NN/G analysis guide helps with reading patterns; checks of the service add more evidence.

Name the open question and its owner

For delivery planning, ask which arrival details would help in different work settings. For packaging return, ask which instructions people received. Assign the next check to someone who can find that missing context.

Keep action ideas apart from findings. The user research insights guide shows how to keep a supported claim and a next step distinct. Choosing an action does not strengthen the evidence for the pattern.

Keep counts and conclusions within the sample

You can say that two of the fifteen fictional entries discuss trouble finding the skip option. The unit is an entry, and one entry can have more than one code.

Theme totals may overlap. Do not add them as though each record belonged to just one group. F1's meal praise and window complaint are two aspects of one entry, rather than two extra entries in the file.

You cannot say that two fifteenths of all customers struggle to skip a box. A feedback file may contain more people who contact support, answer a survey, or have a problem. People who stay silent or leave the service may be missing.

Gale and colleagues warn about wider numerical claims from qualitative material. Counts can describe the file you read. Claims about more people need a sound basis in how you chose the sample and asked for feedback.

Take care when comparing channels or dates. A later file may contain more skip complaints because a question changed or an export kept more follow-ups. Before calling that a trend, check that units, prompts, coverage, and product versions match.

Comments report experiences and views. They do not by themselves show what someone did, a technical root cause, or why someone left. A request for a vegetarian option does not prove lost sales. Negative tone does not prove that someone will stop buying.

For a deeper study, our inductive thematic analysis guide explains another method. Choose it when it fits your purpose, rather than calling every quick grouping of comments a full study.

Review customer feedback themes in Atlas

Select permitted material and name the scope

Prepare the feedback text and a note with the question, dates, channels, entry rules, and counting unit. Remove private details as required by your data rules. Permission to read a support file does not by itself let you process it in another tool.

Open the project and use @ in chat to mention the feedback and scope note. Choose Project only to block new web or literature searches. Earlier chat context stays available. Check it or start a fresh chat when outside sources could confuse this review.

Request patterns with source examples

Ask for a bounded draft: Compare the named entries for needs around receiving and managing a box. For each theme, keep entry IDs, a source passage, a counterexample or scope exception, and an open question. Keep what people said apart from what you think it means; do not infer how many customers wrote the entries.

The Atlas source comparison procedure supports focused comparisons followed by citation checks. Treat the response as a reading aid. It may miss text or group it poorly, so a neat table does not prove that coding is complete.

Check passages, revise, and save

Open each numbered citation and read the text around it. Check the source, the point it makes, and any limits. The citation inspection guide explains how to check a claim and find an item by name when a citation does not open.

Read entries the draft left out and check the code meanings yourself. One citation does not prove that all useful passages were found.

Correct a count of customers to a count of entries where needed. Keep the link between F1 and F2 visible, and narrow claims that exceptions weaken.

Select New, then Note, and keep the checked themes, source IDs, exceptions, scope, and open questions. Follow the first-note tutorial and wait for Saved before closing. Saving keeps your note without certifying its claims.

Share the checked feedback analysis note

Before sharing, have a reviewer trace each theme back to its source entries and exceptions. Check the question, file scope, unit, code meanings, and links between messages. Remove or narrow claims that the feedback cannot support.

Give the team the note with its source links and open questions. Name who owns the next step and what evidence they need. When new feedback changes the pattern, revise the claim and its limits together so a reader can still check the reasoning.