A support ticket priority matrix sets a ticket’s priority from two things. Impact, which is how much is stopped and for how many people. Urgency, which is whether the damage grows while the ticket waits. Cross the two, read one level off the grid from P1 down to P4, and work in that order. Ours is filled in below and you are meant to change it.
The definitions are the easy half of it and they are not where the thing falls over. A matrix falls over on account of the two words along the top and down the side quietly turning into the same word, which takes about a fortnight, and after that you have got a picture of a decision rather than the making of one, and everybody carries on filling it in all the same.
We make a help desk and one of the fields in it goes by the name of priority, so take the interest into account while you read. The grid below is not our field though. It works on a whiteboard, and it worked on whiteboards for a good long while before any of this was software.
What a support ticket priority matrix actually decides
One thing, which is the order of the work. That is a smaller job than the name suggests and it is worth being clear about, seeing as three other decisions get bundled in with it constantly and then blamed on it afterwards when the week goes badly.
It does not decide what you have promised. The promise is a target, an hour to first reply or whatever you have settled on, and that lives in your SLA policy, where we have gone and set the whole of it out already on SLA compliance. It does not decide whose ticket it is, which is its own separate deciding with its own separate mess. And it certainly does not decide whether you have the people, seeing as a queue sorted beautifully is still the very same pile of work it was before anybody sorted it, and if it is half again too big for the four of you then the sorting has not touched the actual trouble.
There is one more distinction worth having and almost nobody prints it, which is the difference between severity and priority. Severity describes the fault. It is a property of the thing that broke and it sits there being the very same thing whether anybody is looking at it or not. Priority describes what you are going to do about the fault, and it very much does change, on account of it depending on who is affected and what else is on fire this morning. The same bug can be severity one on a Tuesday when it is stopping payments and priority three on the Friday when the workaround is documented and two people are using it happily. ITIL and the wider ITSM world keep the two words apart carefully. Most support desks use the two words interchangeably and then wonder why the engineers and the support people keep disagreeing about the very same ticket, funnily enough, and that disagreement runs on for years in some places without anybody once going and writing the two definitions down beside each other.
Why impact and urgency stop meaning anything if you let them blur
Here is the failure, and it is quiet enough that a desk can run on a broken grid for a year without anybody noticing the break, seeing as the thing keeps producing levels the whole time and a level looks the very same on a ticket whether the reasoning behind it held up or fell over quietly back in March.
Impact holds up fine, mostly. It is countable. How many people are stopped, how much money is not moving, how many transactions are failing an hour, and you can go and count each bit of it without asking anybody’s opinion. Urgency is the one that goes. It starts out meaning something specific and useful and then drifts, and where it drifts to is “how quickly ought we to answer this”, which is the very answer the grid was built to produce. Multiply the answer by its self and you get the answer, and the grid becomes a thing you fill in afterwards to justify what somebody already decided at half eight.
So pin urgency down and keep it pinned. Urgency is a fact about the ticket’s future rather than a fact about your intentions. Does the damage grow while this waits, and in what units. A failed payment run grows in money and it grows every hour. A missed regulatory deadline grows in a way that eventually involves people who bill by the hour. A customer who cannot change their profile picture does not grow in anything whatever, they are simply annoyed, and they will be exactly as annoyed on Friday as they are now and not one bit more.
That test does a second job you get for nothing, mind you. It takes tone out of the deciding, or at least it makes tone visible when it creeps in, on account of a furious paragraph about a logo colour still having nothing to grow into. Tone is the other great destroyer of priority fields and it has a piece of its own coming, so we will leave the whole of it at one sentence here and send you onward when that page lands.
The filled grid, and the boxes worth arguing about
Three impact bands down the side, three urgency bands across the top, four levels falling out of the middle. Copy it, disagree with a row, change the words to the ones your own company actually uses. It is more useful to you argued over than adopted.
| Impact, and who is stopped | Urgency: damage grows by the hour | Urgency: bad now, no worse tomorrow | Urgency: waiting costs nothing measurable |
|---|---|---|---|
| Everyone. All customers, or the whole company | P1 | P2 | P3 |
| A group. One team, one account, one region, one integration | P2 | P3 | P3 |
| One person, and no workaround | P3 | P4 | P4 |
The corners are not the interesting part. Everyone stopped and getting worse is a P1 in every company on earth and nobody needed a grid to work that out. The arguing lives in the middle of it.
Take the top right box, everyone affected and nothing growing. A cosmetic fault on every page of your product is genuinely a P3, and that lands badly the first time somebody says it out loud in a room, seeing as it is visible, and visible feels urgent, no two ways about it. Nothing is being lost while it sits there though. Then the bottom left, one person and the damage climbing, which comes out P3 and is the box that will cost you an argument roughly monthly, and it is the one row a great many desks end up quietly editing until it reads P2, which is a change worth making on purpose rather than by drift. One person locked out on the morning their quarter closes is going to escalate, and they will be right to, and the grid still says P3, and what that tells you is not that the grid is wrong. It is telling you the deadline is doing the work rather than the head count, and a deadline belongs in urgency where you can see it, not smuggled into impact by somebody who wants a faster answer.
Two things ignore the grid entirely and they want writing down beside it. Anything with a legal clock on it goes and takes a P1 the moment it is suspected rather than confirmed, so a possible data exposure, a GDPR notification window, a PCI or SOC 2 question with teeth, and you argue about whether it was real afterwards and not before. And a feature request has no priority at all, ever, since priority describes an order of work and a request is not work yet. Put it on a list. Do not put it in a queue, and do not let anybody stamp it P4 either, since P4 means we will get to this and a list does not promise that. Where the same fault turns up from three customers inside an hour it has stopped being a ticket and turned into an incident management problem, which runs a different process, and the grid hands it over rather than trying to hold it.
What each level promises, and what it displaces
Now the table nobody publishes. Every priority scheme in the world prints a definition column, most of them print a response target beside it, and the column that actually changes behaviour is the third one, which is the one nobody prints, seeing as it is the only column that costs a named person something on the day it gets used.
| Level | What it means | What happens to it | What it displaces |
|---|---|---|---|
| P1 | Everyone stopped, damage growing, or a legal clock running | Somebody is interrupted, now, by name. Work in progress goes down mid-sentence | Everything. If nothing was put down, this was not a P1 |
| P2 | A group stopped and growing, or everyone stopped and static | Next thing picked up, before anything older | The rest of today's queue, in order |
| P3 | One person stopped, or a group inconvenienced | Worked in turn, oldest first, inside the normal day | Nothing. It waits its turn honestly |
| P4 | Nobody is stopped. Annoyance, cosmetic, tidy-up | Batched, or done in the quiet hour on a Friday | Nothing, and it may sit for a fortnight |
The fourth column is the one to read twice. A priority is not really a description of how bad a ticket is. It is a decision about what you are prepared to put down for it, and a level that displaces nothing at all is doing no work whatsoever in your week, truth be told. This is why a desk with five levels and no displacement column behaves exactly like a desk with one level. You went and changed the labels and the week carried on exactly as it had been carrying on before.
The rows also want to be true in the other direction. If your P2 never actually goes before anything older, then you have not got a P2, you have got a P3 with a nicer name on it, and the honest move is to go and delete the level rather than carry on filing things into it. Where the levels line up with who does the work rather than with what the work is, that is a different arrangement again and it is written up as support tiers.
Why a priority is a statement about what you are dropping
You can see this one in a room. Somebody reads out the queue at standup, and every open ticket is a P2, and everybody nods, and the meeting ends. A queue where everything is a two is a queue with no priorities in it at all. It only looks like a sorted queue because the field has been filled in on every row of it.
The reason it happens is not laziness. It is that stamping a P1 is uncomfortable if the stamp means something, seeing as it means going to a colleague on Slack or in Teams or across the room, somebody halfway into a thing of their own, and telling them that the thing of their own is now second. Nobody enjoys that at ten past nine on a Wednesday. So the middle fills up, and it fills up quietly, and the person doing the stamping is not being careless about any of it. Fair is fair, a good deal of what looks like sloppy prioritising is somebody trying not to ruin a colleague’s morning.
Which is why the rule that works is a bit of writing rather than a bit of software. When a ticket goes to P1, whoever raised it goes and writes one line in the ticket naming what it displaced. Pulled somebody off the billing investigation. Stopped the release notes. Anything at all, so long as it is a real thing with a name attached to it. Two weeks of that and the P1 count falls by its self, without a policy, without a meeting, without anybody being told off, on account of the line being impossible to write when the honest answer is nothing.
How the top of the grid inflates, with the arithmetic
Say 84 tickets land in a week on a desk of four. These numbers are invented for the shape of it and they are nobody’s benchmark of any description, so please do not quote them at your own team.
Of the 84, say 22 arrive marked urgent by the person sending them, which is the customer’s guess and it costs them nothing to guess high. The desk stamps 19 of those as P1 or P2, mostly because arguing with a customer about their own urgency is a poor use of a Monday, and losing that argument in front of an account manager on the Tuesday is a worse use of one, so the stamp goes on and everybody carries on with the morning. Now do the sum nobody does. 19 interruptions across 5 days on a desk of four is very nearly one a day each, and an interruption is not the fifteen minutes the ticket takes, it is the fifteen minutes plus however long it takes to get back into what you were doing, which for anything with thinking in it is another twenty. So somewhere around 11 hours of the week went on being interrupted, and the tickets themselves took maybe 5.
Nobody sees those 11 hours. They do not turn up in a report, they are not attached to any ticket, and at the end of the week the desk simply feels harder than the ticket count says it should, which is a complaint every support manager has made and almost none of them have been able to evidence. Those 11 hours are the cost of it. That is also why the cap on P1 is not a percentage anybody can hand you. It is however many interruptions your desk can absorb in a day before the rest of the queue stops moving, which on four people is a small number and on twenty is a different small number, and your own last quarter is the only place to find it.
The reflex when this happens is that somebody goes and adds a level on top of urgent, and it has not worked anywhere we have ever looked, for reasons that belong to a different page than this one.
What the grid has not got, which is time
The matrix stamps once, at arrival, using what was known at arrival. Then the ticket sits there and the world carries on moving around it.
A P3 that has been open eleven days is not a P3 to the person who raised it. It has become the thing they mention every time your company comes up, and they have gone and told two colleagues about it, and none of that appears in the priority field, which still says three because three was correct on the day it was set. The customer’s own sense of urgency grows on a clock the grid cannot see. So does the damage sometimes, mind you, since the workaround that made it a P3 in the first place tends to stop working eventually.
Two ways to handle it and they are not equal, truth be told. The weak one is conscience, so somebody promises to review the old tickets on a Friday, and they do it twice. The one that survives contact with a busy month is a rule that raises the level on elapsed time. A P4 that reaches 30 days becomes a P3, a P3 at 14 days becomes a P2, whatever numbers suit the shape of your week, and the point of writing them down is that the promotion happens without anybody having to feel bad about it first. Where a ticket climbing on its own would come as a surprise to the customer, the escalation conversation belongs there rather than in a notification nobody reads, and it is worth the awkwardness of having it properly.
A Wednesday morning, sorted twice
Six things arrive between half eight and ten. Numbers invented again, the shapes real enough.
Sorted by feel, the way it goes when nobody has a grid, the order came out like this. The furious paragraph about the button colour went first, on account of it being furious. Then the customer asking politely why their monthly export came back as an empty CSV, since exports sound technical. Then the password reset, which is quick and clears a row. Then the two-line note about card payments returning an error, which was short and calm and read like a one-off. Then the stuck integration for one team, which looked like a job for the afternoon. And last, an attachment somebody sent through that appeared to have an API key sitting in it, which the first reader did not spot at all, seeing as they were reading the covering sentence and not the file.
Now sort the very same six through the grid. Card payments failing is everyone, and it grows every hour there is a card machine open anywhere, so P1, and it goes first by a distance, and the fact that it turned up in two flat lines with no exclamation marks in them changed nothing whatsoever about that. The suspected key in the attachment is the legal clock, so P1 as well, and it does not matter one bit that it might turn out to be nothing. The empty export belongs to one person, and the damage is growing on account of the deadline sitting on the Friday, so P3 by the grid, and this is the row where the room will overrule the grid and raise it, and that overruling is the system working. The stuck integration is a group and it is static, P3. The password reset is one person, static, P4, and it still gets done in four minutes because it takes four minutes. The button colour is one person, nothing growing, P4, and the fury changed nothing at all about where it sits.
Two of the six moved a long way and the rest of it barely shifted, which is the return on the grid and it is enough, seeing as the two that moved were the two carrying money and a legal clock between them. It is not that the grid is clever. It is that the grid goes and asks the very same two questions of a calm email and a furious one, which a person at half eight with nineteen unread cannot do reliably, however good they are and however much they mean to.
Where our own software sits in this, which is one field of it
Plainly said, and before any of the rest of it. Maxdesk has no matrix. There is no impact field, no urgency field, and no grid to fill in on a settings screen, so the deciding stays with you and always will on our product.
What we have got over here is the field the deciding lands in, and the things that hang off it. Priority is a real field on the ticket. Your SLA policy sets a first reply target and a resolve target by priority, so the number attached to P1 is a different number from the one attached to P3, which is the mechanism that turns a level into a promise rather than a colour. A default policy is switched on from day one at 1 hour to first reply and 8 hours to resolve, and you will want your own numbers there soon enough. The countdown itself runs on the ticket, so the person holding it can see the time going rather than reading about it afterwards in a monthly deck. Breaches get counted live on the dashboard. Automation rules will go and stamp a priority on arrival from a sender or a subject line or the form a thing came through, and that covers the easy half, the half you could think of in advance.
On the Elite workspace at $99 a month the AI support agent reads the words of the ticket properly and sets the priority off the issue it reads there rather than off the tone, which is a different instrument altogether from a rule matching the word urgent in a subject line. Worth being clear about what that is and is not, mind you. It reads the ticket in front of it and nothing else. It does not know your grid, it has not got your impact bands, and it cannot know that the polite one-sentence export question came from the account renewing in November, on account of that fact living in your CRM or in somebody’s head rather than in the words of the ticket. Free and Pro have no AI at all, which we would rather have in this paragraph than in a footnote.
One more, and it is the honest sort. Whether an automation can fire purely because a ticket has aged, which is what the promotion rules further up want, is a thing to check on the day you set it up rather than take from a page of ours. We will not have you designing a scheme around a trigger we have not put in front of you.
What a priority matrix will not do, taken honestly
It sorts the queue and does nothing whatsoever about the size of it. Eighty four tickets stay eighty four however elegantly they get ordered, and if the four of you cannot work eighty four in a week then the grid has told you the order in which you will be late, which is genuinely worth something and is not what anybody buying a scheme is hoping for.
Then the awkward one, which we may as well raise ourselves since it is sitting on our own site. We have taken a fairly dim view elsewhere of the big target grid, the one with four priorities down one side and three channels along the other and twelve separate numbers filled into the middle, which tends to get written in a quiet fortnight and opened by nobody afterwards. That still holds, mind you. It is not a contradiction of this page, it is the line between two objects that get muddled: the matrix here decides the level and it is meant to be filled in and argued over, whereas the targets hanging off those levels want to stay few enough that anybody in the room can recite them from memory. Fill the grid in properly, then keep the promises few enough to say out loud, and the two of them sit beside each other without any bother at all.
Under about three or four people the whole apparatus is overhead as well. Two people who talk to each other all day sort their queue by talking to each other, and writing the grid down buys them nothing but a document that will go stale by March. It starts earning its keep at the point where the sorting is being done by somebody who cannot see what everybody else is holding that morning, which is a different desk entirely and you will know when you get there.
And the plain ones, which are ours. Mail is the only channel we ship, so a queue arriving by phone is not a queue we can sort for you at all. The free workspace runs ads and puts our name on outgoing mail, and it holds 3 months of history, and that window matters more here than it does on most subjects, seeing as the only honest way to settle an argument about whether your P1s are real is to sit down with last quarter’s P1s and read the lot of them. Three months of that on $0, 12 months on Pro at $20, 24 on Elite. Active automations are capped on free too, and priority rules are exactly the sort of thing you will want more of by month two. Plan figures on this page were true as of 31 August 2026, and the next re-check on them falls in January.
How to fill one in for your own desk, in an afternoon
Two jobs. Neither of them needs a budget or a meeting or anybody’s sign-off.
Pull every ticket you marked urgent last month, all of them rather than a sample, and put each into one of two piles. Damage was growing while it waited. Damage was not. Do not let anybody argue the second pile down, and expect the second pile to be bigger than the room guessed, which is uncomfortable for about ten minutes and useful for a good deal longer than that. That afternoon gives you an urgency column you wrote your own self, with your own products in the rows of it rather than ours.
Then write the displacement column before you write anything else. What does a P1 stop, here, in this company, on a normal Wednesday. If nobody in the room can answer that in one sentence then the levels underneath it are decoration whatever else gets filled in, and it is a good deal better to find that out with a blank table in front of you than with a queue full of twos in three months’ time.
Common questions about ticket priority matrices
What is a support ticket priority matrix?
A grid that sets a ticket’s priority by crossing impact, meaning how much is stopped and for how many people, with urgency, meaning whether the damage grows while the ticket waits. Most desks run three bands on each axis and read off four levels, P1 to P4. The grid decides the order of work and nothing else.
What is the difference between priority and severity?
Severity describes the fault and does not change when you look at it. Priority describes what you are going to do about the fault, and it changes with who is affected and what else is happening that day. The same severity-one bug can be a P1 while it is stopping payments and a P3 once a workaround is documented.
What is the difference between impact and urgency?
Impact is countable, meaning how many people or transactions or pounds are stopped right now. Urgency is whether that damage grows while the ticket waits. If a ticket will be exactly as bad on Friday as it is today, it is not urgent, however strongly it was worded. Urgency must never mean how fast you intend to reply, because that is the answer the grid exists to produce.
How many priority levels should a support desk have?
Four is plenty for most desks and three works. The test is not the count, it is whether each level displaces something different. If your P2 never goes before anything older than itself, it is a P3 with a nicer name and the level should be deleted rather than kept.
What should count as a P1?
Everyone stopped with the damage growing, or anything carrying a legal clock, such as a suspected data exposure or a notification window under GDPR. A useful discipline is that raising a P1 requires writing one line in the ticket naming what it displaced. If nothing was put down for it, it was not a P1.
Does Maxdesk have a priority matrix?
Not as a feature. There is no impact field, no urgency field and no grid object, so the matrix stays yours. What Maxdesk carries is the priority field itself, SLA policies with a first reply and resolve target set by priority, a default of 1 hour to first reply and 8 hours to resolve, a countdown on the ticket, and automation rules that stamp priority on arrival. The Elite plan’s AI agent sets priority by reading the issue.