How to Categorise Ecommerce Customer Feedback: A Practical Taxonomy

An ecommerce feedback taxonomy is a shared set of categories that helps people describe customer issues consistently. Start with a few operationally useful groups, define what belongs in each, and test them against real authorised examples. Add detail only when it changes a decision or owner.

The taxonomy below is a suggested team framework. It is not a description of Outlined's built-in ticket categories, and it should not replace existing reporting definitions without a transition plan.

Separate topic, intent, and outcome

A topic describes what the conversation concerns, such as delivery. Intent describes the customer's task, such as asking for an update or reporting a problem. Outcome describes what happened, such as receiving an approved replacement.

Mixing these into one category list causes confusion. “Delivery,” “angry,” and “refunded” describe different dimensions. An agent should not have to choose only one when all three could be relevant.

Enterpret's category documentation is one example of separating feedback intention into defined groups. The ecommerce codebook here is our own suggested starting point.

Start with a compact codebook

Keep an “unclear” option with a review process. It is a useful quality signal, not a failure agents should conceal.

Define the unit of classification

Decide whether you classify messages, conversations, or individual issues. One thread can contain several issues. If a customer asks about delivery and later reports a broken item, forcing a single lifelong label loses important context.

Document how multiple topics affect reporting. Multi-label counts may sum to more than the number of conversations. A chart should explain that rather than presenting the percentages as mutually exclusive shares.

For a small team, begin with a primary topic and an optional secondary topic. Revisit the structure if reviewers consistently need more detail to assign an owner.

Test before rolling out

Select a modest, varied sample from your main channels, products, and issue types. Include short messages, images with unclear context, multilingual exchanges where your team can review them, and conversations containing more than one topic.

Have two authorised reviewers classify the same examples independently. Discuss disagreements and improve definitions. For example, “the wrong size arrived” may refer to fulfilment, while “the size I ordered does not fit” may concern expectations or measurements. The wording alone can be insufficient.

Do not claim a statistically representative accuracy rate from a convenience sample. Use the exercise to find missing rules and train consistent judgement.

Govern changes rather than accumulating labels

Assign a taxonomy owner. Require a proposed new category to state its decision, examples, boundary, and reporting impact. Consider whether an existing category can serve the purpose first.

When renaming or merging categories, retain a mapping and effective date. Historical totals can change because definitions changed, even if the customer experience did not. Do not compare a narrow new category with an older broad one without explaining the difference.

Review the exceptions monthly

Inspect unclear cases, conflicting labels, unused categories, and themes that keep being placed in “other.” Remove personal details from training materials. Keep access-sensitive tags subject to the workspace's visibility rules.

Your first deliverable should be a one-page codebook, a few annotated examples, and a named owner. Use the product complaint analysis workflow to test whether the categories lead to useful decisions rather than merely neater charts.