When a critical system fails during the working day, the questions that matter to a business owner are practical: who will respond, how soon, and when normal operation will resume. An IT SLA, or service level agreement, is the document that answers those questions in measurable terms. For a London SME without an in-house technology team, the wording of its IT SLA determines how much operational risk the business carries. This article explains how response and resolution times should be defined, where commitments are most often misread, and what a sound agreement should contain.
Table of Contents
- Quick Takeaways
- What SLA Response Time Means in Practice
- Resolution Times and Why They Vary
- Setting Realistic Targets for London SMEs
- Comparing Common SLA Models
- Spotting SLA Gaming in Practice
- Reporting, Service Credits and Review
- Frequently Asked Questions
- References
Quick Takeaways
| Key Insight | Explanation |
|---|---|
| Response time measures action, not repair | A critical response commitment confirms that an engineer has started work. It does not guarantee that the fault is fixed within the same period. |
| Confirm when the clock starts | Timing from ticket submission differs materially from timing that starts after triage. Request the start and stop rules in writing. |
| Require resolution targets by priority | Response figures alone leave the time to restore service unmeasured. Each priority level should carry its own restoration target. |
| Define priority by business impact | Priority should reflect the number of users affected and the process interrupted, not the seniority of the person raising the ticket. |
| Match cover to trading hours | Confirm whether critical response applies before 9am and after 5pm, and whether out-of-hours cover is included or charged separately. |
| Audit pending status and ticket closures | Time spent in customer pending status and the number of reopened tickets reveal whether the SLA is being met in practice. |
| Review performance quarterly | Quarterly reviews of SLA reports and recurring incidents show whether targets still reflect the business. |
What SLA Response Time Means in Practice
Response time is the interval between an issue being logged and a qualified engineer acknowledging it and beginning work. It is not the same as resolution time. A provider committing to respond to a critical incident within 15 minutes is making a commitment about action starting, not about the fault being repaired.
The wording of the clock matters. Some SLAs start timing when a ticket is submitted, while others start only after the issue has been triaged, categorised and accepted by the service desk. The difference can change the effective commitment by a significant margin, particularly for incidents raised outside core hours.
Where the Clock Starts and Stops
The strongest agreements define three things: what counts as a response, how tickets are prioritised, and when timing starts and pauses. A headline figure without these definitions describes little about day-to-day service. Request these terms in writing before signing.
Resolution Times and Why They Vary
Resolution time measures how long it takes to restore service or put a reliable workaround in place. It depends on complexity, system access, third-party dependencies such as a broadband carrier or software vendor, and whether the fault can be reproduced.
Resolution targets are most useful when they are set by priority. A provider that commits to restoring a priority one (P1) incident within a stated period, but offers no target for lower priorities, leaves most of its workload unmeasured. Commitments should reflect the business consequence of each fault.
Priority Levels Based on Business Impact
A common mistake is to classify priority by who raised the ticket. A managing director’s laptop fault may have low impact, while an outage of a shared accounting system affecting the whole office is critical. Priority should follow business impact, and the criteria should be agreed in advance rather than decided case by case.
Setting Realistic Targets for London SMEs
Many London SMEs trade across extended hours, with clients, couriers and remote staff relying on systems before 9am and after 5pm. The agreement should state whether response commitments apply at all hours or only during business hours, and whether critical incidents are treated differently outside them.
Targets should match the cost of downtime. A professional services firm that cannot access email for a morning faces different risks from a warehouse that cannot print dispatch labels. Discuss these consequences with the provider before agreeing figures, rather than accepting a generic template.
Out-of-Hours Cover for Critical Systems
Where out-of-hours cover is required, confirm the on-call arrangement, the escalation path and whether engineers can access systems remotely. Out-of-hours cover is often priced separately, so it should be included in the cost model from the outset.
Comparing Common SLA Models
Three models are common in managed IT contracts. Each suits a different risk profile, and each has limitations that should be understood before signing.
| SLA Model | What It Commits To | Best Suited To |
|---|---|---|
| Response-only commitment | Acknowledgement and start of work within a stated time | Low-risk environments with few critical dependencies. Fix time remains unmeasured. |
| Response and resolution by priority | Acknowledgement and restoration targets for each priority level | Most SME operations, provided priority definitions are agreed in writing |
| Service availability targets | Uptime percentage for named platforms such as Microsoft 365 or line-of-business applications | Businesses that depend on continuous cloud access. Availability alone does not measure helpdesk responsiveness. |
For most London SMEs, the response and resolution model by priority offers the clearest accountability. Combining it with availability reporting covers both helpdesk performance and platform reliability.
Spotting SLA Gaming in Practice
Some providers meet SLA figures on paper while delaying real progress. Service management practitioners have documented several recurring patterns, and they weaken trust in reported performance.
A service level that can be paused without the customer’s agreement is a service level that needs independent checking.
Pending Status and Clock Stops
One pattern is placing a ticket into customer pending status while waiting for a question that is not needed to progress the work. Pauses are legitimate only when the provider genuinely awaits customer input. Ask for a report showing time spent in pending status for each ticket.
Ticket Splitting
Another pattern is closing a ticket just before its target expires and opening a new one, which restarts the clock. The agreement should require ticket continuity, so that related incidents retain their original timestamps.
Pro tip: Ask for a monthly ticket export showing creation, acknowledgement, pending and closure timestamps. Comparing these against the SLA definitions reveals clock manipulation quickly.
Reporting, Service Credits and Review
SLA reporting should be produced monthly and reviewed at least quarterly. Reports should show response and resolution performance by priority, the number of breaches, average times and tickets reopened after closure. Without these figures, the SLA is only a document.
Service credits are reductions in fees when targets are missed. They signal commitment, but they rarely compensate for lost trading time, so they should not be the primary protection. Regular service reviews that address recurring faults deliver more lasting value.
Our virtual IT department service includes quarterly technology reviews and measurable SLAs, so the reporting described here forms part of routine delivery. Further details are available at iTO.London.
Pro tip: Compare SLA performance with recurring incidents at each quarterly review. Repeated faults in the same system point to a root cause that the SLA alone will not resolve.
Frequently Asked Questions
What is the difference between IT response time and resolution time?
Response time is the interval before a qualified engineer acknowledges an incident and starts work. Resolution time is the interval until service is restored or a workaround is in place. A short response time does not guarantee a short resolution time.
What response times should a London SME expect for critical incidents?
There is no single standard figure. Critical incident response should be stated in minutes rather than hours, and the agreement should specify whether it applies outside business hours. The right target depends on how much revenue or productivity depends on the affected system.
Should an SLA include resolution targets as well as response targets?
Yes. Response targets confirm that work has started, while resolution targets measure whether the business returns to normal working. Both should be set by priority, with agreed definitions for each level.
How can a business tell whether an SLA is being met in practice?
Request monthly reports showing timestamps for creation, acknowledgement, pending status and closure. Compare these with the SLA definitions, and review reopening rates, which often reveal premature closures.
Is an SLA the same as a managed IT service contract?
No. The SLA is one part of a managed IT service contract. It sets measurable service expectations, while the wider contract covers scope, pricing, responsibilities, data handling and termination terms.
We welcome feedback from business owners and managers on how their current IT support agreements measure response and resolution times, and which measures have proved most useful in practice.
We would love your feedback and any insights you would share with others. What perspective would you add?