Taxonomy Best Practices

A taxonomy that mirrors how your customers actually describe their problems turns raw feedback into something your whole team can act on. The practices below will help you build one that stays useful as your feedback volume grows.

Organize around your customers' problems

Name your groups the way your customers would describe their own problem, not the way your team or product is organized internally. A good test: high-level (generally Level 1 and Level 2) group names should read naturally in the sentence "I have a [group name] problem," and low-level group names should be problem statements in and of themselves. Customers have “Software - Data - I can’t see my data” problems, not “Software Engineering - Data Engineering - Ingestion Pipeline” problems.

Get your top-level groups right early

Give your broadest groups (Level and Level 2) extra thought before you commit to them. They're the foundation for the dashboards and reports your team uses every day, so getting them right early pays off. In particular, L1 groups should be almost completely MECE (Mutually Exclusive, Collectively Exhaustive), and L2 groups should be close to MECE as well. 

Some amount of overlap is expected at lower levels because customers report multifaceted issues often, especially in long support conversations: a delayed shipment could have stemmed from a bounced payment. Lower coverage is more acceptable at lower levels because fewer low-level groups meet the volume bar that establishes utility. Lower level groups are also significantly easier to adjust, so refine those freely as you learn more about the dimensions of your feedback.

Keep groups precise and mutually exclusive

Write group names precisely enough that it’s clear which feedback entries belong in them and which don’t. Avoid combining two ideas into one group name with "and" or "or," and make sure the name matches what's actually inside the group. If you're ever unsure which group a piece of feedback belongs in, that's a sign the boundary needs sharpening. If a feedback entry is clearly about multiple issues, though (e.g. "I want a replacement because the battery keeps dying and the screen scratches easily"), it's acceptable for it to live in multiple groups at once.

Add narrow groups only when they offer real utility

Resist adding sub-groups with very low volume the moment a new pattern shows up. Only build more granular groups when they have a combination of sustained volume and distinct fix/resolution path. For example, don't carve out "Apple Pay Declined" from "Payment Method Declined" after seeing a single mention. Do carve it out, however, once Apple Pay issues are recurring, or if they clearly can be resolved differently from other payment failures.

Divide by what's most actionable

When you divide a group into sub-groups, choose whatever dimension is most useful for your team to act on (e.g. issue type, component, feature, or platform), rather than forcing every group to split the same way. A company organized around specific product features might divide by feature, since that's how customers describe issues and how work gets routed internally.

Keep sibling groups consistent

Keep sibling groups at the same level structured the same way where you can — if one divides by operating system, its neighbor should generally divide by a similar kind of dimension. This keeps your taxonomy easy to navigate and keeps side-by-side comparisons, like volume or trend by group, meaningful. Break the pattern only when the data is too thin to support it, or your team's workflow genuinely calls for something different.

Start from proven patterns

Start from group structures that seem like they would match other companies in your industry or segment, rather than designing from scratch. A wearable-device company, for example, likely sees hardware issues split cleanly by component: fit & finish, battery, connectivity, etc. For higher-level groups, starting from defensible patterns can help you feel less like you’re flying blind.

Use Custom Fields for cross-cutting details

When a detail applies across many groups, like platform, app version, or country, leverage it as a Custom Field rather than rebuilding the same split inside every relevant group. This keeps your taxonomy focused on your customers’ problems, while allowing you to filter, visualize, and create reports across the whole feedback corpus for the specific segment of interest.