How to Categorize Customer Feedback (Worksheet + Examples)

Most teams try to sort feedback with a single label. That breaks down fast. One comment can be a bug report, feel calm, and still be the most urgent thing in the inbox. A polite feature request can matter far more than an angry complaint.

The fix is to stop looking for one label. Categorization is three separate layers, and each layer answers a different question:

Category — what kind of feedback is this?
Sentiment — how does the user feel?
Priority — what should you do about it, and when?

Keep the three in separate columns and the messy cases become easy. Squash them into one and every ambiguous comment starts an argument.

Layer 1: category (what kind of feedback)

Category describes the content, not the tone. FeedValue's documentation describes six AI category values. Use the same six, even if you tag them by hand:

Category	Use it when	Example
`bug_report`	Something is broken or does not behave as expected.	"Export does nothing with a date filter."
`feature_request`	The user asks you to add or change something.	"Please add SSO."
`praise`	The user says something positive, with nothing to act on.	"The new charts are great."
`complaint`	Dissatisfaction without a clear defect.	"The pricing page is confusing."
`question`	The user asks how something works.	"How do I rotate my API key?"
`general`	Anything that does not fit the five above.	"Just checking in."

The line between two categories is where most disagreement lives, so write down a tie-break rule for each pair:

bug_report vs complaint. A bug is a defect you could reproduce. A complaint is dissatisfaction, even strong dissatisfaction, with no broken behavior behind it. If you cannot point at a failing behavior, it is a complaint.
question vs feature_request. A question asks how to do something with what exists. A feature request asks for something that does not exist yet. "How do I export?" is a question. "Please add CSV export" is a feature request.
praise vs general. Praise carries positive evaluation. General is neutral filler. Praise is safe to archive once read.

Layer 2: sentiment (how the user feels)

Sentiment is tone: positive, neutral, or negative, matching the values FeedValue's documentation lists. It is the cheapest signal to collect and the easiest to over-read.

Two traps catch almost everyone:

Sentiment is not urgency. A calm, neutral message can announce a blocking problem. "We are unable to proceed with the rollout until SSO is available." That is neutral in tone and high in priority. If you use sentiment as your priority column, you will miss it.
Politeness hides severity. Users soften bad news. "It would be lovely if the report could finish" may mean the report never finishes. Read for the underlying issue, not the word choice.

Layer 3: human priority (what you do next)

Priority is your decision, not the user's mood. It combines how many people are affected, how badly, how central the area is, and how much work the fix costs. It is the one layer that a machine cannot set for you, because it depends on your roadmap and your constraints.

Keep priority in its own column. A simple high / medium / low is enough to start. When you want a repeatable score, a model like RICE (reach, impact, confidence, effort) gives you one. RICE was developed at Intercom and is documented by ProductPlan; if you adopt it, use their definitions rather than inventing your own. Scoring feature work is covered in our prioritization guide.

Separate urgent incidents from scored work. A defect that is blocking users right now does not belong in the same queue as a feature you are scoring for next quarter. Route incidents immediately and score feature work on its own cadence. Blending the two either buries the incident or distorts the score.

Where categorization gets hard: mixed and ambiguous comments

Real feedback is rarely clean. These are the patterns you will hit, and how to handle each.

Mixed comments (two issues in one message)

"The export fails, and by the way, please add scheduled exports."

Split it. One bug_report, one feature_request. Give each its own row. Note the split so you can trace both rows back to one source. Do not force a mixed comment into a single category; you will lose half of it.

Ambiguous category (fits two)

Pick the primary category for the row and record the second in a secondary_category column. Do not invent a combined label like bug/question. A combined taxonomy grows without limit, and no two people apply it the same way.

Sarcasm and understatement

"Great, another outage." is negative sentiment, not praise. Read intent, not keywords. When you genuinely cannot tell, record confidence low and keep triaging. It is better to flag one uncertain label and continue than to stall the whole queue on it.

Emotion-heavy messages

"You deleted my saved view!!!" Strong tone, weak content. Sentiment is clearly negative. The category is uncertain until you check whether a defect caused the loss. Mark it complaint or bug_report after a quick look, and prioritize it while you confirm.

The categorization worksheet

Download categorization worksheet (CSV)

It is a plain CSV. Import it into Google Sheets, Excel, or Numbers, then paste in your raw feedback. Columns:

Column	What it holds
`feedback_id`	A short handle for the row, so you can reference it later.
`original_text`	The user's words, unedited.
`primary_category`	One of the six categories.
`secondary_category`	The second-best category when a single comment genuinely straddles two. Blank otherwise.
`sentiment`	`positive`, `neutral`, or `negative`.
`human_priority`	`high`, `medium`, or `low`. Your decision.
`split_flag`	`yes` when this row is one half of a split comment. Never set it for a single comment that only fits two labels; record that in `secondary_category` instead.
`confidence`	`high`, `medium`, or `low`: how sure you are about the category.
`notes`	One line of reasoning. This is what keeps two people consistent.

The confidence, split_flag, and notes columns are the ones most teams skip, and they are the ones that keep the taxonomy honest. When you review next week, the notes tell you why the last person chose a category, and split_flag tells you which rows share one original comment.

Worked examples (fictional)

These rows are invented for illustration. They are not customer records.

feedback_id	original_text	primary	secondary	sentiment	priority	split_flag	confidence	notes
C-001	Export does nothing after I pick a date range.	bug_report		negative	high	yes	high	One half of a split comment. Reproduce on staging.
C-002	Also, could you add scheduled exports?	feature_request		neutral	medium	yes	medium	Other half of the C-001 split comment.
C-003	Honestly the new dashboard is fine I guess.	general		neutral	low	no	low	No action. Do not over-read.
C-004	Great product, but SSO is the only thing stopping us from rolling it out company-wide.	feature_request	complaint	positive	high	no	high	Single comment, two labels. Warm tone, real blocker.
C-005	How do I rotate my API key?	question		neutral	medium	no	high	Docs question. Consider an FAQ entry.
C-006	You deleted my saved view!!!	complaint	bug_report	negative	high	no	medium	Single ambiguous comment. Verify whether a defect caused the loss.
C-007	I love that reactions load inline with no popup.	praise		positive	low	no	high	Archive after reading.
C-008	The pricing page mentions a business tier but the upgrade button is missing.	question	complaint	neutral	medium	no	medium	Single comment, two labels. Question plus friction.

Two patterns to read off the table. First, split_flag is yes on both halves of a split (C-001 and C-002); a single comment that merely fits two labels (C-004, C-006, C-008) keeps split_flag as no and puts the second label in secondary_category. Second, sentiment and priority move independently: C-004 is positive and high priority, C-003 is neutral and low priority. That independence is the whole point of keeping the layers apart.

Keeping categories consistent over time

A taxonomy drifts when everyone applies it from memory. Three habits stop the drift:

Write the definitions once, including your tie-break rules, and keep them next to the worksheet.
Calibrate regularly. Have two people categorize the same small batch and compare. Ten comments is a reasonable starting point, but any batch you can both rate works; make it whatever size fits your team. Where you disagree, the definition is unclear, so fix the definition rather than the row.
Resist new categories. Every new label you add splits attention. Add one only when the six genuinely cannot hold a case, and only after the regular calibration keeps surfacing the same gap.

When a comment does not make sense

Sometimes you cannot act because the feedback is unclear. The right move is to ask, not to guess. Savio's triage guide describes a useful three-question routine: can you imagine solving this one day; does it make sense, and if not, ask the submitter for clarification; and which existing feature request does it map to? That is Savio's documented practice, not a description of FeedValue behavior. The idea is worth borrowing regardless of your tools: a clarifying question early is cheaper than a wrong priority later.

Where FeedValue fits

FeedValue's documentation describes assigning an AI category (bug_report, feature_request, praise, complaint, question, general) and a detected sentiment (positive, neutral, negative) per submission, and tracking each item through the new / read / resolved / archived status workflow. The docs describe category and sentiment arriving labeled; human priority is still yours to set, which is exactly the layer that should not be automated.

Those details come from FeedValue's current documentation. They describe what the docs state, not an independently verified result.

See how FeedValue organizes incoming feedback on the features page, or start free.

How to categorize customer feedback: category, sentiment, and priority