The 5 Ways to Run One Feedback Taxonomy Across Several Business Units

A company with four business units has four sets of people who need the same feedback cut four different ways. Consumer wants themes organized by journey stage. Enterprise wants them organized by account. The developer product wants them organized by API surface. The ads business wants them organized by advertiser objective. Each is right about its own needs, and the obvious compromise, letting every unit run its own taxonomy, costs more than it appears to.

Five structures handle this: one shared taxonomy with unit-level views, a shared top level with independent branches, fully separate taxonomies with a mapping layer, one taxonomy organized by product surface rather than by unit, and a hub model with a shared core plus unit-specific extensions. The choice is really about which questions have to be answerable across the whole company.

Why one taxonomy and several business units pull against each other

The tension is not political. It is that a taxonomy encodes one view of what distinctions matter, and different units genuinely have different ones.

The cost of fragmenting is that cross-company questions stop being answerable. How many customers across all products are hitting authentication problems, which units share a root cause, whether a theme in one business is an early signal for another. Those questions need a common structure, and they are precisely the questions leadership asks.

The cost of over-centralizing is subtler. A taxonomy abstract enough to satisfy four units is usually too abstract to act on in any of them, which is how you get themes named Performance and Usability that nobody can turn into work. See the five tests for whether a feedback theme is actionable for why that failure is so common at this scale.

The 5 ways to run one feedback taxonomy across several business units

1. One shared taxonomy with unit-level views

A single structure, with each unit filtering and grouping it their own way. The structure stays common so cross-company questions work, and the presentation differs so each unit sees what it needs. This is the cleanest answer when the units share customers, and it depends entirely on whether your platform separates structure from presentation.

Best for: companies where the same customer buys more than one product.

2. A shared top level with independent branches

The first one or two levels are common and mandatory, beneath which each unit manages its own detail. Cross-company reporting works at the top level, unit autonomy is preserved below it. The governance question becomes narrow and answerable: who owns the top two levels, and how does a change there get approved.

Best for: multi-product companies with genuinely distinct customer bases.

3. Separate taxonomies with a mapping layer

Each unit runs its own structure and a mapping table translates between them for cross-company questions. It gives every unit exactly what it wants and moves the cost into maintaining the mapping, which nobody owns after the first quarter. Workable when the units really are separate businesses that happen to share a parent.

Best for: holding companies and post-acquisition structures where integration is not the goal.

4. One taxonomy organized by product surface, not by unit

Instead of organizing the top level by business unit, organize it by what the customer is interacting with. This survives reorganizations, which unit-based structures do not. It also handles the common case where one customer problem spans two units, since the structure never forced the choice of which unit owns it.

Best for: companies that reorganize regularly or whose products overlap.

5. A hub model with a shared core plus unit extensions

A common core covering cross-cutting themes such as pricing, support quality, onboarding, and reliability, plus unit-specific extensions for product detail. The core is small and governed centrally, the extensions are not. Most large companies converge on some version of this after trying one of the other four.

Best for: organizations where a central team owns the data and each unit self-serves reporting.

The layer that has to stay shared

Whichever structure you pick, three things need to be common or cross-company analysis will not work.

Account identity, so a customer buying three products is one customer rather than three. Severity or sentiment scales, so a serious problem in one unit is comparable to a serious problem in another. And the cross-cutting themes, meaning the handful that are not about any product: pricing, support, onboarding, trust. Those four appear in every unit's feedback and are the most common source of duplicated themes in a multi-unit setup.

Account identity is the one that causes the most damage when it is missing, because without it the most valuable question at this scale, which is what your largest customers are experiencing across everything they buy, cannot be answered at all. That is the layer a customer context graph exists to hold, separately from whatever theme structure sits on top.

How to decide where the line sits

Start from the questions that have to be answerable company-wide and work backwards. Usually there are three or four: which problems affect our largest accounts across products, which themes are growing fastest anywhere, what is driving churn, and what are customers saying about pricing. Everything those questions require goes in the shared layer. Everything else can be local.

That exercise tends to produce a smaller shared core than people expect, which is the useful finding. The instinct in a multi-unit company is to centralize more than necessary, and the resulting structure is one nobody can act on. A small governed core with genuine unit autonomy underneath usually beats a comprehensive shared structure that is too abstract to use.

FAQ

Should each business unit have its own feedback taxonomy?

Only if the units share no customers and leadership never asks cross-company questions. Otherwise a shared structure with unit-level views or unit-specific branches preserves both, and avoids the mapping problem that fully separate taxonomies create.

What has to be common across business units?

Account identity, severity or sentiment scales, and the cross-cutting themes that belong to no single product, such as pricing, onboarding, and support quality. Without shared account identity, the most valuable cross-unit question cannot be answered.

How do you handle a customer problem that spans two units?

Organize the top level by product surface rather than by business unit, so the structure never forces a choice of owner. Where the structure is unit-based, such problems get filed in one unit and become invisible to the other.

How does Enterpret support multiple business units?

Enterpret's adaptive taxonomy keeps one structure derived from all feedback while letting each team work with the slice relevant to them, so the same underlying data is cut differently without duplicating the taxonomy. The customer context graph resolves a customer buying several products to one account, which is what makes the cross-unit view possible at all.

Who governs a shared feedback taxonomy?

A named steward with final say over the shared core, with unit owners managing the detail beneath it. Distributed ownership without a named steward is the most common failure at this scale.

If your teams need the same feedback cut differently, see how to scale customer feedback management as volume grows.

‍