Every managed IT provider’s sales deck has a slide with a big number on it. Four hours. Two hours. Sometimes, ambitiously, thirty minutes. The number sits there looking like a promise. It is, in the overwhelming majority of contracts, not a promise at all. It is a measurement of something almost entirely disconnected from the thing you actually care about, which is how long your business stays broken.

Here is the sentence that should be printed on every MSP sales deck in fourteen point font: response time measures how quickly someone acknowledges your problem. It does not measure how quickly your problem gets fixed. Those are two completely different numbers, and the gap between them is where businesses discover, usually during an actual outage, that the SLA they signed protects the provider’s metrics far more than it protects their operations.

Here is what an IT SLA response time commitment actually measures, why the number on the sales deck is close to meaningless on its own, and the five questions that reveal whether your provider’s SLA is a real operational commitment or a marketing document with numbers in it.

What “response time” actually measures

Response time measures the interval between a ticket entering the system and someone acknowledging it, meaning a human has reviewed the issue and assigned it to be worked. That is the entire definition. It says nothing about how long it takes to actually fix the problem, and it says nothing about what counts as an acknowledgment in the first place.

Resolution time measures a completely different interval: from the ticket entering the system to the issue actually being fixed and service restored. This is the number that determines how long your business is actually impaired. A provider can hit a perfect four-hour response record on every single ticket while your email server sits down for two full business days, because nothing in a response only SLA obligates them to finish the work in any particular timeframe.

If your current agreement only mentions response time, with no explicit resolution commitment attached, you have a document that guarantees someone will look at your problem within a stated window. It guarantees nothing about when that problem actually goes away.

The three ways “response” gets quietly redefined

Even the response time number, limited as it is, gets manipulated in ways that make a four-hour commitment functionally meaningless. Three specific patterns show up repeatedly in real MSP contracts.

The automated acknowledgment counts as the response. A ticket submission triggers an automatic email confirming receipt. That auto-reply satisfies the letter of a “response within four hours” clause even though no human being has looked at the actual problem. The clock legally stops. Your problem remains completely untouched.

“We’re looking into it” counts as the response. A generic status update, sent to satisfy the SLA timer without any actual triage having occurred, is functionally the same as the automated email above with a human’s name attached. Nobody has assessed severity, scoped the issue, or begun meaningful work.

The clock starts late. If tickets are only logged when someone manually reports an issue, rather than through monitoring software that auto-generates a ticket the moment a problem is detected, the SLA clock can start hours after the actual failure began. A well configured monitoring and ticketing integration starts the clock automatically the instant an issue is detected, which is the only version of “four hour response” that means what it sounds like it means.

The real tiered structure most SLAs should have and most do not

A credible SLA does not use a single number for every possible issue. It defines multiple severity tiers, each with its own response and resolution commitment, because a complete network outage and a single user’s printer issue are not remotely the same problem and should never share the same clock.

Notice where the widely advertised “four hour response” number actually belongs in a real tiered structure. It is the P3 benchmark, for a single user issue with a workaround already available, not the number that should apply when your entire network is down. A provider quoting a flat four-hour response across every severity level is either quietly failing to protect you during a real emergency, or has never actually built a tiered structure at all and is using a single marketing number to cover every scenario.

The math your provider does not want you to run

A fifteen minute P1 response commitment is only physically achievable if the provider has the staffing capacity to deliver it. An MSP running 500 or more endpoints per technician is structurally unable to guarantee a fifteen minute critical response across their full client base during a widespread incident, regardless of what the contract says. The commitment is not a lie exactly. It is a number that only holds true when nothing else is going wrong for any other client at the same time, which is precisely the condition that does not hold during a major outage or a broad based attack affecting multiple clients simultaneously.

Ask directly: how many endpoints does each technician support, and what happens to your response time when three other clients have a critical incident at the same moment yours does. A provider who answers this specifically, with a real staffing ratio and a real escalation plan for concurrent incidents, is describing an operational reality. A provider who deflects or refuses to disclose the ratio is telling you, indirectly, that the number does not hold up under real conditions.

The remedy question that separates a real SLA from a promise

An SLA without a defined remedy for missing it is not actually a service level agreement. It is a statement of intent with no consequence attached. If your current agreement says the provider will “make every effort” to hit response and resolution targets, with no specific credit or refund formula tied to a missed commitment, nothing in the document actually changes the provider’s behavior when they fall short.

A credible remedy looks like a specific formula: a defined service credit percentage applied to that billing cycle for each missed SLA tier, escalating for repeated misses, with the credit calculation stated in the contract rather than left to a case by case conversation after the fact. If you have to chase the credit, or the credit is capped at an amount too small to matter, the remedy exists on paper without existing in practice.

Five questions to ask instead of accepting the number on the slide

1. “Define response, in one sentence, in writing.” The correct answer describes a technician engaging with an actual plan of action. Anything involving an automated message or a generic status update is not a real answer.
2. “What is the resolution commitment for each severity tier, not just the response commitment?” If the provider can only produce a response number and no corresponding resolution number, you do not have a complete SLA.
3. “How many endpoints does each technician currently support?” This single number tells you whether the fifteen minute P1 promise is a real operational capacity or an aspirational marketing figure.
4. “What is the specific credit or refund formula when an SLA tier is missed, and how is it triggered?” Get the formula in writing, not a verbal assurance that they take it seriously.
5. “How does a ticket get created, monitoring software automatically or manual reporting only?” Automatic ticket creation through remote monitoring and management tooling is the only reliable way to ensure the SLA clock starts when the actual problem starts, not whenever someone happens to notice and report it.

These five questions take fifteen minutes to ask and answer honestly. They take considerably longer to discover the hard way, during an actual outage, when the four hour number on the sales deck turns out to describe an automated email rather than a technician actually fixing your problem. The same evaluation discipline applies broadly to choosing a managed IT provider in the first place, and response SLA specificity is one of the fastest, cheapest diagnostics available before signing anything.

The honest version

The four hour response SLA on your provider’s sales deck is not necessarily dishonest. It is, more often, incomplete. It describes one measurement, acknowledgment speed, without the resolution commitment, the tiered structure, the staffing capacity, or the remedy that would actually make it operationally meaningful. A business that signs based on that single number alone has agreed to something that sounds like protection and functions, in practice, as a marketing figure with no enforceable teeth behind it.

Real managed IT services in Orange County come with an SLA that answers all five questions above in writing before a contract is ever signed, not after the first outage reveals the gap. The four hour number is not the thing to evaluate. What that number is actually built on top of is.

Related reading:
Managed IT Services in Orange County ·
How to Evaluate an MSP: The 10 Questions That Reveal Everything ·
The Hidden Cost of Your IT Vendor’s Helpdesk ·
What White-Glove IT Actually Means ·
Book a Discovery Call