When feedback about the same issue is scattered across countries, languages, support channels, and meeting notes, teams can mistake a paraphrase for a customer's words, count repeated messages as many customers, or dismiss an uncommon exception. The goal is not a polished chart first. It is to connect each comment to context, compare theme boundaries, and distinguish frequency from impact. Keep each conclusion traceable to its source so colleagues can review it and revise it when new information arrives.
How should you record feedback sources?
Separate what the customer said from how the team interprets it. Give each item a traceable ID and record the original wording, date and time zone, channel, customer's market, language, customer or account code, workflow involved, and whether the speaker was a decision-maker, operator, or spokesperson. Use a team-recognizable code instead of directly identifying a person, and do not copy names, credentials, or full conversations into tables that do not need them.
Preserve context: what was discussed just before the comment, what step the person took, and the environment where the issue occurred. Add a neutral summary separately. “After completing payment, I could not find the next status” describes an observation; “the customer does not understand the process” judges the person. Categorize the problem, not the customer.
For example, if Taiwan support forwards an English email saying, “The page keeps sending me back,” do not immediately label it a login failure. Record which page and actions were involved, whether it happens every time, what the customer expected, and whether the person relaying the message tried the workflow. Set the market from where the customer operates, not where support is located. Mark unknown details “unconfirmed,” and version summary updates with the editor's judgment.
Agree on field definitions before combining channels. A useful minimum is source, date, language, market, context, original wording, summary, and status. Mark missing details in older records unknown instead of guessing. If one conversation raises several issues, make separate records with a shared conversation ID. Keep the original wording accessible so classifications can be corrected; a dashboard can come later.
How can you preserve meaning in translation?
Translate to help the team understand the customer, not to make the customer sound more polished. Never overwrite the original. Keep separate fields for a close translation, a readable summary, and ambiguity notes. Preserve negation, degree, timing, conditions, and uncertainty: “It gets stuck sometimes” must not become “the system is unusable,” and “I think it happened after the update” must not become a confirmed cause. Retain vague words such as “strange” or “inconvenient” with context rather than choosing a technical term too soon. Flag phrases that may be sarcastic, honorific, or industry-specific.
A shared-language summary helps comparison, but keep observation apart from interpretation. “I can’t see it anymore after switching account” might be translated as “After switching accounts, I can no longer see it.” A neutral summary is “An item is not displayed after switching accounts.” Name the item only after confirming whether “it” means an order, report, or setting. Saying the switch “caused data loss” turns sequence into causation without evidence. For incomplete messages, preserve the source fragment and list what needs confirming.
Have someone familiar with the language or market review the original and context before merging themes. If none is available, mark the translation as an initial machine or non-native version pending confirmation; translation tools can help draft, but their output is not confirmation. Keep the version, date, editor, and ambiguity notes. If a translation changes apparent severity or assigns responsibility, get a fluent reader to confirm it before adding it to the theme list.
How should repeated feedback be combined?
Combine records when they describe the same work problem, not just when sentences look alike. Ask what the customer wanted to do, where the obstacle appeared, what result they saw, and what workaround they used. If the answers broadly match, group the items provisionally. If the task is the same but the stage differs, keep subthemes until more records clarify whether they share a cause. Name themes as problems, such as “Existing orders are hard to find after switching accounts,” rather than broad labels or unconfirmed root causes.
Link each original item to one primary theme and use secondary tags only when helpful. Compare the object, action, timing, and exceptions across languages: “I can’t find it” might mean search returned no results, while “I can’t see it” might mean the person lacks permission. If the distinction is unclear, mark the item “unclassified” and state what differs. A keyword match in translation cannot replace judgment.
Deduplicate repeated retellings separately from new occurrences. If one customer sends the same screenshot to support and mentions the incident in a meeting, link both reports to one incident ID and count one customer and incident. If the customer tries again the following week and encounters the problem again, add a new incident linked to the theme. Count an affected company and its individual users separately. For each merge, record the theme definition, inclusion and exclusion criteria, and reason. If a theme is later split, keep its former ID and change history so earlier counts remain interpretable.
How should you preserve counterexamples?
A counterexample can improve a theme's boundaries. Do not delete it because it contradicts a common description, or treat it as proof that the common problem does not exist. Link it to the original comment and record its market, language, user role, plan version, environment, and conditions. Ask whether the difference follows a pattern, such as permissions, device, or user familiarity. If a condition is unknown, say so instead of calling the comment an isolated case.
Imagine that most comments say the export workflow is hard to find, while one customer says its location is clear. Preserve both and compare whether the customer used a newer interface, had administrator permissions, or received training. If the contrary observation clusters among trained users, narrow the theme to “first-time users cannot find the entry point.” If role and version match, check for another navigation path or an error in how the feedback was relayed. This is a classification example, not a product finding.
Label records as supporting, counterexample, or unresolved, but do not treat those labels as proof of cause. State which assumption is challenged, such as whether an issue is widespread or happens only on a first attempt. Show important counterexamples beside the theme summary. When the theme changes, revisit earlier records and retain both definitions with the reason for revision. This keeps minority observations visible without letting one contrary comment erase other customers' difficulties. State which situations the sample covers.
How should you assess frequency and impact separately?
Frequency answers how many people and events were involved; impact describes what happened as a result. Do not combine them into one score. Before counting, choose the observation period, sources, and deduplication rules. Count distinct customers, users, incidents, and messages separately. One customer may send several emails; several operators at one company may each be blocked. If the records cover only support emails, say “in the support emails reviewed,” not every market. Do not calculate percentages without a reliable total-customer or usage denominator.
Assess impact by observing whether the task stopped, whether there was a workaround, whether extra time or rework was needed, whether an important decision was affected, and how long the issue continued. Use observable descriptions such as “prevents completion,” “adds steps,” or “causes confusion.” The table is a wholly hypothetical sample from one month: three themes, eight distinct customers, and fifteen mentions. These figures illustrate separate fields; they are not survey results.
| Hypothetical theme | Distinct customers | Mentions | Observed impact |
|---|---|---|---|
| Returned to the original page after login | 4 | 7 | Two people were temporarily unable to complete the task |
| Field labels are hard to understand | 3 | 3 | People could continue, but needed to ask a colleague |
| Export format does not fit the workflow | 1 | 5 | One specific workflow required manual reorganization |
Read the table by checking whether high impact is concentrated among a few people, then whether affected customers or incidents are increasing. Five mentions do not mean five customers. For prioritization, group themes as repeated and high impact; high impact but few cases; frequent but easy to work around; or insufficient information. Use these groups to prompt investigation, interviews, or continued observation. Record why each theme was placed there and recalculate when new records are available.
Which conclusions still need interviews?
Interview when records cannot answer a question that could change a decision. Signals include an unclear reference, unknown context, opposite descriptions under one theme, only secondhand reports from support, or disagreement about “frequent” or “severe.” Turn each gap into a concrete question. If someone says “I cannot see it,” is there no entry point, or does the person lack permission? Then choose the user group, market, or workflow stage most likely to answer. Sparse data alone does not require interviews; improve the record first if the answer would not change the next step.
Invite people with different outcomes: someone who had the problem, someone who completed the task smoothly, and someone who switched to a workaround. Start with a recent experience: “What were you trying to do? What did you do next? How did the page or process respond? What did you do afterward?” Ask about language, role, environment, and expected result. Avoid leading questions such as “Did you find the workflow difficult?” Ask the person to describe or demonstrate the steps. Record a possible new cause as a hypothesis instead of rewriting original feedback. Explain the purpose and note-taking approach, collecting sensitive details only when needed.
Afterward, link notes to the theme and mark what adds support, weakens an assumption, or remains unresolved. Record participant conditions so one market's experience is not mistaken for a shared answer. If an interview changes a theme boundary, keep the reason and revisit older records with matching conditions. A practical start is to select one higher-impact theme, write one unanswered question and two plausible situations, identify the user roles to invite, and update the issue list after the first conversations. For more information about Chan & Chung, visit the official English homepage.