Build a voice-of-customer taxonomy around decisions your teams can act on. A taxonomy is a structured set of labels for classifying feedback. Give each label a clear boundary and examples before using theme counts to prioritize work.
Level AI describes emerging-theme discovery. Qualtrics describes quantified feedback-theme insights. Those features can help find patterns; neither description supplies the operating definitions your organization needs for stable reporting.
What should one theme represent?
Separate the customer's goal, the experienced problem, and the suspected cause. “Track an order,” “tracking information unclear,” and “carrier event missing” answer different questions. Combining them in one label makes it difficult to tell whether demand changed or the same task became harder.
Use a small hierarchy only when parent and child categories have a useful reporting relationship. Do not add a level simply because the software allows it. Permit more than one label when a contact contains distinct issues, and explain whether dashboard counts represent contacts, issue mentions, or customers.
Which fields make a label reviewable?
| Label field | Example of the required precision |
|---|---|
| Definition | A specific problem a reviewer can recognize |
| Include | Two or more representative supporting excerpts |
| Exclude | A similar case belonging somewhere else |
| Owner | Team able to investigate or change the process |
| Version rule | Date and reason for a split, merge, or rename |
Use short excerpts with their necessary context rather than isolated words. A mention of “late” might describe delivery, a prior response, or a customer's own delay. Reviewers need enough context to apply the same boundary consistently.
How should emerging themes enter the taxonomy?
- Keep an explicit other-or-unclear category.
- Review its examples alongside newly suggested clusters.
- Ask whether the proposed theme changes an operational decision.
- Test the new definition against both likely matches and close counterexamples.
- Approve an owner and version before including it in trend reporting.
Do not promote a generated theme name directly into a production category. A cluster can combine unrelated contacts that share vocabulary. Conversely, a useful issue may appear under several different expressions. Check the examples rather than approving the label's wording alone.
How should historical comparisons survive a change?
Record the old and new definitions and decide whether historical contacts can be relabeled consistently. If they cannot, mark a break in the series. A newly split category should not appear to have grown from zero simply because it previously lived inside a broader label.
Track the proportion of contacts that are unclassified or assigned multiple themes. An apparently cleaner dashboard can hide lost coverage if difficult examples disappear. For the next step, use the VoC action register; for stability over time, see trend comparability checks.
How should a theme split preserve a usable historical series?
Use an explicit crosswalk when a broad theme becomes two narrower ones. For this illustrative taxonomy, replace “delivery problem” with “tracking explanation unclear” and “delivery event missing.” The first concerns understandable information; the second concerns an absent event. Neither definition establishes the root cause without further evidence.
| Example wording | Proposed label | Boundary |
|---|---|---|
| “It says exception; what does that mean?” | Tracking explanation unclear | A confusing recorded status, even if the shipment is moving normally |
| “There has been no update since dispatch.” | Delivery event missing | Customer reports an absent expected event; verify against tracking history |
| “What day will it arrive?” | Delivery-status request | Ordinary information request without evidence of either problem |
Retain the old label, new label, definition version, supporting excerpt and any unresolved mapping. Backfill only records that contain enough context to apply the new rules. If old records are too sparse, mark the split date as a break and compare the stable parent theme rather than implying the new labels began from zero.
Test both likely matches and close exclusions with reviewers. Useful disagreement identifies a boundary to clarify; it should not disappear through forced agreement or silent relabeling.
Limits
This is a proposed label-governance method, not a validated universal taxonomy or a vendor classification benchmark. Useful categories depend on customer language, source coverage, workflows, and decision owners. Test definitions against actual examples and preserve ambiguity rather than forcing every contact into a confident label.