Feedback Classifier: organize bugs, requests, and questions
Sort product feedback into Bug report, Feature request, Praise, or Question. Distinguish broken promises from requests for new behavior.
Free preview limits apply. Sign in to use your credits and keep a decision history.
Your next decision starts here.
Add context above, or try an example to get started.
Classify the observation before deciding its priority
Feedback arrives through support conversations, research notes, and in-product messages. The same sentence can describe a missing capability or a failure of something you already promised. Use a consistent product definition to tell those apart. This tool proposes a feedback category, not a roadmap decision. Keep a link to the source and the relevant product version so someone reviewing a trend can distinguish repeated reports of one incident from independent requests for a new feature.
Work through the cases
Illustrative inputs and review guidance, not recorded model outputs. Run your own context to inspect a decision.
A missing acknowledgement
I click Save and nothing happens. There should be a message saying whether it worked.
Check whether the data was saved. If the documented save action fails, review it as a Bug report. If saving succeeds but the product has never offered a confirmation, it may be a Feature request. The wording alone cannot resolve an unknown product promise.
Praise wrapped around a failure
Great, the dashboard crashed again just before my presentation.
The word “great” does not make this Praise. The concrete observation is a recurring crash. Preserve the affected action and version for triage, and review sarcastic phrasing explicitly in your evaluation set rather than assuming sentiment words determine the feedback category.
A question that may reveal a defect
How do I export a PDF? The help page says there is an export button, but I cannot find it.
The customer asks a Question, but the mismatch with the help page may reveal a defect, a permission restriction, or outdated documentation. Include the plan and documented availability when relevant. If both tasks matter, keep the question linked to the investigation instead of losing it in one label.
Set the boundaries before you classify
Suggested review rules for these options. Include the rules relevant to your team in the question or context when you run a decision.
| Choice | Use it when | Check the boundary |
|---|---|---|
| Bug report | Observed behavior contradicts a supported, documented product behavior. | An unsupported expectation alone does not establish a defect. |
| Feature request | A request for a new capability or a change to existing behavior. | “I wish it worked” may describe a broken existing feature; check the promise first. |
| Praise | A favorable evaluation without a primary unresolved issue or request. | Positive wording can be ironic or accompany a substantive complaint. |
| Question | A request for information about using or understanding the product. | A question can expose a bug that warrants a linked follow-up. |
Where to take a closer look
Counting a release incident as many feature requests
Retain the release, affected workflow, and a source reference. Deduplicate repeated reports before comparing volumes, or a single failure can make a category appear more representative than it is.
Losing nuance across languages
Mixed-language feedback, sarcasm, and local shorthand deserve separate review samples. Preserve the original message if you add a translation. Do not assume that a translated sentence carries exactly the same intent.
Measure category quality before trusting the trend
For reporting, review a sample from every category and measure which pairs are confused. Systematic confusion between bugs and requests can distort planning even when an individual mistake seems cheap. Review uncertain cases rather than assigning a universal low threshold to all feedback.
Keep severity, affected customers, and strategic value outside this classification score. A rare accessibility defect can matter more than a frequent cosmetic request. Category counts describe the inbox; they do not settle the roadmap.
A Jev API example for your next integration
Call the iajev REST API with cURL. Receive a choice, probabilities, and confidence as JSON.
curl https://iajev.com/api/v1/decisions/run \
-H 'Authorization: Bearer YOUR_API_KEY' \
-H 'Idempotency-Key: YOUR_UNIQUE_REQUEST_ID' \
-H 'Content-Type: application/json' \
--data '{
"state": {
"message": "It would be useful to export my weekly reports as a PDF and share them with my team."
},
"decision": {
"type": "choice",
"question": "What kind of customer feedback is this?",
"choices": [
"Bug report",
"Feature request",
"Praise",
"Question"
]
}
}'Questions about this tool
Can one message have two feedback categories?
Yes, although this tool returns one selected choice. Split independent observations into separate inputs when your workflow needs both categories. Keep their common source reference so a question and its associated bug are not treated as unrelated customers.
Should anonymous feedback be classified separately?
Use the same category definitions. Record provenance separately when you need to assess duplicates or follow up. Knowing someone’s identity should not turn the same broken workflow into a different type of feedback.
Using iajev
Add context
Include the facts needed for this decision.
Review the choices
Customize the question and options to match your workflow.
Run and review
Inspect the distribution before taking action.
Is confidence the probability that a decision is correct?
No. Confidence is a separate model estimate; the choice probabilities describe the distribution over your options. Neither is a measured accuracy guarantee.
Can I compare two inputs?
Edit the context and run the same question again to compare probabilities. Changing the question or choices starts a new comparison.