Ticket priority matrix: setting priority from impact and urgency
A priority matrix sets a ticket's priority from two questions, how many people are affected (impact) and how soon it matters (urgency). Using the same two questions every time makes priorities consistent between technicians and gives each level a response target that means something.
Why priority needs rules
Without a rule, priority drifts toward whoever asks most urgently. A technician who sets it by feel will pick differently on a quiet Monday and on a crowded Friday, and two technicians will disagree. A matrix does not remove judgement, but it gives the judgement a shared starting point and a reason that can be written in a note.
Priority is not the same as importance of the person asking. An executive with a cosmetic question is still a low-priority request, and a junior employee who cannot work at all is not. Keep the rule about the effect on work, and handle genuine exceptions as exceptions.
The two inputs
- Impact
- How much is affected. One person, a team or department, or the whole organization or client. Add a note for anything that touches money, safety or legal obligations, since those can raise impact regardless of headcount.
- Urgency
- How quickly the effect becomes costly. A fully blocked person is high urgency. A request with a free workaround, or one with a due date next month, is low.
An example matrix
The table maps three levels of each input to the four priorities that a new ActiveQ workspace starts with. It is an illustration to adapt, not a recommendation for your business.
| Impact \ Urgency | High urgency | Medium urgency | Low urgency |
|---|---|---|---|
| High impact (many people) | Urgent | High | Normal |
| Medium impact (a team) | High | Normal | Low |
| Low impact (one person) | Normal | Low | Low |
Read it as a starting point: a whole department that cannot sign in is Urgent, a single person with a cosmetic problem is Low, and one person who is fully blocked lands on Normal unless a special rule lifts it.
Rules for exceptions
- Named exceptions. List the few situations that always override the matrix, for example a security incident or anything stopping payroll, and keep the list short.
- Raise, do not hide. If a technician changes a priority, an internal note should say why. The next person then sees the reasoning instead of guessing.
- Let it move. A request that looked small can become large, and a large one can be mitigated. Revisit the priority when facts change, and when it is lowered after a workaround, say so to the requester.
- Review disagreements. If two technicians keep choosing differently, the matrix wording is unclear. Fix the wording, not the people.
Connecting priority to SLA targets
Priority is the usual key for response and resolution targets: the higher the priority, the shorter the target. Keep to few levels, because every level needs two numbers that the team can actually meet. The IT SLA guide has sample targets, clearly labelled as examples, and the SLA calculator shows the due time a target gives for a given start time and business hours.
Setting this up in ActiveQ
- A new workspace starts with the priorities Urgent, High, Normal and Low. Levels 1 to 4 order the queue, and in Settings, then Workflow, you can rename, recolor or add priorities.
- A service level policy sets a first response and a resolution target for each priority, with a fallback row for any other priority. See SLA management.
- A mailbox or a portal form can set the starting priority for new tickets, and a staff member changes it during triage. The triage guide describes that routine.
- A staff member can ask AI assist to suggest a priority. It is a suggestion that a person applies or ignores.