An escalation matrix built around incidents classifies a blocked new starter as low severity, because one person affected and no service degraded scores near the bottom. That is correct by the matrix and wrong by every other measure, and it is a gap worth closing deliberately.
TL;DR
- Standard severity scales count affected users, so a single blocked starter scores lowest and waits longest.
- The missing dimension is whether the person can do any work at all, not how many people are affected.
- Day one blockers have a hard deadline that incidents do not: the impression forms whether or not you fix it.
- New starters under-report, so the matrix never sees most of these tickets.
- A time-boxed exception for the first week is simpler than redesigning your severity model.
- Name the escalation path to a person, not a queue, for the first fortnight.
Why the standard scale misclassifies this
Most severity models multiply impact by urgency, where impact is roughly how many people are affected and urgency is how degraded the service is. This works well for infrastructure and badly for individuals.
A new starter who cannot sign in affects one person, degrades no service, and has no revenue attached. Every input points to the lowest band. The ticket enters a queue behind things that are, by the matrix, more important, and it is handled when the queue reaches it.
Meanwhile that person is at one hundred per cent loss of capability, which no standard scale captures because it is not asking about proportion. It is asking about count.
The dimension worth adding
The useful question is not how many people are affected. It is whether the affected person can do anything at all.
Somebody who cannot access one reporting tool is inconvenienced and can work on other things. Somebody who cannot sign in to anything has nothing to switch to. The second case is categorically different and deserves its own treatment regardless of how many people are in it.
Adding a single flag for total blockage, applied to any ticket where the requester cannot proceed with any work, fixes most of the misclassification without touching the rest of your model.
The deadline that does not exist for incidents
An incident resolved in six hours is resolved. The service recovers and the clock has no further meaning.
A new starter blocked for six hours on day one has had their first day, and fixing it afterwards does not give the day back. The impression has formed, and the impression is that this is a place where things do not work and nobody was expecting you. That is expensive in a way the ticket record never shows.
This is the argument for a time box rather than a priority bump. Priorities are relative and get overtaken. A stated commitment that nothing blocks a starter for more than two hours in week one is absolute and much harder to quietly lose.
The tickets the matrix never sees
There is a prior problem that no severity design fixes, which is that a large share of these never become tickets.
A person on day three who cannot access something does not know whether it is broken, not yet granted, or something they have misunderstood. Raising a ticket means declaring in writing that they cannot do their job, during the period when they are least sure how that reads. Most people wait, ask a colleague, and work around it.
What to do:
- Tell starters explicitly, in writing, that raising a ticket in week one is expected rather than tolerated.
- Give a named person as well as a queue for the first fortnight.
- Ask a direct question at the end of week one about what is not working.
- Count blockers found by asking, not only those reported.
- Treat a quiet first week as unverified rather than successful.
A matrix that looked healthy
An eighty person company reported strong service desk performance, with low severity tickets closed well inside target and no breaches for two quarters.
A retrospective with the last eight starters told a different story. Six had experienced at least one blocker in week one. Three had raised tickets. The other three had worked around the problem, one for nine days. The matrix was accurate about the tickets it received and blind to more than half the events.
The change was a week one flag, a two hour commitment for total blockers, and a direct question at day five. Reported blockers roughly doubled in the following quarter, which was the point and had to be explained to a leadership team reading it as a decline.
A workable shape
| Situation | Standard band | With a week one rule | Target |
|---|---|---|---|
| Cannot sign in at all, day one | Low | Treat as high | Two hours |
| One tool missing, can work | Low | Unchanged | One working day |
| Device not delivered | Low | High, no device means no work | Same day workaround |
| Access wrong after week two | Low | Unchanged | Normal queue |
| Cohort blocked together | Medium | High | Two hours |
Where an answering layer fits
Some of what arrives as an escalation is not a fault at all. It is somebody who does not know the access was never meant to be theirs, or who is looking in the wrong place, or who does not know who approves a thing.
Matram is our own product and this is the slice it covers: it reads your documentation and answers those questions before they become tickets, which lowers the volume the matrix has to sort. It has no free tier, it is not an HRIS, and its actions reach HubSpot, Zendesk and webhooks only, so it can open a ticket in a connected service desk but it cannot grant access, reset anything or resolve a genuine blocker. WhatsApp is coming soon rather than available. Pricing is flat at $29, $69 and $199 a month with unlimited seats. A person who cannot sign in cannot reach it, which is the limit worth planning around.
The checklist worth keeping
Checklist:
- A flag for total blockage, independent of how many people are affected.
- A time box rather than a priority bump for week one.
- A named person alongside the queue for the first fortnight.
- A contact route that works without the new device or account.
- A direct question at day five about anything not working.
- Blocker counts taken from asking, not only from tickets raised.
Final Thoughts
An escalation matrix is a good tool asked to do something it was not designed for. Counting affected users is the right instinct for infrastructure and the wrong one for a person whose capability is at zero and who has no other work to switch to.
Add a blockage flag, time box the first week, and go looking for the tickets that were never raised. That last one usually changes the numbers more than the matrix does.
Frequently asked questions
What is an escalation matrix?
It is a grid that maps the impact and urgency of an issue to a severity band, which then determines response targets and who gets involved. It works well for infrastructure problems where the number of affected people is a reasonable proxy for importance, and much less well for issues affecting one person completely.
Why does a blocked new starter score so low?
Because standard scales measure how many people are affected and how degraded a service is, and a single starter who cannot sign in registers as one person with no service impact. The scale is not asking what proportion of that person’s capability is lost, which in this case is all of it, so the classification is internally consistent and practically wrong.
Should we create a separate severity scale for onboarding?
Usually not, because a second scale is more to maintain and creates arguments about which applies. A single flag for total blockage, plus a time boxed commitment for the first week, achieves the same outcome with far less structure. Keep the rest of your model untouched.
Why do reported blockers go up after fixing this?
Because most of them were previously going unreported rather than not happening. New starters work around problems instead of raising them, so a rise in reported blockers after you start asking directly is evidence the measurement improved. Warn whoever reads the numbers before you make the change, or it looks like a decline.
Can a chatbot reduce escalations?
It reduces the share that were never faults, such as somebody looking in the wrong place or not knowing who approves something. It does nothing for a genuine blocker, and a person who cannot sign in generally cannot reach it either. Treat it as a way to keep the queue clear for real problems rather than as a way to resolve them.
What response target makes sense for week one?
Two hours for anything that stops a starter working entirely, and a same day workaround where a full fix is not possible. The precise number matters less than it being absolute rather than relative, because a relative priority gets overtaken by whatever arrives next while a stated commitment does not.
