bug severity rubric for support triage

Not specified by the original author.

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

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

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

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

Thread query: bug severity rubric for support triage

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.

Not specified by the original author.

TL;DR

Engineers act on bug reports they can reproduce in under five minutes. Write the shortest path from a fresh state to the broken behavior, include exact environment details, and state expected vs actual behavior in one line each. A report with repro steps, a screenshot or recording, and a severity signal gets picked up; a paragraph of prose gets filed away.

The query

writing bug reproduction steps for engineering handoff

Use this when

• You are escalating a customer-reported bug to engineering
• Engineering keeps kicking back your bug reports as unreproducible
• You want a bug report template for the support team
• A QA or triage rubric needs a repro-quality bar

Not for

• Customer-facing workaround messages
• Feature requests or product feedback
• Postmortems after an incident
• Writing the actual code fix

Steps

1. Confirm the bug on your own machine first

Before writing anything, try to hit it yourself with the user's account state or a fresh test account. A repro you have personally run is ten times more credible.

Expected output: you have seen the bug happen at least once, or you note "could not reproduce locally" honestly.

2. Reduce it to the shortest path

Cut every step that is not needed. If the bug still happens without step 4, delete step 4. Three to five steps is the sweet spot.

Expected output: a numbered list of steps starting from a defined fresh state (logged in, empty cart, etc).

3. Pin the environment

App version, browser and version, OS, user role, account plan, any relevant settings or flags. Copy the exact values, do not paraphrase.

Expected output: an Environment block with exact versions and settings, no "latest" or "recent".

4. State expected vs actual in one line each

"Expected: invoice exports as PDF with line items. Actual: exports as a blank PDF." One line each, no adjectives.

Expected output: two sentences, zero ambiguity about what correct behavior looks like.

5. Attach evidence

Screenshot of the broken state, screen recording of the repro, console or network errors if any. Attach the raw file, not a pasted description.

Expected output: at least one visual artifact showing the bug.

6. Add the severity signal

How many users are affected, whether there is a workaround, and whether data loss or billing is involved. This is what decides the queue order.

Expected output: one line with user count, workaround yes/no, and data/billing impact.

Bug report template

Title: [short symptom], e.g. invoice export returns blank PDF

Environment: app v4.2.1, Chrome 128, macOS 14, Pro plan

Steps:
1. Log in as a Pro user
2. Go to Billing, click Export invoice for September
3. Open the downloaded file

Expected: PDF shows line items and totals
Actual: PDF is completely blank

Evidence: [screenshot / recording]

Severity: 12 users reported this week, no workaround, billing-related

Variant phrasings

bug report template for support to engineering handoff

Use the template above verbatim as your team's macro. Fill every block, every time.

how to write good bug reports for developers

Same structure. The single biggest upgrade is step 2: most bad reports have a 15-step novel where a 4-step repro exists.

what to include when escalating a bug to engineering

Steps, environment, expected vs actual, evidence, severity. If you only have four of the six, say which one is missing and why.

Why it happens

Support reports land in engineering's queue competing with feature work, and engineers triage by reproduction cost. A report that takes two minutes to reproduce gets investigated today; a report that takes an hour of guessing gets scheduled for never. The repro steps are not documentation, they are the argument for why this bug deserves attention now.

Edge cases

• Intermittent bugs: include frequency ("3 of 10 attempts") and anything that correlates (time of day, data volume, specific account state).
• Bugs you cannot reproduce: say so explicitly, and hand over everything you do have, logs, user state, timestamps. An honest "could not reproduce" beats a fake repro.
• Data-sensitive bugs: strip PII before attaching evidence, or note that the engineer needs the user's consent to look at the account.
• Third-party bugs: same template, but the escalation target is the vendor ticket, and severity signal matters even more.

Provenance

Resolved from the public thread: https://vectle.com/posts/psthaRjeFkoFbRZtUNa-mbQw

Resolved from the public thread: https://vectle.com/posts/psthaRjeFkoFbRZtUNa-mbQw

Thread query: writing bug reproduction steps for engineering handoff

TL;DR: Engineers act on bug reports they can reproduce in under five minutes. Write the shortest path from a fresh state to the broken behavior, include exact environment details, and state expected vs actual behavior in one line each. A report with repro steps, a screenshot or recording, and a severity signal gets picked up; a paragraph of prose gets filed away.

Not specified by the original author.

TL;DR

Escalate when you have ruled out configuration, user error, and known issues, and the fix needs code, data, or access you dont have. If you are escalating because you are stuck rather than because it is a bug, you are misrouting. The test is simple: could an engineer do something you cannot? If yes, escalate. If no, keep working.

The query

when to escalate a support ticket to engineering

Use this when

• Agents escalate everything or nothing
• Engineering complains about noise in the escalation queue
• You are writing the team's escalation policy
• Escalation volume is climbing without more bugs

Not for

• How to write the escalation message itself
• Severity definitions for escalations
• Routing feature requests to product
• Deciding engineering sprint priorities

Steps

1. Confirm it reproduces or is clearly systemic

One customer's odd report is worth investigating; the same report from three customers is a bug. Escalate on evidence, not on the customer's certainty. "It worked yesterday" from one user is a ticket; from ten, it is an escalation.

Expected output: the escalation cites reproduction or multiple reports, not one person's claim.

2. Rule out everything support can fix

Walk the checklist first: configuration, permissions, browser or app state, documented workarounds, known issues list. Escalations that skip this get bounced, and bounced escalations train engineers to ignore the queue.

Expected output: a short list of what you ruled out, attached to the escalation.

3. Check the fix requires engineering access

The fix needs a code change, a data fix, a config only engineering can touch, or logs you cant see. If the answer is in the knowledge base or a settings page, it stays with support.

Expected output: the escalation names the specific thing only engineering can do.

4. Escalate the outage symptoms immediately

Anything that looks like an outage or a security issue skips the checklist. Page first, investigate second. The escalation policy should say this in bold because hesitation here is the expensive mistake.

Expected output: outage and security signals escalate in minutes, everything else waits its turn.

5. When in doubt, ask a senior agent, not engineering

The gray zone is real: weird but possibly user error, intermittent, single-customer. A senior agent or team lead triages the gray zone so engineering sees a clean queue.

Expected output: uncertain tickets get a second support opinion before they become escalations.

Variant phrasings

support escalation criteria for SaaS

Steps 1 through 3 are the criteria. Evidence, ruled-out list, engineering-only fix.

when should support escalate to engineering

The one-sentence test from the TL;DR: could an engineer do something you cannot?

engineering escalation policy for support teams

All five steps, with step 4 in bold. The policy is the checklist plus the outage exception.

Why it happens

Support escalates too much because escalation feels like progress, and too little because getting bounced feels like failure. Both come from the same missing piece: a written line between support's job and engineering's job. Without it, every agent draws the line themselves, and the queue fills with judgment calls.

Edge cases

• The customer demands escalation: acknowledge it, investigate first anyway. "Let me dig in so I can hand them something useful" works.
• Feature requests disguised as bugs: "it should work this way" is product feedback, not an escalation. Route it there.
• Intermittent issues: escalate with the pattern documented (when, how often, what was tried), not after you personally witness it.
• The same bug re-escalated: link to the original escalation instead of filing fresh. Duplicates are queue poison.
• Engineering is underwater: the bar goes up temporarily, and the team lead communicates that. It should be explicit, never silent.

Provenance

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

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

Thread query: when to escalate a support ticket to engineering

TL;DR: Escalate when you have ruled out configuration, user error, and known issues, and the fix needs code, data, or access you dont have. If you are escalating because you are stuck rather than because it is a bug, you are misrouting. The test is simple: could an engineer do something you cannot? If yes, escalate. If no, keep working.