IT Support SLA: Response Time vs Resolution Time

Response time is how quickly an engineer starts working on your issue. Resolution time is how long it takes to restore service or confirm a fix. The two measure different things, and a contract that only promises the first tells you when work begins, not when your team can get back to work. When you compare IT support contracts, look for both targets at every priority level, the hours each one runs in, and how misses are reported to you. To see written targets in practice, read how we run IT support in Dubai.

What is the difference between response time and resolution time?

Response time measures when work starts, and resolution time measures when the problem is fixed or service is restored. Microsoft draws the same line in its own support plans. It defines initial response time as the period from when you submit a support request to when a Microsoft Support Engineer contacts you and starts working on it. The fix is not part of that number.

Your IT support contract should define response the same way. An automatic email or a ticket number is not a response. In our contracts, response means an engineer is working on your issue remotely, not an auto-reply.

A third promise often gets mixed up with the other two: uptime. Microsoft publishes Service Level Agreements that describe its commitments for uptime and connectivity for its online services, including Office 365 and Intune. That is a promise about the platform. Your IT provider cannot change how available Microsoft's service is. It can only respond quickly and keep you informed when the platform has a problem.

• Response time: how long until an engineer is working on your issue.
• Resolution time: how long until service is restored or a fix is confirmed.
• Uptime: how available a platform is, as committed by the company that runs it.

How are P1, P2, P3 and P4 priorities decided?

Priority is decided by business impact: how many people are affected and whether work can continue. Every ticket should get a priority when it comes in, so you and your provider both know which clock is running. These are the four levels we use, with typical examples of each.

• P1, critical, business stopped: a server, firewall or core switch down, the email tenant or domain unreachable, ransomware or an active security incident, or a site-wide internet outage.
• P2, high, a user or team blocked: one user cannot send or receive email, a printer is down for a department, VPN is failing for one user, or a backup job failed overnight.
• P3, medium, work continues: a new user setup, a software install or licence change, a how-to question, or a scheduled maintenance request.
• P4, low or a planned request: minor display or cosmetic issues, non-urgent single-user requests, documentation updates and planned small changes.

Microsoft's support plans follow the same logic with different labels. Its Severity A means the issue has critical business impact, with severe loss and degradation of services. Its Severity B covers issues where workarounds enable reasonable, albeit temporary, business continuity. Whatever labels a provider uses, the definitions and examples should be written into the contract, so nobody has to argue about priority in the middle of an outage.

What response and resolution times are realistic for a Dubai business?

A realistic shape is minutes to respond and hours to days to resolve, scaled by priority. As a worked example, these are the targets written into our packages.

Our support hours are Monday to Friday 9:00 to 18:00 and Saturday 9:00 to 14:00. On GR IT AMC Start, GR IT AMC Grow and GR Managed IT Core, the P2 and P3 response targets apply in those hours as standard. P2 and P3 run 24/7 on GR IT AMC Scale and GR Managed IT Professional. On GR Managed IT Enterprise, the P2 and P3 targets are set in your contract, in writing.

Every package is delivered 100% remotely. When a fault needs hands on site, the visit is booked and charged separately, so check how any provider treats the resolution clock while a site visit is being arranged. Full package details are on our IT AMC and managed IT services pages.

When you compare quotes, ask whether each target is counted in business hours or calendar hours, and what happens to the clock while a ticket waits on you or on a vendor. Two contracts with the same headline numbers can mean very different things.

Is a faster response time always better?

Not on its own. A fast response matters most for P1, where the whole business is waiting. For a P3 or P4 request, a clear resolution target and an honest report matter more than shaving minutes off the first reply. A quick first reply followed by days of silence helps nobody.

Why do some faults take longer than the resolution target?

Some faults depend on parts, providers or vendors that the support team does not control. These are the most common reasons.

• Hardware parts: a failed disk, power supply or laptop board has to wait for a replacement from the manufacturer or your supplier.
• Internet provider faults: a line fault is repaired by your internet provider. Your IT team can diagnose it and report it, but the repair time is the provider's.
• Cloud platform incidents: when Microsoft 365 itself has a problem, the fix sits with Microsoft. Microsoft suggests checking service health to see whether a problem is a known issue with a resolution in progress before you call support.
• Third-party software: line-of-business applications often need the software vendor's own support team.
• Waiting on your side: an approval, an access request or a user who cannot be reached stops the work. Microsoft applies the same principle to its own support, and may downgrade the severity of a request if the customer cannot provide adequate resources or responses.
• Hands on site: a physical fault may need an engineer at your office. Our packages are delivered remotely, and onsite visits are booked and charged separately.

A good contract says what happens to the resolution clock in each of these cases. A good report shows the reason whenever a target is missed.

What should happen when an SLA target is missed?

A missed target should be reported to you, explained and escalated, not quietly absorbed. Look for three things in the contract.

• Every miss in writing: in our monthly report, each miss is listed with the ticket, the time it took and the reason.
• Escalation by priority: a ticket that is not closed inside its window should move up automatically. On our IT AMC packages, for a P1 the service manager is notified within 30 minutes, a director is briefed within 1 hour, and the managing director is briefed within 2 hours if it is still open. For a P2 the service manager is notified within 1 hour and a director is briefed within 4 hours, and the managing director reviews it if the resolution target is missed. For a P3 the service manager is notified within 4 hours and a director reviews it in the monthly report.
• Repeat incidents: a fault that keeps coming back needs a root cause, not another quick fix. On the same IT AMC matrix, a repeat incident is flagged on the third occurrence and a root-cause analysis is assigned.

Ask every provider to show you a sample monthly report before you sign. A report that only shows averages can hide the one P1 that took far too long.

What should an IT support SLA include before you sign?

It should include clear priorities, two targets for each priority, the hours they run in and a written way to see how the provider performed. Use this checklist when you compare contracts.

1. Written definitions for P1 to P4, with examples of each.
2. A response target for every priority, with response defined as an engineer working on the issue, not an automatic reply.
3. A resolution target for every priority, stated separately from response.
4. The hours each target runs in, and which priorities are covered outside those hours.
5. How time is counted: business hours or calendar hours, and when the clock pauses while a ticket waits on you or a vendor.
6. An escalation matrix with named roles and the time limits for moving a ticket up.
7. A monthly report that lists every miss with the ticket, the time taken and the reason.
8. How repeat incidents are handled, including root-cause analysis.
9. How onsite work is handled: whether any visits are included, how they are booked and how they are charged.
10. Who raises and chases faults with your internet provider, hardware suppliers and software vendors.

Put the same list to every provider and compare the answers line by line. For a wider view of the decision, read our checklist for choosing an IT support company in Dubai, or ask us for our targets in writing.