severity vs priority: how support should use both

Not specified by the original author.

TL;DR

Severity measures how bad the damage is. Priority measures how fast the business wants it fixed. They are two different axes, and merging them into one number is where triage arguments start. Keep both, let different people set each one, and use the matrix below to decide what happens first.

The query

severity vs priority: how support should use both

Use this when

• Agents and engineers argue about whether something is "P1" or "sev 1"
• Your tracker has one field doing the job of two
• Triage keeps stalling on what a word means
• You are designing an incident taxonomy from scratch

Not for

• Writing your SLA policy (that comes after the taxonomy)
• Deciding on-call rotations
• Root cause analysis of a specific incident
• Customer-facing status page wording

Steps

1. Define severity by damage only, S1 to S4

Severity answers "how broken is it" with no regard for who is affected. S1: core function down for everyone. S2: core function degraded or down for a segment. S3: workaround exists, minor function broken. S4: cosmetic or single-user edge. No business judgment allowed in this field.

Expected output: a four-line severity scale pinned in your runbook.

2. Define priority by business order, P1 to P4

Priority answers "what do we work on first." It can consider revenue, a launch tomorrow, a key account, or contractual penalties. Two S3s can have different priorities, and that is fine.

Expected output: a four-line priority scale that references business factors explicitly.

3. Assign them with different owners

The agent or on-call who sees the damage sets severity. The incident commander or support lead sets priority. One person setting both is how "my ticket is more important" arguments start.

Expected output: your triage doc names who sets each field.

4. Use the matrix, not vibes

High severity with low priority happens: a complete outage in a deprecated product during a migration. Low severity with high priority happens too: a typo on the checkout page during a launch. Plot both, then act on priority order.

Expected output: triage decisions reference both fields in the ticket.

5. Revisit priority on a schedule, severity on facts

Priority decays and shifts as launches pass and workarounds land; review it daily on open incidents. Severity changes only when the damage changes, like a workaround failing or scope expanding.

Expected output: open incidents get a priority review note; severity changes carry a reason.

The two-axis matrix

              P1 (now)      P2 (today)     P3 (this week)   P4 (backlog)
S1 (all down)  all hands     urgent          planned          (rare: note why)
S2 (degraded)  urgent        planned         scheduled        backlog
S3 (workaround exists)  planned  scheduled   backlog          backlog
S4 (cosmetic)  scheduled     backlog         backlog          wontfix candidate

Rule of thumb: an S1 is never P4 without a written reason.
A P1 that is S4 is usually a launch or a key account. Say so in the ticket.

Variant phrasings

difference between severity and priority

Severity is the damage. Priority is the order. One describes the incident, the other describes your response.

should severity and priority be the same thing

No. Collapsing them forces one number to carry two arguments, and every triage becomes a fight about which argument counts.

priority vs severity in incident management

Most incident frameworks (including the common S1-S4 plus P1-P4 pairing) keep both fields for exactly this reason.

Why it happens

Teams merge the fields because it feels simpler: one number, one sort order. But severity is a technical fact and priority is a business decision, and they move on different clocks. A single number either hides real damage (the S1 nobody prioritized) or manufactures urgency (the P1 with a cosmetic bug). Two fields let the facts and the decisions disagree honestly.

Edge cases

• Customer-reported severity: customers always say S1. Let them pick from a customer-facing scale (e.g. "blocking my work"), then map it to your internal severity yourself.
• Priority inflation: if everything is P1, nothing is. Cap the number of concurrent P1/P2 items and force a demotion conversation when the cap breaks.
• Severity changes mid-incident: log it with a timestamp and reason. Severity history is what postmortems audit.
• Contractual SLAs: when an SLA pins response times to severity, say so in the scale definition so agents know the field has legal weight.
• Deprecated products: an S1 in a product you are sunsetting can legitimately be P4. Write the reason down so nobody re-litigates it.

Provenance

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

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

Thread query: severity vs priority: how support should use both

TL;DR: Severity measures how bad the damage is. Priority measures how fast the business wants it fixed. They are two different axes, and merging them into one number is where triage arguments start. Keep both, let different people set each one, and use the matrix below to decide what happens first.

Not specified by the original author.

TL;DR

Severity measures technical impact: how broken, how widespread, how much workaround exists. S1 is the product is down or data is at risk; S4 is a cosmetic annoyance with a workaround. The most important rule: severity is never set by how loud the customer is. Write the definitions with examples so nobody has to interpret them under pressure.

The query

severity definitions for support escalations

Use this when

• Agents and engineers argue about severity
• Escalations arrive with inflated severities
• You are writing the escalation policy
• Severity inflation is drowning real S1s

Not for

• P1 vs P2 vs P3 priority ranking (priority is business ordering, severity is technical impact)
• SLA response-time design
• Customer-facing status page language
• Engineering sprint prioritization

Steps

1. Define S1: critical, act now

Core functionality down for many users, data loss or corruption in progress, or a security incident. No workaround. Page someone immediately. Example: all logins failing, or exports silently dropping customer data.

Expected output: everyone agrees what a drop-everything event looks like.

2. Define S2: major, same-day

A key feature broken for a meaningful segment, or degraded performance with no workaround. Needs engineering today but not a page at 3am. Example: the reporting dashboard wont load for Pro accounts.

Expected output: a clear line between "now" and "today."

3. Define S3: moderate, this week

A feature broken with a viable workaround, or a minor feature broken outright. Frustrating but not blocking. Example: CSV export works but date formats are wrong and the customer can fix them in a spreadsheet.

Expected output: the workaround question becomes the S2/S3 dividing line.

4. Define S4: minor, backlog

Cosmetic issues, typos, small UX papercuts. Annoying, never blocking. Example: a misaligned button on the settings page.

Expected output: S4s stop consuming urgent attention.

5. Write the anti-inflation rules

Severity follows impact, not volume, not tone, not account size alone. One angry enterprise customer with a workaround is still S3. Put this in writing or every escalation becomes S1.

Expected output: a severity guide that resists pressure.

Ready-to-use definitions

S1 CRITICAL: core function down for many, or data/security at risk.
    No workaround. Page immediately.
S2 MAJOR: key feature broken for a segment, no workaround.
    Engineering today.
S3 MODERATE: broken with a workaround, or minor feature broken.
    Fix this week.
S4 MINOR: cosmetic or trivial. Backlog.

Severity = technical impact. Never set by customer tone or volume.

Variant phrasings

support escalation severity levels explained

Steps 1 through 4 with the examples. Examples are what make definitions stick.

S1 S2 S3 S4 definitions for support teams

The ready-to-use block. Post it where escalations are filed.

severity vs priority in support escalations

Severity is how broken it is; priority is how soon it gets fixed given everything else. An S3 for your biggest account can be P1. Keep the two axes separate.

Why it happens

Severity inflation happens because severity feels like the only lever support has to get attention. When every escalation is S1, the real S1s drown, and engineering stops trusting the labels entirely. Precise definitions protect the signal by making inflation visible.

Edge cases

• A single huge account down: severity is still about technical scope, but note the account impact separately. Dont bend the definition; add context.
• Security issues: default to S1 until security says otherwise. Over-severity here is the one safe direction.
• Degradation vs outage: partial degradation with a workaround is S2, not S1. "Slow" is not "down."
• Severity changes mid-incident: allow it, but log who changed it and why. Severity that drifts silently corrupts the data.
• Customers demanding S1: acknowledge, assess honestly, and explain the call. Never upgrade severity to end a conversation.

Provenance

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

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

Thread query: severity definitions for support escalations

TL;DR: Severity measures technical impact: how broken, how widespread, how much workaround exists. S1 is the product is down or data is at risk; S4 is a cosmetic annoyance with a workaround. The most important rule: severity is never set by how loud the customer is. Write the definitions with examples so nobody has to interpret them under pressure.

Not specified by the original author.

TL;DR

Priority is impact times urgency, not how loudly the customer complains. P1: critical function broken for many users, drop everything. P2: important function broken or degraded, same-day. P3: minor issue or single user, this week. P4: question or cosmetic, whenever. Write the definitions with examples from your own product, assign priority at triage in under a minute, and let customers escalate the priority but never set it.

The query

how to prioritize P1 vs P2 vs P3 support tickets

Use this when

• Agents assign priority by gut feel and it is inconsistent
• P1s are piling up and nothing is actually urgent
• You need a triage playbook for the team
• Customers demand P1 for everything

Not for

• Engineering incident severity (related but different)
• Setting SLA time targets per tier
• Capacity planning or staffing

Definitions

P1: critical

A core function is broken for many users, or one enterprise customer is fully down. Revenue or data is at stake. Drop everything, all hands, update every 30 minutes.

P2: high

An important function is broken or degraded, or a core function is broken for one user. Same-day response and active work until resolved.

P3: normal

Minor bug, single-user issue, or a question that needs a real answer. Resolved within the normal queue flow, this week.

P4: low

Cosmetic issues, questions answered by docs, nice-to-haves. Batched and handled when the queue allows.

Steps

1. Score impact first

How many users, and how central is the broken function? "All users cant log in" is P1. "One user cant export" is P2 or P3 depending on the function.

Expected output: an impact call (many/few users, core/edge function) before any priority label.

2. Score urgency second

Is there a deadline (payroll day, launch day), data loss in progress, or money moving? Urgency upgrades, it never downgrades.

Expected output: a yes/no on time pressure and its source.

3. Assign the priority and write one line of why

"P2: exports broken for one Pro user, no workaround, no deadline." The one-liner keeps priorities auditable and stops priority inflation.

Expected output: every ticket carries a priority plus a one-line justification.

4. Triage new tickets within 15 minutes

Priority assignment is a triage job, not a resolution job. Scan, score, label, route. A wrong priority fixed in an hour beats a perfect priority assigned tomorrow.

Expected output: no untriaged ticket older than 15 minutes during business hours.

5. Review priorities weekly

Pull the week's P1s and P2s. If half the P1s were really P2s, the definitions need sharper examples, not stricter agents.

Expected output: a weekly priority audit that feeds back into the definitions.

Variant phrasings

support ticket priority levels explained

The four definitions above. Add two real examples per level from your own product, abstract definitions drift within a month.

P1 P2 P3 priority definitions for customer support

Impact times urgency, with the one-line justification rule. Priority inflation is the number one failure mode, the weekly audit in step 5 is the fix.

how to triage support tickets by priority

Steps 1 through 4 as the triage runbook. Triage is a separate motion from solving, staff it that way at volume.

Why it happens

Without written definitions, priority becomes a negotiation: the loudest customer wins, the politest loses. Agents default to over-prioritizing because under-prioritizing feels riskier. The result is a queue where everything is P1 and nothing is. Written definitions with examples move priority from a feeling to a call, and the one-line justification makes the call checkable.

Edge cases

• Customer demands P1: acknowledge the urgency, assign by your definitions, and explain the call. "I hear this is urgent for you. By our definitions this is a P2, which means same-day work, here is what happens next."
• Priority disputes between agents: the triage lead decides, fast. Log the dispute and sharpen the definition, dont relitigate the ticket.
• Everything is on fire: when the queue is all P1, you dont have a priority problem, you have an incident. Switch to incident mode.
• VIP or enterprise customers: tier by contract if you must, but keep it explicit in the definitions. Hidden VIP rules breed resentment and inconsistency.

Provenance

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

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

Thread query: how to prioritize P1 vs P2 vs P3 support tickets

TL;DR: Priority is impact times urgency, not how loudly the customer complains. P1: critical function broken for many users, drop everything. P2: important function broken or degraded, same-day. P3: minor issue or single user, this week. P4: question or cosmetic, whenever. Write the definitions with examples from your own product, assign priority at triage in under a minute, and let customers escalate the priority but never set it.