On this page
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.
Effort is not priority
A five-minute task is not automatically urgent, and a complex incident does not become lower priority because it is difficult. Estimate effort for planning after the service need has been prioritized.
Different organizations and products use severity terminology differently. Publish the local definitions and show how they connect to queue behavior. Do not assume that an external provider's severity label has the same meaning as an internal priority level.
Atlassian's impact and urgency documentation and ServiceNow's problem-priority documentation illustrate defined mappings. They are examples of an approach, not a universal obligation to use the same labels or response targets.
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.
Apply the sample matrix only after defining the axes for the service. The number of affected users is one input to impact, not its complete meaning. One person may operate a critical approval process; many users may be inconvenienced by a defect that does not prevent essential work.
Write any override as a visible rule with an owner. If a narrow but time-critical case needs a higher response posture than the matrix suggests, record the consequence and authorized exception. This is more defensible than quietly changing the dropdown whenever someone presses harder.
A suspected cybersecurity incident should enter the organization's incident-response process. NIST SP 800-61 Rev. 3 places response within a defined risk-management capability. Ordinary support triage should preserve the facts and route the concern without attempting an improvised investigation.
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.
When evidence is incomplete, record a provisional priority and the question that will resolve it. For example, staff may know that checkout failed for one customer but not whether it affects everyone. Assign someone to establish scope and set a review point suited to the possible consequence.
Do not leave the ticket unowned while waiting for perfect classification. The provisional owner can gather evidence, maintain communication, and activate the appropriate exception route if the facts warrant it.
Capture the workaround precisely. “Use another device” is not a useful alternative if the affected employee has no authorized access to one. A workaround reduces urgency only when it is available, appropriate, and sufficient for the time-sensitive task.
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.
Reassess priority when a workaround fails, affected scope changes, a deadline approaches, or a critical dependency becomes available. Aging alone should prompt review rather than automatically turn every old request into a major incident.
When priority falls, record the evidence and communicate any changed expectation. A restored partial service may reduce urgency while leaving important follow-up work. Lowering the level should not erase that work or its owner.
Separate the customer's desired completion date from an approved service target. Staff can acknowledge the need and explain the next step without promising a response the destination team is not staffed to provide.
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.
Review a sample of changed priorities and disagreements during routine operations. Look for ambiguous criteria, missing evidence, mismatched support hours, and categories used as shortcuts. A pattern of overrides may reveal that the matrix no longer fits the service.
Use those findings to revise examples and operating rules together. The system works when staff can explain why a ticket is next, identify who owns it, and recognize the evidence that would change that decision.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- Atlassian: Impact, Urgency, and Priority Priority can be calculated from separately defined impact and urgency; exact mappings depend on configuration.
- ServiceNow: Data Lookup for Prioritizing Problems Service management priority can combine separately specified impact and urgency.
- NIST SP 800-61 Rev. 3 Cybersecurity incident response integrates defined preparation, detection, response, and recovery with risk management.