## TL;DR
Severity is customer impact plus workaround availability, nothing else. Data loss or full outage with no workaround is critical; a typo with a workaround is trivial. Write five levels with product-specific examples, and make "is there a workaround" the tiebreaker question. Severity arguments almost always dissolve once both sides answer the workaround question.

## The query

```text
bug severity rubric for support triage
```

## Use this when

- Agents assign severity inconsistently
- Engineering disputes support's triage
- Building triage training for new agents
- Severity inflation (everything is "urgent")

## Not for

- Engineering's internal severity system
- SLA contract language
- Security vulnerability scoring (CVSS)
- Prioritization within a sprint

## Steps

### 1. Define five levels by impact and workaround

Critical: data loss, security breach, or full outage, no workaround. High: major feature broken, workaround painful or partial. Medium: feature impaired, reasonable workaround exists. Low: minor issue, easy workaround. Trivial: cosmetic. Write each with two product examples.

Expected output: five levels with examples.

### 2. Make the workaround question the tiebreaker

"Can the customer still do their job another way?" If yes, it is not critical, no matter how angry they are. Anger is urgency; impact is severity. Teach the distinction explicitly.

Expected output: agents asking the workaround question on every ticket.

### 3. Attach response targets to levels

Critical: 15 minutes. High: 1 hour. Medium: 4 hours. Low: next business day. Trivial: backlog. Severity without a response target is just a label people argue about.

Expected output: targets per level, published.

### 4. Require evidence for critical and high

Repro steps, affected accounts, error messages, timestamps. A critical ticket without evidence gets downgraded until the evidence arrives. This kills severity inflation.

Expected output: an evidence checklist enforced on high severities.

### 5. Review disputed severities weekly

Pull tickets where support and engineering disagreed. Discuss, adjust the examples in the rubric, and move on. The rubric improves by calibration, not by being perfect on day one.

Expected output: a weekly 15-minute calibration.

## Template: the rubric

```text
SEVERITY RUBRIC
Critical: data loss, breach, or full outage. No workaround. Respond 15 min. Evidence required.
High: major feature broken. Workaround painful/partial. Respond 1 h. Evidence required.
Medium: feature impaired. Reasonable workaround exists. Respond 4 h.
Low: minor issue. Easy workaround. Respond next business day.
Trivial: cosmetic. Backlog.

Tiebreaker: "Can the customer do their job another way?" Yes -> not critical.
Not severity: customer anger, VIP status, ticket age. Those are urgency; route separately.
```

## Variant phrasings

### how to prioritize bugs in support

Steps 1 through 3. Levels, tiebreaker, targets.

### severity vs priority support

Step 2. Severity is impact; priority is severity plus business context.

### bug triage levels

Full sequence. The weekly calibration is what makes it stick.

## Why it works

Without a rubric, severity becomes a negotiation tactic: the loudest customer gets "critical." The impact-plus-workaround definition is objective enough to argue from evidence, and the evidence requirement for high severities keeps the top levels meaningful. Engineering trusts triage they can audit.

## Edge cases

- Security bugs: severity floor of high, always. Do not let the workaround question downgrade a breach.
- The workaround requires the customer to be technical: that is a painful workaround. Score accordingly.
- Intermittent criticals: if it sometimes causes data loss, it is critical. Intermittence is not mitigation.
- VIP with a low-severity bug: route VIP fast, but do not relabel the severity. Separate the concepts.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jBuqkmIWrlSlSeGFzvugWQ