Feature Request or Bug? How to Triage Support Tickets Before Engineering

A support ticket is a bug when it has a reproducible path, a gap between expected and actual behavior, and the behavior is unintended. A feature request describes something the product was never designed to do. Between the two sits a category most triage processes miss: the code-actionable feature request, a specific change to existing behavior that a developer could make without a design meeting. Sorting tickets into those three buckets, plus "not for engineering," before anything is escalated is what keeps engineering queues trustworthy.

Why mixed inboxes hurt both teamsCopy Anchor Link

A Zendesk, Intercom or Freshdesk queue mixes everything: billing questions, account-access requests, onboarding confusion, feature wishes and real defects, all in the same view and all in the same urgent tone. When the handoff to engineering has no qualification step, anything that sounds technical gets forwarded, and the cost lands everywhere:

• Support spends escalations on tickets that come back as "works as designed."
• Engineering spends senior triage time decoding tickets that were never bugs.
• Customers with real bugs wait longer, because their tickets are buried among the rest.

None of this is support getting it wrong. Bug-or-not is a judgment call from prose, usually made under queue pressure by someone without access to the codebase. The fix is to make it a test rather than a judgment.

The structural test: three questionsCopy Anchor Link

A ticket is a bug when all three are true:

1. There is a reproducible path. A sequence of steps, a payload, a user action or a state that reliably (or intermittently) triggers the problem. Without it there is nothing to reproduce and nothing to verify a fix against.
2. There is an expected-vs-actual gap. You can write the triple: "When I do X, the product does Y, but it should do Z."
3. The behavior is unintended. A user hitting a plan limit, a permission boundary or a documented constraint is not experiencing a defect.

Each non-bug category fails in a recognisable place. How-to questions fail the first: nothing is broken, the customer just did not find the path. Feature requests fail the second: they describe desired future behavior, not a violation of current behavior. Billing and plan questions usually fail the third.

The customer's label does not matter. "This is broken" and "I wish this worked differently" can describe identical behavior; the test reads the substance, not the framing.

The third category: code-actionable feature requestsCopy Anchor Link

Take two tickets:

• "When I export a report, the CSV always includes a header row. I need to turn it off for my import tool."
• "It would be great if the export page had more formatting options."

Neither is a bug: nothing violates the current design. But they are very different pieces of work. The first names a specific behavior in a specific place and a specific change; a developer could open a pull request today. The second names a direction and needs a product conversation first.

Treat the first kind like a bug for handoff purposes. Collapsing it into the open-ended pile wastes the specification the customer already did for you. Collapsing it into the bug queue inflates your defect counts.

Code-actionable (send to engineering):

• "Add the account tier to the webhook payload so our automation can filter on it."
• "The CSV export should keep the column order I set in the table view."
• "Let me scope an API token to read-only so I can share it with a contractor."

Open-ended (send to the product backlog):

• "Onboarding feels confusing. Can you make it simpler?"
• "I wish there were more integrations."
• "The UI could feel more modern."

The test: could a developer write an issue specific enough to open a pull request from it, without asking anyone what is wanted?

What getting it wrong costs, in both directionsCopy Anchor Link

Feature requests filed as bugs send an engineer to reproduce behavior that is working as designed. They ask support for clarification, wait, and eventually close it as "by design" or start a design conversation that belonged in product review. They also contaminate your metrics: a severity-1 count that includes "the button doesn't do what I want" is no longer a measure of stability, and teams use that number for staffing and SLA decisions.

Bugs filed as enhancements never trip an SLA alert. They sit in the backlog until the customer escalates again, by which point the reproduction context has gone stale and the bug has to be rebuilt from scratch.

Code-actionable requests dropped as "not a bug" lose real product signal. If several customers ask for the same specific change and each ticket is closed individually, the pattern never reaches anyone who could act on it.

What a qualified bug looks like on its way to engineeringCopy Anchor Link

Once a ticket passes the test, it should cross to engineering as a structured record rather than a forwarded conversation:

• Title: an engineering-readable summary, not the customer's subject line
• Severity: based on impact (how many accounts, which workflow), not tone
• Repro steps: numbered, reconstructed from the conversation
• Expected behavior and actual behavior as separate fields
• Customer impact: scope and business weight
• The customer's original words, verbatim, including error messages

Two things make this harder than it looks. Customers rarely write "Steps to reproduce: 1." They write a frustrated paragraph, so the steps have to be reconstructed; if they genuinely are not in the thread, the right move is to ask the customer, not to forward a half-formed bug. And duplicates hide scope: five tickets about the same defect are one bug with five affected customers, and that count changes how engineering prioritises it. Our guide to escalating a support ticket to engineering covers the handoff itself.

What to do with tickets that are not bugsCopy Anchor Link

Failing the bug test does not make a ticket worthless. It makes it someone else's signal.

• Feature requests that cluster are product input. If many customers ask for the same capability in a month, that belongs in front of a PM with the count attached.
• How-to questions that repeat point at a documentation or UX gap. That is a real defect, just not a code defect.
• Billing or plan confusion that spikes is worth flagging to finance and product even when no software is broken.

The goal of triage is not to discard tickets. It is to send each one to the owner who can act on it.

Don't pre-filter before the test runsCopy Anchor Link

One habit quietly breaks all of this: agents escalating only the tickets they personally believe are bugs. That turns a consistent test back into individual judgment, and it hides duplicates, because the tickets that would have shown a pattern were never compared. Apply the test to everything that might be engineering's, the same way every time.

How Watari applies the test at intakeCopy Anchor Link

Applied by hand to a busy queue, this is a full-time job. Watari runs it on every ticket that reaches it from Zendesk, Intercom or Freshdesk. It reads the whole conversation and its attachments, and extracts a structured record that includes an item type (bug or feature request) and, for feature requests, whether the request is code-actionable, alongside severity, repro steps, expected vs. actual behavior and the customer's verbatim words.

Tickets that hold nothing to file (a how-to, a billing query, an account change) are listed under Issues → Not filed with the reason, so nothing disappears silently, and an owner or admin can re-run extraction if a call looks wrong. Extractions that are not confident enough are held for human review rather than guessed. Bugs and code-actionable feature requests then go through the same second gate, a confident match to specific files and functions in your code, before they become a Mapped Issue with a draft pull request and an issue in Jira, Linear, GitHub Issues or Azure Boards.

Code-actionable feature requests that qualify are metered the same way as bugs; see the Mapped Issue meter. Open-ended requests and non-bug tickets never are.

---

Bug versus feature request is a structural question, not a judgment call: a reproducible, unintended gap in existing behavior is a bug; a specific change to existing behavior is a code-actionable request; everything else needs a different owner. Apply that consistently before escalation and engineering stops triaging tickets that were never theirs.