How to Analyze Customer Feedback: A Worked Example

Start with a decision you can make: which obstacles should we investigate before changing first-time data import? Define the audience, task, period, and product version. Include completed attempts with friction as well as abandoned attempts. Do not mix routine repeat imports into first-time setup without marking the difference.

Inventory the relevant board, support conversations, survey answers, and research notes. Search workflow labels alongside customer language: upload, CSV, date mapping, connection, permission, and first report may reveal evidence that 'onboarding' misses. Use the search log to record queries, accessible scope, and missing sources. Keep private artifacts in their existing systems and link them from a restricted analysis document.

Test retrieval with a known relevant record. If it cannot be found, inspect the fields being searched and the active filters. A board's title search might miss detail in a comment; a date filter might exclude an older unresolved problem. Describe the resulting collection as evidence from the checked sources, not all customer feedback.

Create one observation per distinct problem. For each, record the attempted outcome, obstacle, consequence, workaround, and evidence source. Keep the customer's suggested feature in a separate field. 'Add a tutorial' may describe a request, while the underlying observation is that the customer cannot identify the accepted date format.

Use a small set of working codes with clear inclusion rules. For example, 'format guidance' includes reports where accepted input formatting is unclear; 'permission dependency' includes attempts blocked by access held by another person. Do not force every record into those codes. Keep an 'unclear' group and a clarification question when the source does not establish the problem.

Ask another reviewer to code a few borderline records, or reread them later if you work alone. Resolve disagreements by checking the wording and adjusting the definition. Preserve the earlier code when a correction matters to the conclusion. A codebook is a way to make reasoning consistent, not proof that the interpretation is objective.

In the fictional collection, six source records represent four incidents across three accounts. Two record pairs each repeat one incident; the other two records describe different incidents. Account A has two incidents, while accounts B and C have one each. Adding six records together as six affected customers would overstate the observed breadth.

Reading the four incidents reveals three about unclear date formatting, spanning accounts A and B, and one about missing permission in account C. The actionable themes are format guidance and permission dependency. They occur at the same journey step but require different responses. The customer request for 'a better import wizard' does not establish a single cause shared by all four incidents.

Report three format incidents from two accounts and one permission incident from one account. You cannot calculate the percentage of new customers affected without a compatible denominator. Even a denominator of all importing accounts needs care: people who contact support are a selected group, and unreported failures may be missing. Keep source coverage and observation limits beside the counts.

Compare the themes with the current product objective and delivery constraints. A repeated but minor inconvenience can deserve a different action from a single severe failure. Record the evidence, uncertainty, decision owner, and next check rather than turning the largest count directly into a roadmap commitment.

For format guidance, the team might test a visible accepted-format example and a clearer recovery message. Observe whether a new administrator can prepare a valid file without help. For permission dependency, first verify which role should have access and whether the handoff is explained. These are separate hypotheses, and either may be wrong once the task is observed.

Bring the findings into a weekly review with an owner and follow-up date. Keep investigation status separate from delivery status. After a change, revisit the same task with relevant users and comparable measurement rules. Record remaining problems, changes in the eligible audience, and unresolved coverage gaps; a before-and-after change alone does not prove causation.

Feedbackly can hold public-safe request summaries, comments, votes, and statuses. Its board dashboard searches request titles and descriptions within that board. Maintain private source references, working codes, cross-source counts, and this analysis in your internal document. Publishing a summary does not migrate confidential evidence or create native research fields.