MSP SLA Checklist

The target matrix below uses invented timings to show the structure. Set targets for your business and proposed service.

The five SLA timers

Define acknowledgement, work start, mitigation, restore and resolution separately. An advertised response target only becomes comparable when its start event, stop event and service window are clear.

Definitions needed for an auditable SLA

For each row below, the test is the same: could a third party with access to the ticket system decide, from the written definition alone, whether the target was met?

Severity definitions

Each severity level needs an operational definition based on observable impact - for example (illustrative only): P1 as "a production service used by multiple users is unavailable and no workaround exists". Watch for definitions that depend on the provider's own judgment ("as determined by the service desk") without buyer input or an appeal route.

Service window

Which hours, which timezone, which holiday calendar. A document may use a 24x7 window for P1 and a business-hours window for P3; a document that never states the timezone is not comparable across candidates. For off-hours promises, check who actually staffs the window - the after-hours planning guide covers coverage models in depth.

Illustrative case: the agreed calendar is Monday-Friday, 09:00-17:00 in one timezone, with no holidays, clock changes or permitted pauses during this example. A timer starts Friday at 16:50 and stops Monday at 09:20. It counts 10 minutes on Friday plus 20 on Monday: 30 business minutes, while 64 hours 30 minutes have elapsed. A continuous 24x7 timer counts the full 64 hours 30 minutes. Judge each result against that timer's written target and calendar; retain both counted time and the actual delay.

The configuration matters as much as the label. For example, Atlassian's Jira Service Management Cloud calendar instructions ↗ (external website), checked 19 October 2026, specify timezone, working days, time slots and holidays. Ask to see the calendar assigned to the proposed SLA, including any lunch break or excluded day.

Measurement start and stop

What event starts each clock: ticket creation, first classification, or alert arrival in the provider's queue? What pauses it: waiting on the client, waiting on a third-party vendor, scheduled maintenance? A clock that starts at "triage completion" is controlled by the party doing the triage - that belongs in your red-flag list.

Exclusions

Typical exclusions: client-caused delays, third-party outages, out-of-scope systems, force majeure, maintenance windows. Document exclusions and require observable criteria for their use. Each exclusion should be observable and logged, not asserted after the fact.

Escalation

Who can escalate, on what trigger, to whom, and is the path usable outside normal hours. Confirm a separate off-hours route wherever off-hours escalation is promised.

Reporting

The reporting period, and crucially what the report exposes: a compliance percentage alone can hide a catastrophic miss on your most important client. Ask for both the percentage and the missed-ticket detail.

This invented single-timer dataset uses one completed cycle per request and the same reporting period:

The overall 99.9% includes a miss on one of ten critical requests. Request counts and missed cases by severity and timer, then define which open, paused or reopened cycles enter the total. Specify whether the period follows creation, completion or breach dates. Do not average the two group percentages: the combined rate uses 999 divided by 1,000.

Report names can conceal different populations. Atlassian's Data Center reporting explanation ↗ (external website), checked 19 October 2026, says its SLA success-rate report excludes ongoing cycles. Confirm the actual report definition for your product and configuration before comparing supplier percentages.

Remedies

Service credits, their size, how they are claimed (automatic or on request), caps, and whether chronic failure creates a termination right. A remedy you must discover and claim yourself, within 30 days, capped at a small percentage, is a different promise than an automatic credit with a termination trigger - even when the targets read identically.

Illustrative target matrix

The example separates all five clocks. Timings are invented to illustrate the layout, not recommendations or provider terms. Unspecified targets require agreement rather than an assumed value.

A real matrix additionally needs: clock start and pause events per row, the service window per row, the exclusion list, the measurement source (whose ticket system is authoritative) and the reporting period.

SLA worksheet

Use one copy per candidate document. It mirrors the structure above:

1. Service definition - covered service, coverage window and timezone, severity definitions, measurement start and stop events, exclusions. Each row takes the candidate's answer, the source, the checked date and a status.
2. Target matrix - separate acknowledgement, work start, mitigation, restore and resolution targets, plus update cadence and remedy per severity.
3. Quality checks - is each timer tied to an observable event; are business hours, holidays and paused states defined; are dependencies and client-caused delays handled explicitly; does the report expose both compliance percentage and missed-ticket detail; is the escalation path usable outside normal hours; are remedies meaningful enough to support correction?

Keep an ambiguous severity, timer or exclusion open until the proposed definition is agreed. Compare only the rows with matching scope and measurement rules. If a clause affects a mandatory requirement, agree its definition before accepting the service; retain the question and its owner alongside the candidate's response.

Red flags

• Response time quoted prominently with no restore or resolution language anywhere in the document.
• Clocks that start at events the provider controls (triage completion, severity assignment) without an appeal route.
• "Commercially reasonable efforts" as the only measure for higher severities.
• Severity definitions the provider can reassign unilaterally after ticket creation.
• Exclusions without logging requirements - excluded time that is not recorded cannot be audited.
• Credit caps and short claim windows can limit remedies; document the amounts, deadlines and claim process explicitly.
• A compliance report with no per-ticket detail.
• SLA published on the website but absent from the actual agreement - a marketing page is not a contractual commitment, check the executed agreement rather than assuming the web page is incorporated.

From evaluation to requirement

The strongest use of this worksheet is before signature: convert each ambiguous row into a written question, and put your required definitions into the RFP so every candidate answers the same matrix.

• Add SLA terms to the RFP - turn your evaluation rows into section 5 requirements.
• Plan after-hours coverage - test whether coverage promises match staffing and escalation reality.

After signing: check the SLA in practice

An audit log should document incident ID, tenant, severity rationale, signal and acceptance times, first action, mitigation, restore, resolution, pauses, approvals, receiving owner and source ticket. For a business-hours P2 case, document the exact service window that determines elapsed versus counted time. For a continuous P1 case, document every pause and accepting escalation. Do not silently apply one window to both severities. Suggested pilot clocks must be selected for your business; invented example targets are not recommended market standards.