An IT support SLA (Service Level Agreement) is the written promise behind your contract: it defines how fast your provider acknowledges and works on problems, how issues are prioritised, and what happens if targets are missed. In London, a typical SLA guarantees a first-response time (often 4–15 minutes for priority issues), priority levels from P1 to P4, and credits or penalties when the provider falls short.
What an IT support SLA actually covers
An SLA is not a marketing slogan — it is a measurable, enforceable part of your contract. A good one spells out exactly what 'support' means, when it applies, and how performance is judged. The aim is not to sound reassuring. The aim is to remove ambiguity on the morning something breaks.
At minimum, a London IT support SLA should define: service hours (business hours versus 24/7), the channels you can log a ticket through (phone, portal, email), response and resolution targets by priority, escalation paths, and the reporting you receive. It should also state what is excluded — out-of-scope software, third-party faults, or changes that count as project work rather than support.
Where providers differ is the detail. A vague SLA promising 'fast, friendly support' guarantees nothing you could ever hold them to. A strong SLA attaches numbers to each priority level and explains how those numbers are measured. If you run an in-house team alongside external help, check how the SLA handles shared responsibility under a co-managed IT support arrangement.
When you compare managed it services london providers, ask for the SLA document itself rather than a summary slide. The gap between what a salesperson says and what the contract commits to is where disputes start.
Response time vs resolution time — the difference that matters
These two terms get confused constantly, and the confusion costs businesses money. Response time is how quickly someone acknowledges your ticket and starts work. Resolution time is how long until the problem is actually fixed. A provider can hit a brilliant response target and still leave you offline for a day — so you need both defined.
Most honest SLAs guarantee response times firmly but treat resolution times as targets rather than hard promises. That is reasonable: a failed hard drive, an ISP outage or a Microsoft 365 service incident is not always within the provider's sole control. What you want is a committed response time, a realistic resolution target per priority, and a clear escalation process when a fix is taking too long.
Watch for 'resolution' being defined as a workaround rather than a permanent fix. Logging a user back in temporarily is not the same as solving the underlying fault. A mature provider distinguishes between restoring service and closing the root cause, and reports on both.
Priority levels and how tickets are triaged
Triage is the process of ranking incoming tickets so the most damaging issues get attention first. Without it, a single-user password reset competes with a company-wide outage for the same engineer. A clear priority matrix is the backbone of any credible SLA.
Most London providers use four or five priority levels based on impact (how many people are affected) and urgency (how time-critical it is). The classification should be objective, not left to whoever happens to pick up the phone. You should also be able to escalate a ticket's priority if circumstances change — for example, a minor issue becomes business-critical as a deadline approaches.
- P1 (Critical): entire site or key system down, no workaround — fastest response, continuous work until restored.
- P2 (High): significant impact on a team or core function, limited workaround available.
- P3 (Medium): single user or non-critical issue affecting productivity.
- P4 (Low): requests, minor queries, scheduled changes and 'how do I' questions.
- Service requests: onboarding, new starters, equipment — often tracked separately from incidents.
What a 4-minute first response means in practice
A headline figure like a '4-minute average first response' sounds impressive, but you need to read it precisely. A 4-minute average means exactly that — an average, measured across all tickets. It is not a guarantee that every single ticket is answered within four minutes, and an average can hide a long tail of slow responses.
In practice, a genuine fast-response helpdesk means that at 09:10 on a Monday, when half the office cannot log in, a real engineer acknowledges your ticket and starts triaging within minutes — not an automated 'we have received your request' email. The important detail is what 'response' triggers the clock-stop: a human beginning work, not a robot confirming receipt.
Ask whether the figure is a target or a guarantee, whether it is an average or a percentile (for example, 95% of P1 tickets responded to within X minutes), and how it is measured. Percentile commitments are harder to game than averages and tell you more about the worst-case experience. Our own remote IT support and helpdesk run to a 4-minute average first response, and we report the underlying numbers so you can see the distribution, not just the headline.
Questions to ask about penalties and reporting
An SLA without consequences is just a wish list. The teeth of a service level agreement are the remedies — what you get when targets are missed — and the reporting that lets you verify performance independently. Both are routinely weak in cheaper contracts.
Service credits are the most common remedy: a percentage of the monthly fee refunded when the provider breaches a target. These are rarely large, but they prove the provider is willing to be measured. More important is transparency: monthly reports showing tickets logged, response and resolution times against SLA, trends, and recurring problems. If you cannot see the numbers, you cannot manage the relationship.
- How are service credits calculated, and is there a cap or minimum breach threshold?
- Do I get a monthly or quarterly SLA performance report, and in what format?
- Are response times measured by average, or by percentile (e.g. 95th)?
- What counts as an exclusion — third-party faults, ISP outages, out-of-scope apps?
- Is there a Not-To-Exceed (NTE) spend limit on emergency work, and who authorises it?
- What is the escalation path and named contact when a P1 is not moving?
How SLAs differ for onsite, remote and connectivity issues
Not every problem is solved from a keyboard in another building. A complete SLA sets separate expectations for remote fixes, onsite attendance and connectivity faults, because the realistic timelines differ enormously. A remote password reset can take minutes; an engineer travelling across London to replace hardware cannot.
For onsite work, check the response commitment — is it 'next business day', 'same day', or a guaranteed number of hours? Central London travel is quicker than an outer-borough or home-counties site, so a London provider's SLA should reflect your actual locations. Our on-site IT support and managed it services london are structured so that most issues resolve remotely, with onsite attendance reserved for physical faults.
Connectivity deserves its own line in the SLA. If a leased line or broadband drops, the fault may sit with the carrier, not your IT provider. Where CLI Secure supplies the circuit too, the SLA covers the carrier's committed targets — including a Committed Information Rate (CIR) and fix-time guarantee — so you are not stuck between two suppliers blaming each other.
Reading an SLA before you sign
Treat the SLA as the most important page in the proposal, not the small print. Before signing, map your real-world scenarios against it: what happens if the finance system is down on payroll day, or email fails at 2am before an early flight? Trace each scenario through the priority matrix, response time and escalation path.
Be wary of SLAs that are all averages and no commitments, that define resolution loosely, or that exclude so much that little meaningful support remains. Equally, an SLA with heavy penalties but no reporting is hard to enforce in practice. You want measurable targets, independent reporting and a realistic escalation route — in that order.
If you are moving provider, ask to see a redacted sample of a recent monthly SLA report. It tells you more about how a provider actually performs than any sales conversation. When the numbers are shared openly, you are dealing with a provider confident in its service — and that confidence is usually earned.