SLAs, priority, and severity explained

Three related ideas

• SLA — a timed commitment (for example first reply within 1 hour for Priority 1). Missed SLAs are process signals, not automatic proof that an agent failed.
• Priority — how urgently the support team should work the ticket relative to other tickets in the queue.
• Severity / impact — how bad the product failure is (one user vs whole region, cosmetic vs data loss). Engineering incidents often use severity language.

How they interact

A site-wide login outage is high severity and usually high priority with a tight SLA. A single customer asking for a CSV export tip may be low severity and low priority even if they are upset. Conversely, a VIP contract can raise priority without changing the technical severity of a bug. Write both impact and urgency in the ticket so triage stays honest.

Support example

Checkout fails for all customers in AU. You mark the ticket Critical, page the incident channel, and keep customer updates on a single parent ticket. Separately, one AU customer asks how to change their logo—that stays Normal priority even though they mention the outage; you link them to the incident notice instead of inflating every related question.

Common mistakes

• Setting every ticket to Urgent because the customer asked loudly.
• Confusing “SLA breached” with “engineer must drop everything” without impact context.
• Changing priority without documenting why—handoffs become political.