GUIDE · SERVICE DELIVERY
MSP service-delivery review: escalations, exceptions and recurring work
Reactive operations rarely come from one big failure. They come from three quieter things: work that escalates for the wrong reasons, client-specific exceptions that slow every ticket, and the same problems recurring because nobody owns fixing them. All three are visible in a ticket export if you know where to look.
By The founder of MSP Reboot, who co-founded an MSP in 1999 and ran it until it was sold in 2023.
Published
Pull ninety days of tickets
Ninety days covers a full month-end, a patch cycle or two and enough volume to see patterns, without old processes muddying it. Export from the PSA with these fields, or as many as you have:
- Client, contact and site
- Created, first response and closed timestamps
- Category or type, priority, and source (email, phone, portal, alert)
- Assigned technician, every reassignment, and the final resolver
- Time logged, and whether the ticket was reopened
- Whether it was inside or outside the agreement
If categories are unreliable
Technicians often pick the first category in the list. Before analysing, read a random sample of fifty tickets and re-categorise them by hand. It takes an hour and tells you how far to trust the rest.
Part 1: escalations
An escalation is any ticket that moved to a more senior person than the one who first picked it up. Count them, then find out why each one moved.
Map the path you actually have
- List every reassignment chain in the export: first technician, each person it moved to, final resolver.
- Count how many tickets ended with the owner or the most senior technician.
- Compare that with the written escalation path, if there is one. The difference is the real path.
Classify the reason for each escalation
| Reason | What it looks like | Usual fix |
|---|---|---|
| Knowledge | The first technician did not know how | Runbook, training, pairing on the next one |
| Access | They knew how but lacked a password or permission | Documented, role-based access |
| Authority | They needed approval to spend, schedule or say no | Written decision limits |
| Client pressure | The client asked for someone senior | Expectations set in the agreement and at onboarding |
| Habit | It always goes to that person | Escalation path enforced by the senior person, not around them |
Knowledge escalations are healthy in small numbers. Access, authority and habit escalations are process problems, and they are usually the ones that pull the owner into the queue.
Part 2: client exceptions
An exception is anything done differently for one client: a different backup product, after-hours cover nobody else gets, a custom approval step, a technician who is the only one allowed on the account. Each one makes every ticket for that client slightly slower and slightly riskier, and the costs add up across the queue.
- Inventory them. Ask every technician for the client-specific things they have to remember. You will get a longer list than any document holds.
- Note where each one came from. A client request, a sales promise, an old tool never migrated, a past incident.
- Estimate the effort, not the money. Which exceptions show up in reassignments, longer resolution times or reopens in the export?
- Decide one of three things for each: standardise it away, price it as a defined add-on, or keep it deliberately and document it properly.
Exceptions that turn out to be unpriced scope belong in the pricing review.
Part 3: recurring work
Recurring work is the same problem arriving again: the printer at one site, the same backup job failing, password resets for the same users, the monthly report rebuilt by hand. Some is legitimately recurring and should be scheduled; most should not exist.
Find it
- Group tickets by client and category, then by keywords in the subject line. Sort by count.
- Look at reopened tickets separately: a reopen is recurring work within a single ticket.
- Separate alert-generated tickets from human ones. Noisy alerts are recurring work too.
Decide what each pattern needs
| Pattern | Question to ask | Typical decision |
|---|---|---|
| Same fault, same client | What is the root cause, and who owns fixing it? | A small project with a named owner and a date |
| Same task, every client | Is this maintenance pretending to be support? | Schedule it, or automate it |
| Same request, same users | Is there a training or self-service gap? | Documentation or a client-side change |
| Same alert, no action taken | Does anyone act on this alert? | Tune it, or turn it off |
A hypothetical example
Hypothetical — not a client and not a result
This is an invented scenario to show how the three parts connect. It is not a real MSP and claims no outcome.
Imagine the export shows that a large share of escalations end with the owner, and most are classified as authority, not knowledge: technicians needed approval to schedule after-hours work for two particular clients. The exceptions inventory explains why. Both clients were promised after-hours changes on request during their original sale, and nobody wrote down the terms. The recurring-work view adds that one of those clients accounts for a cluster of repeat backup failures that get fixed every week and never root-caused.
Three findings, one underlying problem: an undocumented promise. The changes are equally unglamorous: write the after-hours terms into the agreement (and price them, if they were never priced), give the service manager authority to schedule within those terms, and open a small project with an owner to fix the backup fault once.
What the review should produce
One page, not a deck:
- The five changes that would remove the most escalations, exceptions or repeat tickets.
- For each: who owns it, the date it will be done, and what you will look at to see whether it worked.
- A date to re-run the same export and compare, ninety days later.
Repeat the review every quarter. The first one is the hardest; after that it is mostly checking whether last quarter’s five changes held.
Bring the export and your top five to the free hour.
An hour on your own ticket data usually shows where the operational complexity is coming from. You will leave with initial direction, and an honest view of whether a paid diagnostic would add anything.