How to categorize customer feedback: a taxonomy you can copy

Most support teams start tagging tickets with good intentions. A year later the helpdesk has 140 tags, half of them used twice, and “other” is the biggest one. Nobody trusts the numbers, so nobody looks at them.

That’s rarely a discipline problem. It’s the shape of the system. A flat list of tags asks one label to answer four questions at once. Which part of the product? What kind of feedback? How does the customer feel? How bad is it?

This guide keeps those questions apart. It ends with the exact default labels we ship in SignalScoop, so you can copy them, change them, or use them to audit the tags you already have.

Count signals, not tickets

One message usually says more than one thing. Take this support email:

That’s a bug and a feature request in one ticket. Tag the ticket and you pick one and lose the other. Tag it with both and your bug count now includes a ticket that is half a feature wish.

So count the statements inside a message instead. We call each one a signal. The email above holds two. A “thanks, all sorted!” reply holds none, and shouldn’t count toward anything.

The reverse also happens. A customer who mentions the same crash in three replies of one thread has reported one bug, not three. Count it once, at the message where they first raised it. Then let the latest message decide how urgent it is: a thread that went from “small thing” to “we can’t invoice anyone” got more urgent, not more numerous.

Give every signal five labels, not one tag

Tags like export-bug-angry multiply. Ten modules times seven types times three moods is 210 combinations, and no team applies 210 tags consistently.

Split the question into dimensions instead, and give each signal one value on each:

Now “angry export bugs from app reviews” is a filter, not a tag somebody had to invent in advance. You can ask questions you didn’t plan for, which is the reason to collect feedback in the first place.

The seven feedback types

These are the types every new SignalScoop account starts with. Each one comes with a one-line test, because a label without a test drifts.

Bug or complaint?

This is the line people argue about most. Ask whether the product does what it promises. If the export crashes, it doesn’t, so it’s a bug. If the export works but the customer finds it slow or ugly, it’s a complaint. The split matters because the two go to different people. Bugs go to engineering. Complaints go to product and design.

Complaint or feature request?

“Reports are slow” is a complaint about something that exists. “Let me export reports to Excel” asks for something that doesn’t, so it’s a feature request. Plenty of messages hold both, which is another reason to count signals.

Why cancellation gets its own type

It’s rare, and it hides. A renewal threat often sits in the fourth paragraph of an email about something else. As its own type it can trigger an alert instead of waiting for someone to read carefully.

Keep “other”, and watch it

Deleting “other” forces bad guesses. Keeping it lets you spot a missing type. If it grows beyond a small slice of your signals, read what’s in it. There is usually a new type in there waiting for a name.

Modules: use the customer’s words

Your module list should match how customers describe the product, not your org chart or your codebase. Customers say “the bank sync”, not “the reconciliation service”. A few rules that hold up:

• Two levels at most. Invoicing / Export is useful. Invoicing / Export / PDF / Line items is a tree nobody maintains.
• Start from real messages. Read a few hundred recent ones and write down every part of the product people mention. That’s your first list.
• Merge synonyms early. “Bank feeds”, “bank sync” and “the bank connection” are one module.
• Add, don’t dump. When customers keep bringing up something that fits nowhere, give it a module. That’s news about your product, not noise.

Sentiment and urgency are separate scales

A polite customer can report a disaster: “Hi, hope you’re well. Just a heads-up that none of our invoices have gone out since Tuesday.” Sentiment is neutral. Urgency is critical.

A furious customer can report a detail. Three paragraphs in capitals about a button colour is negative sentiment and low urgency. Merge the two scales and you end up prioritising whoever shouts loudest.

Three sentiment levels are enough: negative, neutral, positive. Five-point scales look precise, but two people rarely agree on “slightly negative” versus “negative”, and a scale nobody applies the same way is worse than a coarse one.

For urgency, use four levels and write an example next to each definition. Examples settle arguments that definitions start.

A worked example

Here is a four-star Trustpilot review, the kind that looks fine on a ratings dashboard. Split into signals, it’s four pieces of feedback:

As a star rating, that’s a 4 and nobody looks twice. As signals, it’s a bank-feed bug and a missed support target, sitting inside a happy review. If ten other customers mention the bank connection this month, the bug shows up as one line going up instead of eleven unrelated tickets.

Change labels without breaking your charts

You will rename things. When you do, apply the new labels to new signals only. Relabel history every time a definition changes and last quarter’s chart shifts under you, and nobody can tell a real trend from a relabel.

Once a quarter, go through the list. Merge types nobody uses, split modules that got too big, and check the size of “other”.

By hand or automatic?

By hand works when volume is low and one person does it. Once several people tag, their labels drift apart within weeks. Once volume reaches hundreds of messages a week, nobody splits messages into signals by hand any more. They tag the ticket and move on, and you’re back to one label per ticket.

A classifier applies the same definitions to every message, splits each one into signals, and doesn’t get sloppy on Friday afternoon. It still gets some wrong, so keep the taxonomy editable and spot-check it every week or two.

That’s what SignalScoop does. It reads messages from email, chat, calls and reviews, finds your product’s modules on its own, and labels every signal on the dimensions above. Paste a customer message below to see it work. Nothing you paste is stored.

Checklist

• Count signals, not tickets. One message can hold several, or none.
• Give every signal one value per dimension: module, type, sentiment, urgency, source.
• Start with seven types, and write down the test for bug versus complaint.
• Name modules in the customer’s words, two levels deep at most.
• Keep sentiment and urgency on separate scales.
• Apply label changes going forward only.
• Watch the size of “other”.

Want to test it on a batch of your own messages? The free feedback classifier uses the same taxonomy.