A priority field doesn't tell you why a ticket matters. If the only evidence behind “Urgent” is the requester's choice, your team still has to work out what broke and whether it can wait.
IT ticket prioritization starts with two separate judgments: the consequence of leaving the issue unresolved, and how soon that consequence requires action. An impact-urgency matrix makes those judgments repeatable, but only if you collect enough context to use it.
I don't think employees should have to understand your priority policy to get help. Ask them about the work they can't do, then let your support process turn that answer into a priority.
TL;DR
Assess impact through business consequences, including the work blocked and whether a usable workaround exists.
Assess urgency through the time available to act. A requested deadline needs a reason behind it.
Use a documented matrix, then send uncertain cases to a named person for triage.
Keep priority separate from severity and SLA targets. Reprioritizing a ticket doesn't necessarily change its SLA.
Start automation with clear cases, and review the decisions people override before expanding it.
What Do Impact and Urgency Actually Mean?
Atlassian's definitions tie impact to the effect on business processes and urgency to the time before that effect becomes significant. That distinction is useful even if you don't use Jira.
Impact answers “What happens if this stays unresolved?” Urgency answers “How long do you have before that consequence becomes unacceptable?”
The number of affected employees helps, but it can't be your only impact measure. One engineer unable to access the system needed to restore a production service can represent greater business impact than an entire office losing a convenience feature.
A deadline also needs context. A request for software access “by Friday” means something different when Friday is a personal preference versus the start of a scheduled production support shift.
For planned service requests, capture the needed-by date and work backwards through approvals and fulfillment. Don't wait until the deadline arrives to discover that a routine request needs several teams involved.
Build a Matrix Your Team Can Explain
Start with three impact levels and three urgency levels. Write the definitions alongside the matrix, because “high impact” means little until people agree on what belongs there.
For an internal IT desk, these are useful starting definitions:
Level | Impact | Urgency |
|---|---|---|
High | A critical business operation is blocked or materially at risk; affected headcount can be small. | Delay is already causing harm, or there is no safe time left to wait. |
Medium | Work is materially disrupted, but a limited workaround or alternate process exists. | There is a real deadline, with time remaining to coordinate a response. |
Low | Limited disruption, with normal work largely able to continue. | The work can be scheduled without material consequences from waiting. |
Use those inputs to assign a priority:
Impact ↓ / Urgency → | High | Medium | Low |
|---|---|---|---|
High | Urgent | High | Medium |
Medium | High | Medium | Low |
Low | Medium | Low | Low |
This is an illustrative policy, not an ITIL-mandated matrix or a claim about Ravenna's default behavior. Adapt the cells to your services and support coverage, then test them against actual tickets before rollout.
Define what each output asks the team to do: Urgent activates immediate escalation, High needs prompt ownership, Medium enters planned support work, and Low is scheduled through normal fulfillment. Attach response commitments your team can meet; the labels alone don't establish deadlines.
The high-impact, low-urgency cell deserves a closer look. A future service disruption may need planning today even if it doesn't need an immediate incident response. Assign an owner and a due date; a Medium label isn't permission to forget it.
Check the Matrix Against Real Situations
Consider four hypothetical tickets:
Ticket | Assessment | Result Under This Example Policy |
|---|---|---|
Company-wide sign-in failure prevents employees from working, with no usable workaround. | High impact, high urgency. | Urgent; activate the relevant incident response. |
The only available on-call engineer cannot reach the system needed to restore a critical service. | High impact, high urgency despite one affected user. | Urgent; escalate to the team that can restore access. |
A team's shared drive is unavailable. An approved alternate works until the afternoon handover, when the next shift will need files it can't access. | Medium impact, medium urgency, subject to the workaround's limits. | Medium; assign an owner and confirm when the alternate stops being sufficient. |
An employee wants a dashboard's display settings changed before an optional meeting. | Low impact, low urgency despite the requested deadline. | Low; schedule through normal fulfillment. |
The examples are deliberately conditional. If the alternate drive contains old files or excludes the people doing the work, it isn't a workable substitute, and the shared-drive ticket needs another assessment.
Use your security incident process for suspected compromise, and don't delay escalation while someone completes a form. A general service desk matrix should never become a gate in front of an established emergency route.
Ask for Evidence Before Assigning Priority
Replace the question “How urgent is this?” with a short set of questions employees can answer:
What are you trying to do, and what is preventing it?
Who else is affected, and which service is involved?
Can the work continue another way? What can't that workaround cover?
When does this need to be resolved, and what happens if it isn't?
You don't need every detail before acknowledging a request. You do need enough information to avoid turning a quiet, incomplete message into a low-priority ticket by default.
If the answers are missing or contradictory, flag the ticket for human triage and assign someone to review it. If a priority value is required, note that it is temporary and still needs review.
This distinction matters with chat intake. A short message in Slack or Microsoft Teams may describe a serious problem badly; the next question should uncover the consequence rather than reward how confidently someone asks for help.
Turn the Policy Into a Working Queue
Our priority documentation describes Low, Medium, High, and Urgent, with Medium as the default unless the form is configured differently. It also documents manual changes, workflow-based priority updates, and AI agent rules that assign priority from ticket content.
Those are mechanisms for applying your policy. They don't remove the need to define it.
Start with cases where the evidence is clear and the action is easy to inspect. An intake form can collect the affected service and business consequence, while the triage process records the resulting priority and its reason. Uncertain requests should reach a person who can ask a useful follow-up.
Keep a short decision record with the ticket. For the shared-drive example, it might look like this:
Decision Field | Example Entry |
|---|---|
Affected Work | Shared drive; current shift has an approved alternate. |
Consequence of Waiting | Next shift cannot access handover files. |
Workaround Limit | Covers current shift only. |
Next Deadline | Afternoon handover. |
Evidence | Shift lead confirmed alternate access and its limits. |
Priority and Owner | Medium; assigned triage owner. |
Review Condition | Reassess before handover, or immediately if alternate access fails. |
Replace relative deadlines with actual times in the ticket. A reviewer can challenge the assessment without reconstructing the whole conversation.
Give the triage owner permission to change the decision, and record what new evidence justified the change. A workable override is part of the process; it isn't an admission that automation failed.
When several tickets describe the same outage, manage the incident as a shared problem. Our incident trackers can propagate status and priority changes to open linked tickets and broadcast public updates. Closed linked tickets are excluded, and fields such as assignee stay independent.
Keep SLA Promises Separate From Queue Order
Priority expresses what deserves attention first. An SLA sets a measured service commitment, and those two things need compatible rules.
Ravenna's SLA playbook documents one SLA per ticket, selected by the first matching rule from the top of the list. It also states that the selection is locked at ticket creation: changing priority later doesn't re-evaluate which SLA applies.
If a Medium ticket becomes Urgent, update its owner and notification path as needed, then check the existing service commitment. Don't assume that changing the label has attached a shorter clock.
Set service response targets from the coverage you actually provide, including working hours. A matrix can't supply an overnight responder, and a target you can't staff will teach employees to distrust the priority labels.
What Should You Review After Rollout?
Start with a small sample of recent tickets and have two people classify them independently. Where they disagree, inspect the definition or missing evidence before changing an automation rule.
Once the policy is in use, review overrides and tickets whose consequences worsened while waiting. Look for repeated reasons: a workaround that didn't hold, an understated service dependency, or a deadline nobody captured.
When priorities match, consider the next committed deadline or approaching SLA breach, then ticket age and the skills needed. Give the triage owner responsibility for resolving conflicts and recording exceptions. Make that tie-break rule visible, so people don't quietly replace the matrix with whoever messages them most.
Check the Low queue too. Low priority should determine scheduling, not whether a request gets an owner or a meaningful update. A weekly review of aging requests is a reasonable starting practice, with the cadence adjusted to your commitments.
A useful matrix reduces the amount of interpretation your team repeats on every ticket. Keep the explanation beside the priority, and you'll have something concrete to improve when the first assessment is wrong.
If you're building this in Ravenna, we're happy to walk through your intake and priority rules, or you can start with the priority documentation.
Frequently Asked Questions
What Is the Best Way to Prioritize IT Tickets?
Assess business impact and urgency separately, then apply an agreed matrix. Capture the affected work and time constraint, and send unclear cases to human triage instead of treating missing information as low impact.
Are Ticket Priority and Incident Severity the Same?
They're related, but teams often use severity to describe an incident's impact and priority to decide response order. Define both locally and document how they relate, because naming conventions differ between organizations.
Should Employees Choose Their Own Ticket Priority?
Employees should describe the consequences and deadline, with a clear route to flag emergencies. Your triage policy should determine the final priority, and the requester should be able to provide new information if the assessment misses something.
Can AI Prioritize Support Tickets Automatically?
AI can help assign priorities from ticket content, but the decision needs enough evidence and a documented policy. Keep human review for uncertain cases, preserve the reason for changes, and check how reprioritization interacts with your SLA configuration.
