MSP ticketing system hides the real resolution times behind averages
Your MSP's monthly report shows a clean average resolution time. The CFO likes the chart. The help desk still hears from people who waited three days on a password issue and four hours on a plant-down ticket their ticketing system already marked closed. Their averages. Hiding the facts that hurt you.
When businesses break up with an MSP, the fight is rarely "we never get tickets." It is "we cannot trust what the ticket system says happened." Selection is the moment to catch that, before the first invoice under the new contract.
How averages hide real resolution time
Ticket platforms make averages easy. Averages make bad distributions look healthy. Common tricks you will see in live MSP operations:
- Mixing severities. P1 outages and password resets share one mean. A fast pile of easy tickets pulls the average down while the few hard tickets that stop revenue still drag for days.
- Clock stops that favor the vendor. Time in "waiting on customer," "waiting on vendor," or "pending change window" drops out of the clock. Some of that is fair. Some of it is the MSP parking work until the SLA math looks good.
- Reopen and reopen-again. Ticket closed at first reply. User comes back. New ticket or reopen that never links cleanly to the original. Resolution "met" on paper; user still stuck.
- Priority games. Work gets downgraded after intake so the remaining clock matches a softer tier. Or everything arrives as P3 because P2 would break the report.
- Batch close-outs at month end. A burst of closures cleans the queue for the QBR slide. Nobody shows the age of the tickets the day before the close-out.
None of this requires malice. It is what happens when the commercial conversation rewards a single number and nobody asked for the distribution underneath it.
What good reporting looks like in selection
Look for proof the MSP can show work the way you will manage them, not the way a slide deck prefers:
- Percentiles, not only means. Median and 90th percentile resolution by priority beat a single average every time.
- Separate clocks by priority. P1, P2, and standard requests never share one blended number as the headline KPI.
- Clear pause rules in writing. When the clock stops, who starts it again, and how that shows in the export you can audit.
- Reopen rate and linked tickets. Closures that bounce back should show up as a quality signal, not disappear into a new ticket ID.
- Sample ticket extracts from comparable clients. Redacted rows with open time, first response, resolve time, priority history, and pause reasons. A chart without a sample is marketing.
If a finalist cannot produce a redacted extract and only offers a polished average, treat that as a selection signal. You are buying the reporting system as much as the engineers.
How to score this in your matrix
Give service desk quality and reporting real weight before proposals open. Score anchors might look like:
- Strong: percentile reporting by priority, written pause policy, reopen metric, and a real sample extract from a similar client
- Acceptable: priority-split SLAs with means plus at least one distribution view, and a clear answer on how reopens are counted
- Weak: one blended average, no pause definition, no reopen story, "we can customize dashboards after kickoff"
Must-pass gates can still kill a bid (coverage hours, security requirements). Reporting quality belongs in the weighted score so a cheap bid with opaque tickets cannot hide behind a smooth QBR template.
Where ITBluPrint fits
Vendor-neutral selection work includes pressure-testing how an MSP will prove delivery after signature, not only how they pitch it. That means the matrix, the evidence asks, and the award memo all force the same standard on every finalist.
If you want a second set of eyes on whether your shortlist can prove real resolution performance, start with a free advisory session at itbluprint.com/contact-us.
