How to read an MSP's SLA numbers — three metrics, a hidden stop-clock, and the language that hides both

Every managed-IT service-level agreement an Ohio SMB signs names three numbers in the headline, and a fourth number — a stop-clock — hides in the fine print. The three numbers are first response time, resolution / close time, and ticket volume over the reporting year. Each one answers a different question, and each one can be made to look good without the operations behind it actually being good. The fourth number is the stop-clock: the conditions that pause the clock between ticket open and ticket close. The vendor who is fastest at stopping the clock is rarely the vendor who is fastest at responding.

First response time is the wall-clock between a ticket open and the first engineer reply. It is one of two numbers an SLA almost always commits in writing, because it is the easier of the two to meet. It does NOT measure time-to-resolution, severity of the answer, or whether the same engineer follows up. Vendors fudge first response in three ways: (1) auto-acknowledgement — a chat bot or after-hours answering service replies inside the SLA window with "we have received your ticket", resetting the clock before the engineer ever reads it; (2) escalation-first — every after-hours ticket is re-routed to the morning queue, so the first response time starts at 9 AM; (3) tiered acknowledgement — the SLA commits only to the lowest tier, while everything else falls outside the contract. The honest read is first response after acknowledgement minus auto-reply and after-hours re-routing.

Resolution time (sometimes called close time) is the wall-clock between ticket open and engineer-resolved. Three things make resolution time harder to meet than first response: (1) the work — actual fixes take longer than the acknowledgement; (2) the dependency chain — many tickets wait on the user, the vendor, or a third party, and the clock can be paused at every step; (3) the definition — "resolution" is whatever the vendor closes the ticket as, including "user resolved on their own" and "no error reproduced". The hidden lever is the stop-clock. A "business hours only" clause pauses the SLA clock overnight; an "after-hours excluded" clause pauses it on weekends; an "awaiting client response" clause pauses it whenever an email reply is pending. The vendor who reads the close metric against a paused clock is not the same vendor who reads it against a running clock. Central IT Dept publishes the close metric the same way every year — wall-clock from open to resolved, paused only when a third party is involved, never paused for business hours.

Ticket volume is the count of tickets opened in the reporting period. It is the number most partners skip because it is the number they cannot blame elsewhere. A high ticket count does not mean bad service — many tickets means many interactions, which means many fixes applied; a low ticket count can mean fewer problems or fewer reports. Three things ticket volume reveals: (1) staff capacity — if the count is steady but the average first response is sliding, capacity is dropping; (2) scope drift — if the count is steady but the close time is sliding, either tickets are harder or they are being closed earlier on a definition change; (3) dispatch quality — if both count and response time are sliding, dispatch is losing the queue. The vendor who publishes ticket volume alongside response and close metrics is publishing the only dataset where all three lines can be read together.

Seven phrases to circle before signing

1. "business hours only" — the clock pauses overnight and weekends; first response "in writing" often means "by next business day".
2. "after-hours excluded" — the metric is measured against a smaller denominator than the 24/7 ticket count; press for what counts as after-hours.
3. "by next business day" — equivalent to 14–18 hours in practice for a Cleveland / Cincinnati / Dayton / Akron / Toledo SMB; commits nothing at the same scale as the tickets being filed.
4. "best effort" — no numerical commitment; a written best-effort is not an SLA, it is a marketing line.
5. "subject to availability" — pauses the clock when staffing is short; reads as a pass-through for staffing decisions.
6. stop-clock carve-outs — "paused while awaiting client" / "paused during maintenance windows" / "paused for change control" / "paused during national holidays" pause the SLA clock against a list the vendor alone maintains.
7. no published actuals — every line above is meaningless without the vendor's own pre-publication numbers for the last reporting year; a vendor who will not commit to the next quarter's reported metric has not yet committed to any line item.

Every metric above reads against a number. The numbers come from the track-record dataset — tickets opened, average first response, average close — for the three reporting years Central IT Dept has published: 2023, 2024, and 2025. The dataset is not surveyed; it is republished verbatim from the operator's own ticket-system export. The point is not the specific year-by-year change; it is that the same three columns are present, the same clock definitions apply, and the same conditions that pause the clock are documented.

Questions to ask any MSP about their SLA

Seven questions to bring on every walkthrough. The vendor whose answers line up with their published numbers is the vendor worth signing.

• What is published first response and resolution, and is it committed in writing — not just on a slide?
• Are after-hours tickets on the same clock as business-hours tickets, or is the metric measured against a smaller denominator?
• What is excluded from first response (auto-acknowledgements, after-hours re-routes, escalation queues) and what is excluded from resolution (awaiting client, awaiting vendor third party, change-control windows)?
• Are these published actuals, or a verbal promise? Will the vendor commit to publishing next quarter's metric on the same page?
• How is "close" defined — engineer-resolved, user-resolved, no-error-reproduced, or whichever the ticket is filed as?
• What counts as a ticket — phone call, email, walk-up, chat, alert from monitoring — and what is intentionally excluded from the count?
• Is ticket volume published alongside response and close, so all three columns can be read together against the same clock?

The three numbers, the stop-clock, and the seven red-flag phrases narrow the walkthrough to one question: do the vendor answers line up with the vendor numbers? Bring the list to every quote. The vendor whose answers match their published numbers is the vendor worth signing.