Support ticket severity: stop low-priority noise from burying real bugs

Customer-reported severity and engineering-relevant severity are structurally different signals. A customer marks a ticket "urgent" because they're frustrated; that label says nothing about whether the bug is reproducible, affects more than one account, or touches a code path your engineers can actually fix. The result is a Zendesk or Intercom queue where a billing question sits at P1 and a silent data-loss regression sits at P3 — and your senior engineers spend Monday morning triaging noise instead of shipping.

Why gut-feel severity classification fails at scale

Severity assigned by customer loudness is not a signal — it is an amplifier of whoever complains most persistently. A single enterprise customer who sends five Intercom messages in an hour will escalate a cosmetic bug to your engineering queue faster than twenty self-service users silently hitting a checkout failure. That is not a triage process. That is a loudness contest.

The structural problem is that customers and engineers are answering different questions when they assign severity:

• Customers answer: "How much does this affect me, right now, emotionally?"
• Engineers answer: "Is this reproducible? What is the error type? How many users are affected? Is there a code location I can point to?"

Those two questions share almost no information. A customer saying "URGENT" tells you nothing about repro steps, expected-vs-actual behavior, or affected user count — the three fields an engineer needs to decide whether to drop everything or schedule the fix for next sprint.

The consequence is measurable even if the cost is invisible: engineering triage meetings fill with tickets that should never have left the support queue. Every senior engineer who spends twenty minutes confirming that a "P1" is actually a feature request is twenty minutes not spent on a genuine incident. Over a quarter, that compounding cost dwarfs whatever time a better Jira label scheme might save.

Structured extraction is the only consistent severity signal

The fix is not better Slack etiquette between support and engineering. It is not a new Jira field. It is extraction: pulling structured fields from the free-form ticket before any human makes a routing decision.

A structured bug record includes at minimum:

1. Severity — inferred from error type, user impact, and conversation pattern, not from the customer's word choice
2. Repro steps — extracted from the ticket thread in order, with author labels
3. Expected vs. actual behavior — the engineering-readable framing, not the customer's frustration narrative
4. Affected user count — derived from ticket metadata and any duplicate signals
5. Error type — crash, data loss, performance degradation, UI glitch, or billing discrepancy

When these fields are populated consistently — not by whichever support agent happened to write the ticket, but by an extraction step that reads the full conversation thread, screenshots, and attachments — severity becomes a function of the bug's properties, not of who reported it or how loudly.

This is what Watari's ticket-to-bug pipeline does. When a ticket arrives from Zendesk or Intercom via webhook, the extraction model reads the subject, body, full conversation thread (in order, with timestamps), and any attachments, then produces a structured bug record with those fields. The extraction step produces a confidence score alongside the structured record. A low-confidence extraction — one where the ticket didn't contain enough signal to reliably populate repro steps or identify an error type — does not proceed. It routes to a human review queue instead. See the ticket-to-bug pipeline docs for the full field list and what triggers manual routing.

The consistency this produces is the point. Whether the ticket was written by a technical user who included a stack trace or a non-technical user who wrote "the app broke," the extraction step applies the same logic and produces comparable severity signals. That comparability is what makes the queue sortable by actual engineering priority rather than by ticket age or customer tier.

Confidence-gated routing: turning severity into a gate, not a feeling

Structured extraction gets you a consistent severity signal. Confidence gating is what turns that signal into a routing decision your engineering team can trust.

Watari uses two independent confidence gates before a ticket becomes a Mapped Bug — the unit that surfaces to your engineering queue and fires the billing meter:

1. Extraction confidence — the structured bug record is high-confidence: repro steps, expected-vs-actual, and error type all populated with sufficient signal from the ticket.
2. Code-location confidence — at least one file and function in your GitHub repository matched the bug description with high confidence, using tree-sitter-parsed code chunks and a pgvector HNSW index.

Only when both gates clear does the bug reach your engineering queue, generate a draft pull request, and sync to Linear or Jira. A ticket that passes extraction but fails to map to a code location does not become a Mapped Bug — it waits or routes to human review. A ticket that maps to code but whose extraction confidence is low does not proceed either.

This double gate is the mechanism that protects senior engineering triage time. It is not a Slack etiquette policy. It is not a "please fill in the template" request to your support team. It is a structural filter that every ticket passes through before it touches your engineering queue.

The threshold itself is tunable. If your team wants higher precision — fewer Mapped Bugs, each one very high confidence — you can raise the extraction confidence threshold in Settings → AI Behavior. If you want higher recall — more bugs surfacing for human review, with the confidence gate set lower — you can adjust that too. The AI behavior controls docs cover the full set of tunable parameters. All changes apply to future tickets only; they don't retroactively re-promote or re-demote bugs already in the dashboard.

CODEOWNERS-driven routing adds a second dimension. Once a bug maps to specific files in your GitHub repository, Watari reads the CODEOWNERS file to identify the responsible team or individual. The draft PR routes to the right reviewer automatically — not to a generic engineering Slack channel where it will compete for attention with six other notifications. That routing is configured through the routing and notifications docs.

What this means for the support-to-engineering handoff

The practical change is architectural, not behavioral. You are not asking your support team to write better tickets. You are not asking your engineering team to be more patient with noisy escalations. You are inserting a structured extraction and confidence-gating layer between the two queues.

The support team's job stays the same: respond to customers, collect information, keep tickets updated. The extraction step runs in the background on every ticket that arrives via the Zendesk or Intercom webhook. Support agents do not need to change their workflow. Tickets they would have escalated manually still get escalated — but now with structured fields populated and a confidence score attached.

The engineering team's queue changes materially. Instead of a mix of feature requests, billing questions, genuine bugs with no repro steps, and one or two actual critical regressions — all labeled P1 by frustrated customers — they see only bugs that passed both confidence gates. Each one has repro steps, expected-vs-actual behavior, a severity inference, and a draft pull request already opened against the right file and function in GitHub.

The triage meeting becomes a review meeting. The question shifts from "is this worth engineering time" (which the gate already answered) to "does this draft PR look right" (which takes two minutes, not twenty).

The cost of not filtering

The alternative — continuing to rely on customer-reported severity or support-agent judgment — has costs that compound quietly:

• Senior engineer time spent confirming that escalated tickets are not actionable bugs
• Legitimate regressions that sit in the queue behind louder but lower-signal tickets
• Support-engineering relationship friction when engineering pushes back on escalations that weren't properly triaged
• Incident response latency when a real data-loss bug is buried under cosmetic issues because the customer who reported it was less persistent than the customer who reported a UI misalignment

None of these costs appear in a Jira ticket count or a sprint velocity metric. They accumulate in the background: in on-call fatigue, in engineer frustration, in customer trust eroded by bugs that took too long to fix because they were invisible to the team that could fix them.

Support ticket severity classification is not a labeling problem. It is a signal problem. The label is only as good as the signal behind it — and customer-reported severity is not that signal. Structured extraction, confidence-gated routing, and code-location matching are.