If the product did not do what it is meant to do, the message is a bug report. If it did what it is meant to do and the user wants something else, it is a feature request. Four questions sort most messages in under a minute.
Four questions
Did it work before, or is it meant to work this way? A change from earlier behavior points to a bug.
Does the product already promise this? If a page, a help article or a plan says it should work, a failure is a bug.
Is the user describing a result or asking for a new ability? "The export is empty" is a result. "Let me export to CSV" is an ability.
Would fixing it change what the product does by design? If yes, it is a feature request, even when the user phrased it as a complaint.
Messages that are neither
Some messages are questions: "Where do I find my invoices?" Some are feedback: "The new page is easier to read." Neither needs a ticket. A question may point to a gap in the page, and feedback is worth reading when a pattern forms, but treating either one as a bug adds noise to the queue.
Messages that are both
"The export is slow and should be a spreadsheet" holds a bug and a feature request. Split it. The slowness gets a Case. The spreadsheet request joins the Idea for exports. One message can feed two lists as long as the original stays attached to both.
When you cannot tell
Ask. One short question to the sender, sent on the channel they used, usually settles it. Label the message "needs clarification" until it does, so it does not sit in the wrong list.
Mobius labels each message as a bug, a feature request, a question or feedback, shows its confidence, and drafts the clarifying question when the label is unclear. A person confirms or changes the label, and the change is saved.