IT ticket priority matrix. Decide what needs attention first.
An IT ticket priority matrix combines the impact of an issue with how urgently it needs attention. Use the example below to agree on Urgent, High, Normal, and Low priorities, then adjust it to your services and support hours.
By Troublesheet · Published · Updated
Separate business impact from urgency.
Impact describes the effect on people, services, and essential work. Urgency describes how much delay the situation can tolerate before that effect becomes unacceptable. The number of affected people matters, but it is not the whole decision: one person may operate a service that everyone else depends on.
Who or what is affected?
Identify the service, location, work that cannot continue, and scope of the interruption. Check whether a workaround actually allows the work to proceed.
What happens if we wait?
Ask for the real deadline and consequence of delay. An appointment starting in ten minutes differs from a setup request for next month.
What do we know?
Record confirmed facts and missing details. Treat the initial priority as a decision to review when the situation changes.
The impact-and-urgency approach is described in Atlassian’s priority documentation. The four-level matrix and scenarios below are Troublesheet examples, not an official ITIL standard or a universal SLA.
A four-level ticket priority matrix.
First agree on three impact levels: high for a critical service or broad interruption, medium for a team or important workflow, and low for limited disruption with work still possible. Then choose the urgency column. Read the cell where the row and column meet.
Example only: adapt to your organization’s services and support coverage
Impact
High urgency Work cannot wait
Medium urgency Delay has a cost
Low urgency Work can be planned
High impact
Urgent
High
Normal
Medium impact
High
Normal
Normal
Low impact
Normal
Normal
Low
Use the matrix to make a consistent starting decision. Follow your established emergency or security incident process when it applies; do not leave a critical report waiting in a routine queue while someone completes a form.
Urgent: begin your agreed incident response and name the person coordinating it.
High: give the request prompt triage, a clear owner, and a scheduled update.
Normal: handle it through the regular queue with a visible next action.
Low: plan the work and confirm expectations with the requester.
Priority labels do not promise a response time. Define response and resolution targets separately, accounting for business hours, available coverage, dependencies, and any agreed service commitments.
Four examples to calibrate the team.
URGENT / HIGH IMPACT + HIGH URGENCY
A site’s network fails during operating hours.
Staff cannot reach the systems needed to work, and there is no usable alternative connection. Start the incident response, assign a coordinator, and provide a next-update time. Link or identify related reports so the scope remains visible.
HIGH / MEDIUM IMPACT + HIGH URGENCY
A classroom cannot present minutes before teaching starts.
The room’s scheduled session is blocked and moving rooms is not practical. Confirm the start time and available alternatives, then assign someone to restore a usable teaching setup. A single room can still represent a meaningful service interruption.
NORMAL / MEDIUM IMPACT + LOW URGENCY
A team needs software installed before next month’s project.
The request affects several people, but current work continues. Confirm the required date, licensing, approvals, and a planned installation window. A future deadline should be tracked without treating the work as an outage today.
LOW / LOW IMPACT + LOW URGENCY
A user requests a second monitor with no near-term deadline.
The existing workstation remains usable. Confirm requirements and the purchasing process, then schedule the work. Reassess if new information shows the current setup prevents essential work.
If a printer appears to affect only one person, ask what it prints. A convenience printer and the only printer for time-sensitive shipping labels can have different business impact.
A repeatable triage checklist.
Confirm the affected service. Ask what stopped working, when it started, and who cannot complete which task.
Check the workaround. Confirm whether it is available, usable, and adequate for the immediate deadline.
Record impact and urgency. Capture a short reason for each, then use the matrix to choose the priority.
Assign an owner and next action. A high priority without an owner still has no one responsible for moving it forward.
Set the next update. Tell the requester when they should expect to hear from you, even if the diagnosis is incomplete.
Reassess when facts change. A workaround, a wider outage, or an approaching deadline may change the decision. Record why the priority changed.
Apply the decision in Troublesheet.
Use the matrix as a team reference, then have an authorized staff member select Urgent, High, Normal, or Low on the ticket. Record the triage reasoning in an appropriate team note, assign the technician, and set a follow-up for the next action. Troublesheet does not automatically calculate priority from this article’s matrix.
At the next team review, compare a few real tickets without ranking individual technicians. Look for inconsistent definitions, missing information, and workarounds that changed the outcome.
Practice with a sample ticket.
Open the demo, choose a request, and explore its priority, assigned technician, notes, and follow-up.