Service Management
Priority is not an opinion: impact, urgency and the SLA clock
Why we calculate the priority of an incident from a matrix instead of letting people argue about it, how SLA deadlines are derived within business hours, and when the clock is allowed to stop.
Every service desk knows the sentence “But this one is really urgent.” It is said on the phone, written into tickets and occasionally delivered in person by the boss. The problem is not that it is wrong. The problem is that it cannot be compared. When three callers say “really urgent”, somebody still has to decide who goes first.
That is why OpsCloud365 calculates the priority instead of asking for it.
Two questions instead of one opinion
When creating an incident, the agent answers two questions. How big is the impact, meaning how many people or which services are affected? And how urgent is the fix, meaning how long can things stay as they are? The priority matrix turns both answers into a priority from P1 to P4.
The trick is not the matrix itself; every ITIL book has one. The trick is that the argument moves somewhere else. People no longer argue about “P1 or P2” but about “does this affect the whole site or one person”. That question can be answered. And if the matrix does not fit your organisation, you change the matrix, not the answers.
The clock runs in business hours
Deadlines follow from the priority. Every service in OpsCloud365 can have its own SLA; incidents without a service SLA use the default one. An SLA defines a response and a resolution time in minutes per priority, and whether those times run only within business hours. A P3 with eight hours of resolution time, reported on Friday at 4 pm with business hours ending at 5 pm, is due on Monday at 4 pm, not on Saturday morning.
The incident shows both deadlines in a panel of its own: response due, responded at, resolution due, resolved at, plus a bar showing how much of the resolution time is already used. Filter the list by “SLA breached” and you see immediately where it burns. A background job refreshes the breach flags every 15 minutes, so the display does not depend on whether somebody happens to open the ticket.
When the clock may stop
There is one legitimate reason to stop the clock: when the work is not with the service desk. The requester has not replied yet, a spare part is on order, an external provider is on it. That is what the “On hold” status is for. It requires a reason and pauses the SLA clock. The time spent on hold is shown on the incident in minutes.
What deliberately does not exist: quietly resetting the deadline. An incident that gets reopened gets a counter, not a fresh start. If a ticket has been reopened three times, that is information, not a cosmetic issue for the statistics.
Major incidents: be loud when it matters
Sometimes a P1 is more than a P1. When the ERP system is down for every site, it helps nobody if a hundred people call one by one. A P1 can therefore be flagged as a major incident. It then appears in the self-service portal as a current outage, with start time and affected service.
What counts in the end
At the end of a week it is not the single ticket that matters but the pattern. The ITSM dashboard shows incidents by status, open incidents by priority and group, the weekly volume and the list of SLA breaches. If you see the same group at P2 every week, you know where a conversation is due.
One last thought: none of this replaces judgement. An experienced agent recognises when the matrix is off in a particular case and may change the priority. But they do it visibly, with history, and not because somebody was louder than everybody else.
All images show the real application with fictitious demo data.