What Should a Service Desk Escalation Process Look Like?

A good service desk escalation process tells everyone when a ticket moves up, who it moves to, and what happens to it along the way.

 

Tickets move based on priority and how long they’ve been waiting, and ownership is handed over properly, so the client never has to explain the problem twice.

 

Someone also checks every day for the tickets that should have escalated and didn’t.

 

Most MSPs don’t have that. Escalation means messaging whoever’s free or messaging the owner.

So at 9pm, you log back into your PSA. A ticket has been on hold since Tuesday, two have no owner, and a client has emailed you directly because nobody replied. You fix them yourself, because nothing tells you the team has seen them.

“If you’re micromanaging and you’re not giving people the autonomy that they need, you’re going to struggle.”

– Michelle Coombes, Service Improvement Specialist at Uprising

Seven signs your escalation process isn't working

  1. Escalation means messaging whoever’s free, or messaging you
  2. Tier 1 engineers hold onto tickets they should have passed up
  3. Tickets sit unassigned for hours because nobody owns the queue
  4. You hear about an overdue ticket when the client rings to complain
  5. Tickets go on hold and nobody takes them off
  6. Clients repeat the problem every time a ticket changes hands
  7. You check the queue every night, just to be sure

Why it happens

Most service desks grow around the owner. In the early days you see every ticket, so you are the escalation process, and nothing needs writing down.

Then the team grows and nothing replaces you. Engineers escalate on judgement, and judgement varies. Some pass tickets up too early. Others hang on too long because they don’t want to look like they can’t cope.

Nothing flags a stuck ticket, so the client flags it for you.

It also hides your real capacity. One MSP told us their team was too busy to take on more clients, yet their first-line engineers were closing six tickets a day, when 13 to 15 is realistic on tier one.

Tickets were drifting because nobody managed the queue, and the ones that drifted furthest landed on the owner.

How to build your escalation process in three steps

Each step builds on the one before, so work through them in order.

1. Measure how often tickets escalate and breach today

Pull six numbers from your PSA:

  • Total backlog
  • Stale tickets
  • Unassigned tickets
  • SLA breaches
  • Escalations
  • Tickets with a category

Watch the last one. If categories are patchy, every report after will be wrong.

Then name one person accountable for the desk, usually your service desk manager or team leader. Escalations end with them. It shouldn’t be you.

2. Write down the escalation path and check it every day

Define your tiers and when a ticket moves between them. Every ticket gets a tier and an engineer.

Then set up an “Action Required” view in your PSA to catch tickets that should have moved and didn’t:

  • Appointment missed
  • On hold too long
  • Scheduled, but no appointment booked
  • Client waiting days for a reply

Each team clears that view twice a day. Once a week, your service desk lead reviews every stale ticket. Keep them under 5% of the open queue.

3. Turn the path into an escalation matrix

Once the path works, swap judgement for rules:

  • Time limits: set one for each priority. A high-priority ticket left untouched past its limit goes to the team lead, then the service desk manager.
  • Handover standard: agree what the engineer records, who confirms they’ve taken it on, and what the client is told, so the client never explains the problem twice.
  • Weekly report: cover volume, SLA %, backlog and first-time fix by engineer and client, plus Action Required tickets by type and team.
  • Categories: make them mandatory and check their accuracy monthly. Aim for 90% coverage before you trust the numbers.
  • Review rhythm: write down who reviews what daily, weekly and monthly, with the same measures on every dashboard.

Now escalations reach you only when the rules say they should.

What this looks like in practice

In one of my MSPs, I had exactly this habit. I’d open one ticket, then another, and two hours would disappear. I’d been away from the process long enough that I was doing it wrong.

So we took me off the ticket queue and gave me a dashboard instead. Green meant fine. Amber belonged to the team lead. Red was the only colour I was allowed to ask about, and only through the operations manager, never straight to an engineer.

The desk improved because I could no longer interfere, and the team lead finally owned it.

What to do next

Start with step one. Pull your numbers this week and see how often tickets are escalating, breaching or going stale.

The Service Desk Escalation Pack gives you what you need to measure your queue, run the twice-daily Action Required review and build a weekly service report, so your escalation process runs without you.

Get Your Service Desk Escalation Pack

Where this conversation goes next

Michelle Coombes podcast coming soon.

Share this post :