Why everything is a priority one, and how to stop it

Priority inflation is universal and it is rational. If choosing “high” gets a faster response and costs the requester nothing, everyone chooses high. The scale then carries no information, and triage moves to whoever shouts.

Stop letting people choose their own priority

Priority should be calculated, not selected. The standard approach works: impact — how much of the business is affected — crossed with urgency — how quickly the consequence lands. The requester describes their situation; the system derives the priority.

This single change does most of the work, because it moves the decision from a field to a definition.

Define impact in business terms

The definitions have to mean something to the person raising the ticket. Not “severity 1 — critical system outage” but the concrete version:

• Can people still do the work, with a workaround?
• Is money stopping, or safety affected?
• Is one person blocked, a team, or a site?
• Is there a regulatory or customer commitment attached?

Written this way, a requester can usually place their own issue correctly, and disagreements become factual rather than emotional.

Publish what each priority buys

Every priority level should state what response it gets. Not just a target time — what actually happens: who gets involved, what gets interrupted, whether it is worked outside hours.

This matters because it makes the trade-off visible. Raising something as the highest priority means pulling people off other work, and when that is stated, the number of genuine top-priority tickets falls sharply without anyone enforcing anything.

Give the real emergencies a different route

Part of the inflation is that there is nowhere else to go. If a genuine major incident uses the same form as a password reset, people will over-escalate to be safe.

A separate, well-known path for major incidents — with a named person and a clear trigger — lets the ordinary queue settle down.

Fix the defaults

Look at what the form does when nobody chooses. In a surprising number of systems the default is the highest priority, or the field is mandatory with no guidance, which produces a guess. Defaults do more work here than training does.

Then, and only then, review

Once the definitions are good and the routes exist, a periodic review of misclassified tickets is useful — as calibration, shared back as examples, not as a compliance exercise. Enforcement before definition just moves the argument into the review.

What good looks like

A distribution. Most tickets at the middle and lower levels, a small number high, and an occasional genuine top priority that everybody recognizes as one. If your current distribution is flat, the field is not telling you anything, and any reporting built on it is describing something other than reality.