Guide · contracts
What an IT SLA should guarantee — and what to check before you sign
The service level agreement is the part of an IT support contract that decides what you actually get when something breaks. Here is what a good SLA should spell out, the difference between response and resolution, and the red flags UAE businesses should look for.
Why it matters
The SLA is the contract. The rest is the brochure.
Every IT provider describes its support as fast, proactive and reliable. The service level agreement is where those words become commitments you can measure. It sets out how your requests are prioritised, how quickly an engineer responds at each priority, which hours count, what is covered and how the provider reports on its own performance.
A vague SLA protects the provider. A clear one protects you. When your email is down for the whole office, the only question that matters is what was agreed in writing — so it pays to read this part of the contract more carefully than any other, whether you are signing a managed IT services agreement or renewing an annual maintenance contract.
The essentials
Eight things a good IT SLA should spell out.
Use this as a checklist when you compare proposals. If an item is missing, ask for it in writing before you sign.
Clear priority definitions
Every request should be prioritised by business impact, with plain-language definitions for each level. "Critical" should mean something specific — the business is stopped — not whatever the provider decides on the day.
Response targets per priority
A measurable target for each priority level, stating when the clock starts, whether it counts business hours or clock hours, and which hours count as business hours.
Service hours and cover
When the service desk is staffed, how public holidays are handled, and what cover applies outside those hours — for example, continuous monitoring or on-call arrangements for critical systems.
What is in scope
Which users, devices, sites, servers and cloud services are covered, and which work is billable on top. Most SLA disputes start with an unclear scope, not a slow engineer.
Escalation path
Named roles to escalate to when a request is not progressing, and when escalation happens automatically. You should never have to hunt for someone senior during an outage.
Reporting against the targets
A regular report showing tickets raised, priorities, and performance against the targets. An SLA that is never measured in front of you is a promise, not a standard.
Security and backup obligations
What the provider is responsible for in patching, endpoint protection, backup monitoring and restore testing — and how quickly a failed backup is acted on.
Review and exit terms
How the SLA is reviewed, how changes are agreed, and how documentation, passwords and admin access are handed back if the relationship ends.
Response vs resolution
Know which clock the SLA is running.
Response is how quickly an engineer starts working on your request. Resolution is how long it takes to fix. They are very different promises. Response can be committed to precisely, because it is within the provider's control. Resolution depends on the fault itself: a password reset takes minutes, while a failed server component may depend on a hardware replacement or a third-party vendor.
Be equally precise about time. "Four hours" in clock time and "four business hours" are not the same thing. A good SLA states the business hours it counts, whether UAE public holidays are excluded, and exactly when the clock starts. Those details matter more than the headline number.
Finally, look for what reduces the need to raise a ticket at all. Continuous monitoring and automated patching catch many problems before users notice them — and the best SLA is the one you rarely need to invoke.
An example: Missan 365 response targets
When you raise a request, an engineer will respond within these targets. Your request is prioritised by its business impact.
- P1
Critical · 4 business hours
Your business is stopped: a server, network, internet or email is down for everyone
- P2
High · 8 business hours
A key system is badly affected or many users are impacted, with no workaround
- P3
Medium · 1 business day
One user or one system is affected, or a workaround exists
- P4
Low · 5 business days
General requests, changes, questions and planned work
*Targets are for our first response and are measured in business hours: Monday to Friday 08:30–17:00 and Saturday 08:30–14:00 UAE time (GST, UTC+4), excluding UAE public holidays. They run from when your request is logged with our service desk. The response and resolution times that apply to you are set out in your service agreement.
Red flags
Four signs an SLA will not protect you.
These are the patterns that turn an impressive-looking agreement into an argument after the outage.
"Response" that means an auto-reply
If the target is met by an automated acknowledgement email, it measures nothing. A meaningful first response is an engineer engaging with your request.
Priorities the provider sets alone
If you have no say in how an issue is classified, a critical outage can be quietly logged as a medium request — with a much longer target.
Headline numbers with no definitions
A fast-sounding figure with no mention of business hours, holidays or when the clock starts is impossible to hold anyone to.
No reporting
If performance is never reported, you cannot tell whether the targets are being met — and neither, often, can the provider.
Before you sign
Eight questions to put to any IT provider.
A provider that runs a well-managed service desk will answer each of these quickly and in writing. Hesitation on any of them tells you something useful.
At Missan 365, the answers sit in your service agreement from day one. Requests are logged and tracked on our enterprise service-management platform (PSA), prioritised by business impact, and reported back to you every month, with quarterly reviews as part of the Missan 365 Method. We have run IT for UAE organisations since 2004, with 5,000+ clients served since 2004 — and many clients have been with us for more than a decade.
See what each plan includes- How do you define each priority level, and who decides which one applies?
- Are your targets measured in business hours or clock hours, and what are your business hours?
- Does the clock start when I email, when I call, or when a ticket is logged?
- What counts as a first response — an engineer, or an automated reply?
- Which devices, users, sites and cloud services are in scope, and what is billable on top?
- Who do I escalate to, and at what point does escalation happen automatically?
- How will you report your performance against these targets, and how often?
- What happens to my documentation, passwords and admin access if we part ways?
Common questions
IT SLAs, answered.
What is an IT SLA?
An IT service level agreement (SLA) is the part of a managed IT or support contract that defines the service you will receive in measurable terms: how requests are prioritised, the target times for each priority, the hours that count, what is in scope and how performance is reported. It turns support from a general promise into a standard both sides can check.
What is the difference between response time and resolution time?
Response time is how quickly an engineer starts working on your request. Resolution time is how long it takes to fix it. Response can be committed to precisely; resolution depends on the problem itself — a failed hard drive and a third-party outage take very different routes to a fix. A good SLA is clear about which it is measuring.
What response targets does Missan 365 work to?
When you raise a request, an engineer will respond within a first-response target set by its business impact: 4 business hours for P1 Critical (your business is stopped), 8 business hours for P2 High, 1 business day for P3 Medium and 5 business days for P4 Low. Targets are measured in business hours — Monday to Friday 08:30–17:00 and Saturday 08:30–14:00 UAE time, excluding UAE public holidays — from when your request is logged with our service desk. The response and resolution times that apply to you are set out in your service agreement.
Should an SLA include 24/7 support?
It depends on how your business operates. Many organisations need their service desk during working hours, combined with continuous monitoring of critical systems and on-call arrangements for genuine emergencies. What matters is that the SLA states exactly which hours and which systems are covered, so there are no assumptions on either side.
More in the knowledge centre →
Want an SLA you can actually hold us to?
Tell us about your organisation and we will scope a managed IT service with clear priorities, first-response targets and monthly reporting — set out in your service agreement. We reply within one business day.