Create consistent ticket-priority definitions and a repeatable triage and reassessment process.
Ticket priority should answer one operational question: What needs attention first, and who is accountable for the next action? It should not be a measure of how important the requester is, how loudly someone asks, or how difficult the work appears.
A dependable system separates four concepts that are often mixed together: impact, urgency, severity, and ownership. Clear definitions make triage faster, service targets more credible, and escalations easier to defend.
Severity, impact, urgency, and priority are different
- Impact describes the breadth and business consequence: how many people, locations, transactions, or critical processes are affected.
- Urgency describes how long action can safely wait before the consequence becomes materially worse.
- Severity describes the observed condition or harm. A system can have a severe defect that is contained and therefore not immediately urgent.
- Priority is the queue order and response posture after impact, urgency, and any safety, security, contractual, or regulatory exception are considered.
- Ownership identifies the person or role accountable for the next action and for ensuring the ticket does not disappear during a handoff.
A practical four-level priority model
The following model is a starting point, not a universal service-level agreement. Replace its examples and response posture with language that matches your actual staffing, contracts, risk profile, and support hours.
| Level | Typical criteria | Response posture | Ownership |
|---|---|---|---|
| P1 — Critical | Widespread loss of a critical service, severe active risk, or major operation stopped with no workable alternative | Begin coordinated response immediately; maintain active command, communications, and reassessment | Named incident lead plus technical and communications owners |
| P2 — High | Material degradation, multiple users blocked, important deadline threatened, or limited workaround | Rapid triage within the applicable support window; escalate if impact expands or the workaround fails | Named resolver with an escalation deadline |
| P3 — Normal | Individual or limited issue, routine service interruption, or usable workaround | Handle through the normal queue and communicate the next expected step | Assigned agent or resolver group with one accountable owner |
| P4 — Low or planned | Information request, cosmetic defect, enhancement, or work that can be scheduled without meaningful harm | Plan, batch, or route to the appropriate request backlog | Queue owner until accepted by a named assignee |
Use an impact-and-urgency matrix
A matrix reduces improvisation. Define each axis with observable evidence rather than vague labels.
| Impact \ Urgency | Immediate | Soon | Routine |
|---|---|---|---|
| High impact | P1 | P2 | P3 |
| Medium impact | P2 | P3 | P4 |
| Low impact | P3 | P4 | P4 |
“High impact” might mean a public service is unavailable or a revenue-critical workflow cannot operate. “Immediate urgency” might mean harm is continuing, data could be lost, or a hard deadline will pass before the next normal review.
Document exceptions. A suspected security compromise, safety concern, or legally sensitive event may need a specialized response even when few users are affected. Route those cases through the correct escalation matrix rather than relying on an ordinary queue.
A seven-step triage sequence
- Confirm the request type. Separate incidents, access requests, questions, complaints, security reports, and planned changes.
- Capture facts. Record the affected service, users, locations, start time, symptoms, error evidence, and known workaround.
- Assess impact. Consider breadth, criticality, financial or service consequence, and whether essential work has stopped.
- Assess urgency. Identify the next deadline and what becomes worse if action waits.
- Check exception routes. Security, privacy, safety, legal, and executive-communications procedures may override ordinary routing.
- Set priority and owner. Record why the level was chosen, who owns the next action, and when it will be reviewed.
- Reassess. Priority can rise or fall as scope, workaround, or evidence changes. Record the reason and timestamp.
Examples that expose common mistakes
- Public checkout unavailable for every customer: high impact and immediate urgency; likely P1.
- One employee locked out before a time-sensitive customer presentation: low breadth but high urgency; often P2 or P3 depending on consequence and alternatives.
- A reporting defect affecting many users, with an accurate manual workaround and no near deadline: high impact but lower urgency; perhaps P2 or P3, not automatically P1.
- A spelling error on an internal page: low impact and routine urgency; P4 unless it changes meaning or creates a compliance concern.
Ownership must survive every handoff
Assignment and ownership are not always the same. A specialist may perform the work while the service owner remains accountable for updates, follow-up, and closure. State who can declare an incident, change priority, approve a workaround, communicate externally, and close the record.
After-hours rules also need named roles. If a P1 can arrive overnight, align the model with the real after-hours coverage and activation path. A target that nobody is staffed to meet is not an operational plan.
Priority-system checklist
- Criteria use observable impact and time constraints, not requester status.
- Every open ticket has one accountable owner and a next-review time.
- P1 activation, communications, and closure authority are documented.
- Security, privacy, safety, and legal exceptions have separate routes.
- Priority changes retain the old value, new value, reason, and timestamp.
- Teams sample misclassified and repeatedly reprioritized tickets.
- The complete definitions live in accessible workflow documentation.
A good priority model will not eliminate judgment. It makes judgment consistent, reviewable, and tied to the actual consequence for users and the organization.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- Atlassian Support: impact, urgency, and priority Provides a documented example of defining priority through impact and urgency.
- ServiceNow documentation: prioritizing problems Provides another documented service-management approach using business impact and acceptable delay.
- NIST SP 800-61 Rev. 3: Incident Response Recommendations Supports routing cybersecurity events into an established incident-response capability with defined preparation, response, and recovery responsibilities.