Bug report vs support ticket: how to tell them apart

The same message can be a bug report or a support ticket depending on one thing: whether the software behaved incorrectly. "I can't download my invoice" is a defect if the button is broken and a support question if invoices only appear after the first payment.

Sorting incoming messages correctly matters because the two need opposite responses. A support ticket needs an answer to a person. A bug report needs a change to the source. Treating one as the other wastes the effort and leaves the original need unmet.

What is the actual distinction?

Ask a single question: did the system do what it was built to do?

If yes, and the visitor still could not achieve their goal, it is a support matter — or a design problem, which is a third category worth naming. If no, it is a defect.

That question is harder than it sounds, because it requires knowing the intended behaviour. Nobody can classify "the total looks wrong" without knowing how the total is supposed to be calculated. This is why classification should follow a quick check against intent, not precede it.

Three practical categories cover almost everything:

• Defect. The software produced a result it should not have produced.
• Question. The software worked; the person did not know how to reach their goal.
• Suggestion. The software worked as designed; the design should be different.

A fourth category is worth adding once you see it a few times: unclear, meaning you cannot classify it without more information. Naming it prevents the far worse habit of guessing.

Why does misclassification cost so much?

Misclassifying in either direction is expensive, in different ways.

A defect treated as a question produces a workaround for one person while the defect stays in production. Everyone else who hits it either finds the same workaround, contacts you again, or leaves. The report count grows while the cause never gets examined.

A question treated as a defect starts an investigation into code that is behaving correctly. Someone reads the source looking for a fault that is not there. The investigation ends in confusion, and the visitor — who only needed one sentence of explanation — is still waiting.

A suggestion treated as a defect is subtler and common. Someone "fixes" behaviour that was deliberate, which can break the case the original design accounted for.

How do you classify quickly?

Read the message for three signals.

Expectation language. "I expected X but got Y" points toward a defect. "How do I do X?" points toward a question. "It would be better if X" points toward a suggestion.

Error evidence. A visible error message, a failed request, or a browser console error is strong evidence of a defect. Their absence is weak evidence of anything, because plenty of defects fail silently.

Consistency. "It used to work" points strongly at a defect, and usually a recent one — that phrase is worth escalating on its own, because it implies a change in behaviour rather than a persistent misunderstanding.

When the signals conflict, check the intended behaviour before classifying. One minute confirming what the feature is supposed to do prevents a day of investigating the wrong thing.

Where do the two paths diverge?

Once classified, the work is genuinely different.

A question needs a clear answer to a person, and ideally a note about why the question arose. Repeated identical questions are a design signal — the interface is not communicating something, and that is worth fixing even though nothing is technically broken.

A defect needs reproduction, then investigation against the exact source that was running, then a fix and a test. It should end with a specific source location and an explanation, or with an honest statement that the cause is unknown and what was ruled out. See what makes a bug reproducible for the shape that makes this possible.

A suggestion needs recording and grouping, not investigation. Its value appears over time, when several suggestions turn out to describe one underlying gap.

Should visitors classify their own reports?

Partly. Asking a visitor to choose between "something is broken" and "I have an idea" is reasonable — they know which one they mean, and the choice is meaningful to them.

Asking them to assign severity, or to distinguish a defect from a configuration issue, is not reasonable. That requires knowledge of the system they do not have, and a wrong self-classification is worse than none because it anchors the reader.

The practical middle ground: let the visitor pick a coarse type, collect the observable context automatically, and let a human confirm the classification on first read with the evidence in front of them.

Where IssueProbe fits

IssueProbe asks the visitor for exactly the coarse distinction they can make: a problem or a suggestion. The widget is available in English, Portuguese, and Spanish, and the visitor needs no account.

Alongside the description, the safe observable context is collected — the page path, failed or slow request metadata, bounded and redacted console errors, and metadata-only browser state that records names, presence, and approximate size but never values. A screenshot is included only after a visible capture action, a preview, and explicit consent, and the visitor can remove it before sending.

An eligible problem report can then start one isolated, read-only investigation against your repository at the deployed commit. The result cites specific source locations, separates important unknown facts from conclusions, and recommends an action, or states plainly that the cause is unknown when the evidence does not support one. A human reviews the result and edits the draft response before it is used anywhere. IssueProbe is not a help desk and never emails visitors.

Read next: how to triage user-reported website issues for ranking what you have classified, and the example report for the reviewed result format.