← All Blogs

First Response or Resolution: Which SLA You Should Actually Care About

By Best IT MSP Editorial Team - Updated October 20, 2026 - 11 min read

The Best IT MSP editorial team maintains this directory's provider data across the US and Canada. We rank providers on verified rating and firmographic data, label paid placement, and do not sell IT services.

First response or resolution: which SLA should you actually care about?

Care about neither as written. A first response time commits your provider to a reply, and a resolution time is almost never in the agreement at all. The clause worth negotiating is a time to engage a qualified engineer, with severity levels defined by business impact.

Almost every managed IT proposal has the same shape. A 15-minute or one-hour first response time sits near the top in bold, and nothing states when a fault gets fixed. That is not a small-provider problem. Microsoft commits to a Severity A initial response of under one hour on its Standard, ProDirect and Unified Enterprise plans. Amazon Web Services commits to a response inside 15 minutes when a business or mission-critical system is down on Enterprise Support. Neither commits to a resolution time anywhere. Google Cloud says only that turnaround times vary, depending on the issue complexity and product component in question.

The first response clause measures the cheapest link in the chain, which is a reply. Nothing in the standard wording requires that reply to come from a person, and nothing requires the person to fix anything. AWS promises only to make every reasonable effort to respond to your initial request within the corresponding timeframes. Respond to the request. Not resolve the fault.

This guide covers two clauses and one definition. Read it beside 24/7 Monitoring Means Four Different Things for coverage hours, MSP Contract Red Flags for the other clauses worth a second read, and Supervising the IT Provider You Already Have for the review rhythm around them.

What does a first response time SLA actually commit your provider to?

A first response time commits your provider to one reply inside a stated window, and to nothing beyond it. It does not promise a human, a diagnosis, a qualified engineer, or any movement on the fault itself.

Every service desk tool sends an acknowledgement the second a ticket is created. Where your agreement says response and does not say who responds, that automated email is a defensible answer to the clause. A 15-minute first response time then costs the provider a workflow rule and commits it to almost nothing. Three questions close the gap.

• Ask whether an automated ticket acknowledgement satisfies the clause, and get the no in writing.
• Ask what the first reply must contain. A named owner and a next action beats a receipt.
• Ask who sends it, and who triages it afterwards. A dispatcher, a qualified engineer and a workflow rule are three different purchases.

Watch how little the number moves between service tiers, because that is what you are really buying. Microsoft's Severity C initial response goes from under eight hours on Standard to under four hours on ProDirect, and the fault is identical in both. You are buying queue position. An engineer who triages your ticket properly at minute 12 beats a reply at minute 3.

Coverage hours sit underneath all of it. A one-hour first response time inside business hours only is a different product from the same number under 24/7 coverage, and both get quoted at the same headline figure.

Why almost no MSP guarantees a resolution time

Almost no provider guarantees a resolution time because a large share of faults are not the provider's to fix. The absence is usually defensible rather than evasive, and understanding why changes what you should ask for instead.

The dependency chain is measurable. Uptime Institute, which has tracked publicly reported outages for nine years, attributes about two-thirds of them to third-party IT and data centre service providers, including cloud and internet giants, telecommunications and colocation companies. In 2024, IT and networking issues accounted for 23 percent of impactful outages. When your circuit or your SaaS platform is down, your provider is a customer in someone else's queue, exactly as you are in theirs.

Your own environment supplies the other half. Uptime found nearly 40 percent of organisations have suffered a major outage caused by human error in the past three years, and that 85 percent of those stem from staff failing to follow procedures or from flawed processes. No provider can promise to resolve a fault caused by a decision inside your business, a password nobody can produce, or a failed laptop that has to be shipped.

Government guidance says it in plainer language. CISA grades recoverability from an incident in four steps, and one reads time to recovery is unpredictable, with additional resources and outside help needed. A fourth reads recovery from the incident is not possible. The body that writes the federal reporting standard will not pretend recovery time is always knowable, so a 40-person managed IT provider cannot either.

Demanding a blanket resolution SLA therefore produces one of two bad outcomes. An honest provider refuses. A provider that needs the deal gives you a number padded until it cannot be broken, which is worse, because an unbreakable target rewards closing the ticket rather than fixing the problem. A resolution target is fair in one narrow case, where the fault sits wholly inside the provider's own scope. Three examples qualify, which are patching a server it manages, restoring from a backup it owns, and rebuilding a user account it created. Name those and leave the rest alone.

Ask for a time to engage a qualified engineer instead

To replace the clause you cannot get, ask for a time to engage. That is the maximum minutes from ticket creation to the moment a named person with the skill to fix the fault is actively working on it, and it is the one commitment that changes outcomes.

This is not an invention you have to argue from first principles, because a provider already sells it in exactly that form. AWS Enterprise Support states that Support Engineers engage within 15 minutes for high-severity issues. Ask for the same shape in your own numbers, and four lines carry it.

• Define time to engage in minutes, split by severity, and name the skill level that counts.
• Separate it from first response time in the agreement, so satisfying one cannot satisfy the other.
• Set an update cadence for anything still open, such as every 30 minutes at the top severity.
• Fix the escalation matrix beside it, naming who is engaged next, after how long, and how you escalate past them.

Then handle resolution the other way round. Ask your provider to measure and report mean time to resolve by severity every month, and do not ask it to guarantee the figure. A measured number you see monthly beats a guaranteed number nobody can honour, because the trend tells you whether the service desk is degrading while the first response target stays green.

The scale of the clock is why it has to be measured rather than promised. Verizon's 2026 report puts the median time for full resolution at 43 days, almost two weeks more than the previous year's 32 days. That figure measures vulnerability remediation rather than help desk tickets, and it moved 11 days in one year. IBM measured an average of 247 days to identify and contain an active breach. Resolution time is a distribution, not a promise.

What a business-impact severity matrix looks like

A business-impact severity matrix grades a fault by what stops working and for how many people, not by which piece of technology failed. That single change is what makes every other number in the agreement measurable.

Most agreements carry a technical-category matrix instead, and four rows do the damage.

• Server down becomes P1, whether or not a single person noticed.
• Network issue becomes P2, whether one desk or the whole office is offline.
• Application issue becomes P3, including the application that runs payroll.
• Printer or peripheral becomes P4, including the printer that produces your shipping labels.

Two cases break that matrix immediately. One machine failing on payroll day is a P4 peripheral problem by category and a business emergency in fact. A redundant server failing at 2am with failover working is a P1 by category and nobody notices until the monthly report. The matrix grades the wrong noun.

The business-impact version is already written down by providers who sell to demanding buyers, so you can lift the wording. Microsoft defines Severity A as critical business impact, where the customer's business has significant loss or degradation of services and requires immediate attention, Severity B as moderate business impact, where work can reasonably continue in an impaired manner, and Severity C as minimum business impact, where the business is functioning with minor impediments of services. Google Cloud grades P1 as critical impact with the service unusable in production and business impact critical, for example revenue loss or a potential data integrity issue. Neither definition names a server.

CISA goes further and grades functional impact across eight levels, from no impact to services up to denial of critical services, where a critical system has been rendered unavailable. Its middle rungs are written the same way, including minimal impact but to a critical system or service, such as email or active directory. Every level describes services and customers. None describes hardware.

Write yours the same way and name your own systems, so the order fulfilment database and the payroll run appear by name rather than as an application issue. Three questions expose which matrix you hold.

• Count the rows in your severity table that name a technology, and the rows that name an outcome.
• Ask which severity applies when payroll cannot run and every server is up.
• Ask which severity applies when a server is down and nobody is affected.

Who decides the severity, and why that is the whole SLA

Whoever grades the ticket controls every target in the agreement, so name the decider in writing. A provider holding a unilateral right to grade your outage as low severity has rewritten its own service level agreement without changing a word of it.

The two published defaults sit at opposite ends, which is the useful part. Microsoft reserves the call for itself, stating that Microsoft may at its discretion decrease the Severity to level B and that it may downgrade the severity level if the customer is not able to provide adequate resources or responses. That condition is defensible, because a Severity A case assumes you work the problem too. It is also written down, so a buyer can read it and plan around it.

Google Cloud hands the decision to the customer. Its guidance says you can change the priority of your case based on the urgency and the business impact, and that Customer Care is notified and attends to your case based on the new priority. Same industry, opposite default, both stated in public.

Most managed IT agreements say nothing at all, which in practice means the service desk decides silently and you learn the grade from the response you get. Three lines settle it.

• Name who sets the initial severity, you or the service desk.
• Confirm whether you can raise it, and whether the clock restarts or continues when you do.
• State the grounds for a downgrade, and require written notice to a named person when one happens.

A provider that can downgrade your severity without telling you never has to break its SLA. It can simply regrade the ticket until the target fits.

What to get in writing, and what an SLA credit is worth

Put six lines into the agreement rather than the proposal, because a proposal describes intent and an agreement creates an obligation.

• Define first response time, and state that an automated acknowledgement does not satisfy it.
• Set time to engage a qualified engineer in minutes, by severity, with the skill level named.
• Define severity levels by business impact, with one named system as the example at each level.
• Name who grades severity, the grounds for a downgrade, and the notice you receive.
• Fix the escalation matrix, including what changes outside business hours.
• Require mean time to resolve reported monthly by severity, as a measurement and not a guarantee.

Two external yardsticks give you leverage when a provider calls this unusual. CISA requires federal agencies to report an incident within one hour of it being identified, so an hour-scale clock is a normal thing to commit to in writing. CISA, the NSA, the FBI and international partners advise managed service provider customers to establish in the contract how and when MSPs notify the customer of an incident affecting the customer's environment, and whether the MSP or the customer owns specific responsibilities, such as hardening, detection, and incident response.

Spend almost no energy on the SLA credit. A credit is typically a small percentage of one month's fee, claimed by you rather than paid automatically, against an average breach cost IBM puts at 4.99 million dollars. Treat credits as a reporting trigger, not as compensation. Do not let an uptime guarantee stand in for any of this either, because availability of a system and speed of a fix are different measurements.

Then read the numbers where decisions get made. Take the monthly first response, time to engage and mean time to resolve figures into your QBR, read them beside CSAT and ticket volume by severity, and ask what changed. Best IT MSP is independent and does not sell IT services, so we rank on verified rating and firmographic data and publish our evaluation method in full. Compare three merit-ranked managed IT providers on these three clauses. None of this buys a perfect service desk, and no honest provider claims it does. It buys a specific, contractual answer to the one question most agreements leave open.

FAQ

What is the difference between first response time and resolution time?

First response time measures how long until your provider replies to a ticket. Resolution time measures how long until the fault is fixed. Almost every managed IT agreement guarantees the first and omits the second. Microsoft publishes a Severity A initial response under one hour and publishes no resolution target at all.

Should an MSP guarantee a resolution time?

No, not as a blanket commitment. Resolution often depends on parties your provider does not control. Uptime Institute attributes about two-thirds of reported outages to third-party IT and data centre providers. Ask for resolution targets only on faults inside the provider's own scope, such as patching a server it manages.

Can an automated ticket acknowledgement count as a first response?

Yes, unless your agreement says otherwise. The clause measures a reply, and the wording rarely requires a human. AWS states only that it will make every reasonable effort to respond to your initial request within the corresponding timeframes. Write in that an automated acknowledgement does not satisfy the clause.

Who decides the severity of an IT ticket?

Whoever your agreement names, and most agreements name nobody. The published defaults differ. Microsoft states that Microsoft may at its discretion decrease the Severity to level B, while Google Cloud says you can change the priority of your case based on the urgency and the business impact. Name your decider.

What is a good SLA response time for a small business?

Ask for time to engage rather than a response figure. AWS Enterprise Support commits that Support Engineers engage within 15 minutes for high-severity issues, which is a defensible benchmark to copy. Pair it with severity defined by business impact, and with mean time to resolve reported monthly.

← All Blogs