Service desk

MSP SLA response times: setting targets you can actually hit

Most MSP SLA response times were copied from someone else's contract. They looked reassuring in the proposal, nobody has measured them since, and the first person to read them closely is an unhappy client with a lawyer. This guide covers what response actually means, sensible targets by priority, and how to set numbers your service desk can hit every month, not just in a good week.

Response is not resolution, and both need defining

The single most common SLA failure is not a missed target. It is a contract where "response" was never defined, so the MSP and the client are measuring two different things in good faith.

Pin down three separate clocks:

• First response: a qualified human has read the ticket, triaged it and told the client what happens next. An automated "we got your email" receipt does not count, and clients notice when it is passed off as one.
• Resolution: service is restored or a workaround is in place. Not "root cause fully understood", which can take much longer and belongs in a post-incident note, not the SLA clock.
• Updates: how often the client hears from you while a ticket is open. On a P1 that might be every 30 minutes. Silence during an outage does more contract damage than the outage itself.

Write all three into the agreement, per priority level. If your PSA or service desk cannot report on all three, that is a tooling gap to fix before you sign anything.

Typical MSP SLA response times by priority

Numbers vary by market and price point, but most healthy MSP agreements land close to this shape:

• P1, critical: a whole site or core system is down. First response in 15 to 30 minutes, work continues until service is restored, updates at least every 30 to 60 minutes.
• P2, major: a team or key function is degraded. First response within 1 to 2 hours, resolution targeted the same business day.
• P3, minor: one user affected, work continues with friction. First response within 4 business hours, resolution by the next business day.
• P4, request: new starters, changes, questions. First response within 1 business day, fulfilment within 3 to 5.

Two caveats before you lift these into a contract. First, they assume business-hours cover; if you sell 24/7, the P1 line is the expensive one, so price it deliberately. Second, these are ceilings, not ambitions. If your desk routinely responds to P3s in 20 minutes, keep the 4-hour promise anyway. The gap between what you promise and what you deliver is your margin for the bad week, and every desk has bad weeks.

Priority must come from impact, not volume

An SLA is only as good as the triage behind it. If priority is set by whoever shouts loudest, every ticket from the shouty client becomes a P1, your team burns out chasing false urgency, and the genuinely critical ticket from a quiet client waits.

The fix is a simple, written impact and urgency matrix: how many people are affected, and can they work at all? A payroll server down on the 28th of the month is a P1 even if the ticket arrived politely. A director's second monitor is a P3 even if it arrived in capitals. Put the matrix in the client agreement too, so priority is a shared definition rather than a negotiation on every ticket.

Triage quality is also where alert-driven tickets earn their keep or destroy it. If your monitoring floods the desk with noise, technicians stop trusting priorities altogether, and the SLA clock runs on tickets nobody should be seeing. We covered how to fix that at the source in our guide to cutting MSP alert noise.

The mechanics that quietly break SLA reporting

Even sensible targets fall over on the details of how the clock runs. Four mechanics to get right in your tooling:

1. Business-hours calendars. A P3 logged at 16:55 on Friday should not breach at 09:05 on Monday because the clock ran all weekend. Every SLA needs a calendar, including client-specific holidays if you serve multiple regions.
2. Pause states. When a ticket is waiting on the client or on a vendor, the clock should pause, and the status change should be logged so the report can prove it. Without this, your worst-looking breaches are tickets where you were waiting three days for a reply.
3. Reassignment resets. Escalating a ticket between technicians must not reset first response. It was responded to once; the client does not care about your internal routing.
4. Breach visibility before the breach. A report that shows last month's misses is an autopsy. What changes behaviour is a queue that shows tickets at 75% of their target while there is still time to act.

Report on it before your client asks

An SLA you do not measure is a marketing line, and one you only measure when challenged is a liability. Put SLA attainment on the monthly report and the quarterly review: percentage of tickets that met first response and resolution by priority, the misses, and what changed as a result. Bringing your own misses to the table, with causes, is disarming and builds far more trust than a suspiciously perfect scorecard.

Expectations around response times should also be set on day one of a new contract, alongside how tickets are raised and what counts as urgent. It is one of the steps in our client onboarding checklist, because an SLA explained in week one prevents the escalation call in month six.

Where this fits with Helios

The Helios service desk was built around the mechanics above: per-client SLA policies with business-hours calendars, pause states for waiting-on-client time, and countdown timers on the queue so technicians see what is approaching breach rather than what already breached. Helio, the AI layer, auto-triages inbound tickets against your impact matrix, which keeps priorities consistent when they arrive at 2am or in capital letters. Attainment then flows into the client portal and monthly reports without anyone assembling a spreadsheet.