By Yair Knijn · February 23, 2025

When every agent sets priority by gut feel, your P1 definition is whatever today's loudest customer says it is

The operations manager looks at the queue and sees a priority on every ticket. The field is mandatory; nothing closes without it. So the assumption sets in quietly: priority is being set consistently, because it is always being set. That is the trap. A populated field is not a classified ticket. If no rule binds impact and urgency to a level, the value in that field is whatever the agent felt when they typed it.

And what agents feel is mostly volume. The customer who calls three times and copies their account manager gets a P1. The quiet one whose authentication service is degrading for two hundred users gets a P3, because they asked politely and nobody escalated. Priority stops measuring damage and starts measuring noise.

Impact times urgency: the matrix every desk claims to use and few enforce

ITIL is unambiguous here. Priority is a function of two inputs: impact, meaning how much of the business is hurt, and urgency, meaning how fast it has to be fixed. High impact and high urgency is a P1; low and low is a P4. Most desks will tell you this is how they work. Pull ten closed tickets and check the math and you find the matrix lives on a wiki page, not in the workflow. The InvGate and TOPdesk write-ups on priority matrices both land on the same point: when impact and urgency are left as subjective text fields, agents misclassify, and the classification drifts toward whoever shouted.

The fix the ITSM vendors describe is not a better training session. It is structural. The agent records the affected service, the impact, and the urgency, and the platform computes the priority from those answers. The human supplies facts; the tool applies the rule. The moment you let the human supply the conclusion, the rule is decorative.

Why the loudest customer trains your agents to inflate priority

Inconsistency is not random. It has a direction, and the direction is up. An agent who under-prioritizes a loud customer gets a manager forwarding an angry email within the hour. An agent who over-prioritizes a quiet one gets nothing. There is no symmetric punishment for inflation, so the queue inflates. Within a quarter half the board is P1 and P2, the SLA clocks that were supposed to protect the worst incidents are spread evenly across everything, and the priority field carries no information at all.

This is operant conditioning, not malice. You taught the desk that escalation follows complaint volume rather than business impact, and the desk learned. The agents are behaving rationally inside the incentives you left in place.

The silent P1: how a misclassified ticket becomes a major incident

The expensive failure is the inverse: a real P1 wearing a P3 badge. A sync job fails overnight. The agent who opened it saw one stalled integration and one calm requester, so it landed mid-queue with a relaxed clock. Nobody knew it was the order pipeline for your largest account until that account's operations lead called your director directly. By then the resolution clock had been ticking against the wrong target for ten hours, the major-incident process never fired because nothing told it to, and there is no audit trail showing a decision because no decision was made. A field was filled in.

The director's first question is never "who got it wrong." It is "how often does this happen and we never find out." If priority is set by gut feel, the honest answer is that you cannot know.

Codifying the matrix so the tool sets priority, not the agent's mood

Turning the matrix from documentation into enforcement is concrete work:

• Make impact and urgency the inputs. Replace the free-typed priority field with two structured selectors tied to defined criteria, and let the system derive the level.
• Anchor impact in real terms: number of users, whether a critical service is down, exposure to revenue or compliance. Publish those definitions to customers too, so urgency is not negotiable by phone.
• Lock the SLA clocks to the computed priority so the timer attaches to severity, not to who escalated.
• Require a logged justification for any manual override, and review overrides weekly. Persistent override patterns are where your real classification problem hides.

OpsDesk computes priority from impact and urgency inside each workspace, attaches the response and resolution clocks to the level the rule produced, and keeps an audit trail of every classification and override. The matrix stops being a page someone wrote and becomes the thing the queue actually obeys. If you want to see your own classification drift, the ticket lifecycle view shows exactly where priority was set, by whom, and whether the math held.