Managed IT SLAs: What a Service-Level Agreement Should Actually Commit To
What an IT service-level agreement should actually commit to: response vs resolution time, coverage hours, priority levels, uptime and exit terms.
A service-level agreement is the part of a managed IT contract that says what the provider owes you and what happens if they do not deliver it. A usable one commits to six things in writing: how fast someone responds, how fast the issue gets resolved or escalated, which hours those promises apply during, how an issue’s priority is decided, what uptime is guaranteed and for which systems, and what you get if a commitment is missed. Anything described only as “fast,” “rapid,” “industry-leading” or “proactive” is not a service level. It is an adjective.
Most SLA disputes are not about speed. They are about two things that were never written down: which hours the promise covered, and who got to decide how urgent the problem was. If you are earlier in the process, our checklist for what a managed service provider does is the better starting point.
Response time and resolution time are not the same promise
This is the distinction that causes the most disappointment after signing, and the one most proposals blur.
Response time is how long before a human being who can act acknowledges your ticket. A fast response time is real value — it tells you the queue is staffed and your issue has an owner — but a response is not a fix. A provider can hit a fifteen-minute response target all year and still leave a problem running for three days.
Resolution time is how long before the issue is actually fixed. Honest providers are cautious here, because resolution depends on things outside their control: a failed drive needs a part, a carrier outage needs the carrier, a vendor bug needs the vendor.
What a good agreement does is commit to both, differently. A firm, numeric response target per priority level; and for resolution, either a target with named exclusions, or — more honestly — a commitment to continuous work and scheduled updates until the issue is closed, with a defined escalation point.
The question to ask, in these words: “What is your response target, what is your resolution target, and which of those two is contractual?” If the answer to the second half is “the response one,” that is a legitimate answer. If the person cannot distinguish the two, you have learned something more important than the numbers.
The six things a service level is made of
| Component | What it should say | What “not written down” looks like |
|---|---|---|
| Response target | A number, per priority level, measured from when the ticket is raised | “We respond fast” |
| Resolution or escalation target | A number with named exclusions, or a defined escalation and update cadence | Silence, or a resolution number with no exclusions at all — usually a sign nobody expects to measure it |
| Coverage window | The hours and days each target applies, and what happens outside them | “Always available” with no definition |
| Priority definitions | Written criteria, with examples, and who decides | “Critical issues are prioritised” |
| Uptime commitment | A percentage, the systems it covers, the measurement method, and what is excluded | A percentage alone |
| Remedy | What you get when a target is missed, and how you claim it | Nothing — which means the SLA is a statement of intent |
What “around-the-clock support” can mean, and the three questions that tell you which one you are buying
“Around-the-clock” is used for at least four different models, and the difference between them is the difference between someone answering at 2am and someone reading your email at 8:30am.
- Continuous automated monitoring, humans during staffed hours. Tooling watches without interruption and raises alerts; a person looks at them when the office opens. This is the most common arrangement at the small-business end, and it is perfectly reasonable — as long as it is what you think you bought.
- On-call rotation. A human is reachable outside staffed hours, usually via a defined trigger — a phone line, a severity level, a specific contact.
- A help desk staffed around the clock. Somebody is actually at a desk at 3am.
- Emergencies only outside staffed hours, normal handling for everything else — with “emergency” defined by the provider.
Three questions settle it:
- At 2am on a Sunday, what specifically happens — who or what receives the alert, and who picks up the phone?
- Is work outside staffed hours included in the monthly fee, or billed?
- What triggers a response outside staffed hours: any ticket, a severity level, or a particular phone number?
Ask for the answer in the agreement, not in the sales call. And check the provider’s own published hours against whatever their marketing claims — if the website promises constant availability and the opening hours say Monday to Friday, both may be true for different things, but the agreement should say which is which.
Priority levels: who decides an issue is urgent?
Every response target is attached to a priority level, which means priority definitions are the real mechanism and the response numbers are downstream of them.
A workable scheme is short — typically three or four levels — and defined by business impact rather than by technology:
- Critical: the business cannot operate. Everyone is down, the main line of business application is unavailable, or there is an active security incident.
- High: a group is blocked or a critical function is degraded. One department cannot work; a key system is unreliable.
- Normal: one person is affected, or there is a workaround.
- Low / scheduled: requests, changes, new user setup, planned work.
The questions that matter more than the definitions:
- Who assigns the priority — you or the provider? The best answer is that you set it when you raise the ticket, the provider can propose a change, and disagreements escalate to a named person.
- Can you escalate a priority mid-ticket, and how?
- Does a security incident have its own path? It should. A suspected breach is not a help desk ticket — see incident response.
Uptime, and why an uptime number is often the least useful figure in the document
Uptime percentages read as the most rigorous part of an SLA and are frequently the least meaningful. A percentage on its own does not say which systems it covers, how it is measured, what is excluded, or who is responsible for the parts the provider does not control.
Before accepting an uptime figure, establish:
- Which systems it covers. Managed infrastructure only? The network? Cloud services the provider resells but does not operate? A provider cannot credibly guarantee uptime for a third-party cloud platform beyond what that platform guarantees them.
- How it is measured and reported — monitoring interval, what counts as down, and whether you see the report without asking.
- What is excluded — scheduled maintenance, carrier and ISP outages, power, client-caused changes, force majeure. Exclusions are normal. Unstated exclusions are not.
- Whether degradation counts. Systems that are technically up and unusably slow are the most common real-world outage.
A provider who explains the exclusions unprompted is telling you more about how they operate than the percentage does.
What happens when the commitment is missed
An SLA without a remedy is a goal. Common remedies, roughly in order of how often they are real:
- Service credits — a percentage of the monthly fee, usually capped, usually claimed rather than granted automatically. Ask: who has to notice, and what is the window for claiming?
- A documented review and corrective action — less satisfying, often more useful than a credit.
- A termination right after repeated misses within a defined period. This is the only remedy with real teeth and it is worth more than the credits.
- A trial or satisfaction period at the start of the relationship.
Ask one question: “In the last twelve months, how many times did you miss a response target, and what did you do about it?” The content of the answer matters less than whether they can answer at all. A provider who measures their own performance can tell you; one who does not will change the subject.
Scope: the part people argue about later
Most billing disputes are scope disputes wearing an SLA costume. Get these in writing before signing:
- What is included in the monthly fee versus billed hourly — projects, migrations, moves, new office builds, work outside staffed hours, on-site visits. A provider’s full service list, like ours, tells you what is even on the menu before you argue about what is in the plan.
- Whether on-site visits are included, and whether travel is billed.
- Who is covered — named users, devices, locations, and what happens when the count changes mid-term.
- Third-party vendor management — whether the provider will argue with your line-of-business software vendor and your ISP on your behalf, or hand you the phone number.
- What is explicitly excluded. Every provider has exclusions; the useful ones hand you the list. This is normally where a managed IT plan is defined in practice.
Exit terms: who owns your documentation and administrator credentials
This is the question burned buyers ask first and new buyers never think of — and it is the one both Google and Bing now tell buyers to ask before signing.
Establish in writing, at the start:
- Who holds the administrator credentials for your systems, and do you have a copy? Your tenant, your domain, your firewall, your backups. The answer should be that they are yours and you can get them without a negotiation.
- Does the environment documentation leave with you? Network diagrams, asset inventory, licence records, configuration notes.
- Are your backups accessible and restorable without the provider’s tooling? Backups locked inside a provider’s platform are a hostage situation waiting to happen.
- What is the notice period, and what does the provider commit to do during it?
- Is there an exit-assistance obligation, and is it billable?
A provider who has these answers ready has thought about the end of the relationship, which is a good sign about the middle of it. If you are already at that stage, our page on signs you need to switch IT providers covers the move itself.
Copy this table into your RFP
Send this to every provider on your shortlist and compare the answers side by side. Blank cells are the finding.
| Question | Provider A | Provider B | Provider C |
|---|---|---|---|
| Response target, critical | |||
| Response target, normal | |||
| Resolution target or escalation commitment | |||
| Which of those is contractual? | |||
| Coverage window for each target | |||
| What happens at 2am Sunday, specifically | |||
| Is work outside staffed hours included or billed? | |||
| Number of priority levels, and who assigns them | |||
| Separate path for security incidents? | |||
| Uptime commitment, and which systems | |||
| Uptime exclusions | |||
| Remedy when a target is missed | |||
| Misses in the last 12 months | |||
| Included vs billable work | |||
| On-site visits: included? travel billed? | |||
| Who holds admin credentials | |||
| Does documentation leave with us? | |||
| Notice period and exit assistance |
How TVG Consulting answers these questions
We would rather you asked us the questions above than took our word for it, so here is where we stand.
- Urgent issues get immediate engagement. When something is business-down or a security incident is suspected, it is picked up and worked, ahead of routine requests — it does not wait in a queue for a target to expire.
- Priority is a conversation, not a verdict. You tell us how urgent something is when you raise it. If we think it is more urgent than you did, we will say so and act on ours.
- Security incidents do not sit in the help desk queue. A suspected breach has its own path — see our incident response services.
- The specifics belong in your agreement. Response targets per priority level, coverage hours and priority definitions belong in a document you can hold us to, not in a sales conversation or on a web page. Ask us for them in writing and we will give them to you in writing.
TVG Consulting works from offices in Burbank, CA and Franklin, TN — see IT support in Burbank and managed IT services in Franklin, TN.
Not sure your current provider’s commitments are written down anywhere? Talk to us — bring the agreement you already have.
Frequently asked questions
What is the difference between response time and resolution time in an IT SLA?
Response time is how long before someone who can act acknowledges your ticket. Resolution time is how long before the problem is actually fixed. They are separate commitments and only one of them is usually contractual. A provider can meet a fast response target while an issue stays open for days, so ask for both numbers and ask which one is in the agreement.
What is a reasonable response time for managed IT support?
There is no single correct number, because a response target only means something alongside its priority definition and its coverage window. “Fifteen minutes” during staffed hours for a business-down incident and “fifteen minutes” for any ticket at any hour are completely different commitments. Compare providers on the whole set — target, priority level, coverage hours and remedy — rather than on the headline figure.
Does “around-the-clock IT support” mean a person is always available?
Not necessarily. It is used for at least four arrangements: continuous automated monitoring with humans during staffed hours; an on-call rotation triggered by severity; a help desk genuinely staffed around the clock; and emergency-only cover outside staffed hours. Ask what specifically happens at 2am on a Sunday, who or what receives the alert, and whether work outside staffed hours is included in the monthly fee or billed.
Who decides how urgent an IT issue is?
It should be you when you raise the ticket, with the provider able to propose a different priority and a named person to escalate a disagreement to. If the provider assigns priority unilaterally, then the response targets in the agreement are theirs to control rather than yours to rely on. Ask how priority is set, whether you can escalate mid-ticket, and whether security incidents have a separate path.
What does an uptime guarantee actually cover?
Only what the agreement says it covers. A percentage on its own does not identify which systems are in scope, how uptime is measured, what is excluded, or whether severe slowness counts as downtime. Scheduled maintenance, carrier outages and client-made changes are normally excluded, which is reasonable — but the exclusions should be written down, and the provider should be able to show you the measurement report without being asked twice.
What happens if my IT provider misses their SLA?
That depends entirely on the remedy clause, and plenty of agreements do not have one. Common remedies are capped service credits you have to claim, a documented corrective-action review, and a termination right after repeated misses in a defined period. The termination right is worth more than the credits. Ask how many targets the provider missed in the last twelve months — whether they can answer tells you whether they measure themselves.
Who owns our administrator credentials and IT documentation?
You should, and it should say so in writing before you sign rather than after you give notice. That covers administrator access to your Microsoft 365 or Google tenant, your domain registrar, your firewall and your backups, plus the network diagrams, asset inventory and licence records that describe your environment. Also confirm that your backups can be restored without the provider’s own tooling, and whether exit assistance is included or billable.
Talk it through with TVG Consulting
Book a 15-minute call to walk through your environment.