Bug report vs feature request: what's the difference?

What makes something a bug report?

A bug report describes behavior that is wrong by the product's own standard. The standard can be written in the docs, promised in the interface or obvious from how the rest of the product works. The customer expected one result, got another, and the gap is a defect.

Typical bug reports look like this: a button saves nothing, a total is off by one day, a page shows another customer's name, or a file export drops the last column. Each one has an expected behavior that the product already claims, even if nobody wrote it down.

What makes something a feature request?

A feature request asks for behavior the product does not have. Nothing is broken. The customer wants the product to do something new, or to do an existing thing in a way it has never done.

Examples include a request to export to a spreadsheet format the product never supported, a request for a dark theme, or a request to schedule a report. The product is working as designed, and the question is whether the design should change.

The distinction is simple to state and harder to apply. A bug is a gap between what exists and what was promised. A feature request is a gap between what exists and what would be useful.

What about missing behavior and friction?

Gray areas appear when something is not broken but feels wrong. Two cases come up most often.

Missing behavior sits between the two. A customer says "the export does not include archived projects". If the docs say the export covers all projects, it is a bug. If the docs are silent, it is a feature request with a bug-like tone.

UX friction is usually a feature request in disguise. "The save button is hard to find" does not describe a defect. It describes a design that could be better. Treat it as an idea, and read the message for the real problem before deciding what to change.

When you cannot decide, ask. A short question such as "what did you expect to happen?" usually answers the question for you.

Why does the label change the response?

The label decides the path an item takes. A bug goes to reproduction, a fix and a release note, and it usually has a short deadline. A feature request goes to a decision about fit, cost and direction, and it can wait for a planned cycle.

The labels also shape what you tell the customer. For a bug, you can say you are reproducing it and will confirm the fix. For an idea, you can say you have recorded it, without implying a date. Mixing the two causes trouble. Calling a bug an idea sends a broken feature into a backlog, and calling an idea a bug sets an expectation you cannot meet.

Should customers pick the type?

Customers pick the type when they send a message, and that choice is useful even when it is wrong. The Escuta Produto widget offers four types: bug, idea, praise and other. You can preselect one from the entry point, such as a "report a problem" link that opens with bug selected.

Treat the customer's choice as a hint, not a decision. Read the message, check the page URL and decide yourself. Keep the type the customer chose as the record of what they reported, and write your reading of the item in an internal note and in the status you set.

How do you handle a message that is both?

Many messages are a bug and a request at once. "The chart does not show last month, and I wish I could compare two months" contains a defect and an idea. Split them into two internal notes, handle the bug first and record the idea as a separate decision.

If you cannot split a message cleanly, handle the defect and file the rest as an idea. Customers rarely mind when you fix the broken part first.

How do you sort both types in Escuta Produto?

Filter the product inbox by type to see bugs and ideas separately, then work the bug list first. Use the page URL and browser saved on each bug to reproduce it. For ideas, search the inbox for the same words to find repeats, and read the triage guide for how to rank them.

If a bug turns out to be a missing feature, change your internal note, not the type the customer chose. Keep the record of what the customer reported, so the history still makes sense later. For the widget options that preselect a type, see the widget documentation. For a fuller definition of the form itself, read what a feedback widget is.