Why priority needs a rule
Every support team has more work than time at some point, so the order of work matters. Without a rule, order tends to follow whoever calls most often, whoever is most senior or whoever sounds most stressed. That feels unfair to everyone else and can leave genuinely serious problems waiting. A simple, shared method for ranking tickets makes decisions faster and easier to explain.
Impact and urgency
Two questions do most of the work.
- Impact: how much damage does the problem do? This usually reflects how many people are affected and how important the affected service is. One person unable to print is low impact; the whole company unable to send email is high.
- Urgency: how quickly must it be fixed before the damage grows? A problem with a deadline attached, or one that will get worse each hour, is more urgent than one that can wait until tomorrow without consequence.
Keeping the two separate matters because they are not the same thing. A broken system used by a few people (low impact) might still be extremely urgent if it prevents a payroll run due this afternoon. A widely felt annoyance (higher impact) may have a workaround and be less urgent.
A simple matrix
Rate each ticket as high, medium or low on both questions, then read the priority from a table such as this one:
| Urgency high | Urgency medium | Urgency low | |
|---|---|---|---|
| Impact high | Critical | High | Medium |
| Impact medium | High | Medium | Low |
| Impact low | Medium | Low | Low |
Many teams use four or five labels in all, such as critical, high, medium and low. Fewer levels are easier to use consistently. The exact wording matters less than having each label defined in writing.
Defining the levels
The matrix only works if people agree on what “high” means. Write short, concrete descriptions. For example:
- High impact: a critical service is unavailable, or many people cannot work, or there is a risk to safety, security or legal compliance.
- Medium impact: a department or a group is affected, or an important feature is degraded but usable.
- Low impact: one person is affected or the issue is cosmetic.
- High urgency: work stops now, or there is a fixed deadline within hours.
- Low urgency: there is a reasonable workaround, or no near-term deadline.
Use examples from your own environment. Teams tend to agree faster over “the finance system is down at month end” than over abstract wording.
Worked examples
These are hypothetical.
- The whole office cannot reach the internet. Impact high, urgency high. Priority: critical.
- One employee’s laptop will not start, and they have a spare available. Impact low, urgency medium or low depending on whether the spare is workable. Priority: low or medium.
- A team’s shared folder is slow, but files can be opened. Impact medium, urgency low. Priority: low.
- A sales representative cannot log in an hour before a major customer demonstration. Impact low (one person) but urgency high. Priority: medium by the matrix; many teams allow a documented override up one level for a hard deadline.
- An account looks as though it has been used by someone else. This may be a security matter, so it often follows the incident response route and is treated as high from the start.
Connect priority to response targets
Priority becomes useful when it is tied to expectations, such as how soon the team will respond and how soon it aims to resolve each level. These targets usually appear in service level agreements. Be realistic: targets that cannot be met teach people to ignore them. A critical ticket may also call for notifying a manager or starting a major-incident routine, while a low-priority ticket may simply wait in the queue for the next available person.
Who sets the priority
The person logging the ticket often assigns it initially, using the questions above. Let users describe the effect on their work, but the support team should make the final call, since users naturally see their own problem as the most important one. Make it easy for requesters to explain business context, such as a deadline, because that is information the team cannot guess.
Handling pressure and exceptions
- “Everything is urgent.” Ask what happens if the issue waits an hour or a day. The answer usually reveals real urgency. Skilled staff do this politely, and practicing the calm approach used with difficult callers helps.
- Senior or favored requesters. Have a clear, short list of cases where priority may be raised, and require a note explaining why. Silent queue-jumping erodes trust.
- Changing circumstances. Priority should be reviewed as facts change. A workaround found may lower urgency, while more users reporting the same fault may raise impact. When several tickets share one cause, link them and work on the cause once.
- Out-of-hours work. Teams that cover nights or weekends should state which priorities justify waking someone, to protect both users and people on on-call work.
Keeping it consistent
Consistency comes from practice. Review a sample of tickets each month and see whether two staff members would have ranked them the same way. Where they disagree, refine the written definitions. New staff should learn the matrix with examples from past tickets. Tools like system monitoring can also help by raising the right priority automatically for well-understood alerts.
Treat the matrix as a guide for judgment rather than a replacement for it. Occasionally a ticket does not fit, and an experienced person should be free to adjust it with a note. The goal is a queue that feels fair, in which the problems that matter most are handled first.