You're reviewing an MSP contract because the renewal date is close, or because your current provider has promised that the next agreement will be “more proactive”. The document contains familiar phrases such as 99.9% uptime, “priority support” and “reasonable endeavours”. What it may not contain is who takes control during a Microsoft 365 outage, how quickly a third-party carrier must be engaged, or what evidence you'll receive after a security incident.
That's the weakness in many UK SME contracts. A service level agreement isn't valuable because it contains impressive numbers. It's valuable because it gives your team a controlled response when operations, client commitments, insurance requirements or regulatory scrutiny are at risk.
Table of Contents
- Why the Service Level Agreement Decides Your Worst IT Day
- What a Service Level Agreement Actually Is
- The Core Components Every UK SME SLA Must Include
- Sample Service Level Agreement Clauses for Common Managed Services
- From Uptime Promises to Governance and Cyber Resilience
- How to Choose an MSP That Will Actually Hit Its SLAs
- Common Service Level Agreement Pitfalls and How to Negotiate Past Them
- Service Level Agreement Checklist and FAQs for UK SMEs
Why the Service Level Agreement Decides Your Worst IT Day
At 08:15 on a Monday, the hosted ERP at a 40-person manufacturer in the North West stops responding. Production planning can't access orders. The finance team can't raise invoices. The operations director calls the MSP and reaches a service desk queue.
At 08:20, an automated ticket acknowledgement arrives. At 08:45, a technician says the issue has been escalated. At 09:30, nobody has told the directors whether the failure is local, hosted or related to the connectivity provider. By 10:15, the MSP confirms that its hosting platform is available, but the underlying virtualisation layer is being investigated by another supplier. At midday, the business still has no restoration estimate.
That sequence may sound poor, but it might be contractually compliant. If the agreement only promises general support during business hours and contains a broad uptime statement, the MSP can argue that it responded promptly. The business owner is left with a ticket number, no meaningful recovery commitment and a service credit that may be difficult to claim.
The difference between acknowledgement and control
A serious service level agreement separates the first reply from the actions that matter:
- Incident ownership: One named provider remains accountable, even when Microsoft, a telecoms carrier, a backup platform or a data-centre operator is involved.
- Escalation timing: The agreement states when a senior engineer, service delivery manager and director become involved.
- Communication: Directors receive updates at defined intervals, not only when somebody has new technical information.
- Recovery: The provider commits to restoring service or delivering a workable alternative, rather than merely opening a case.
- Evidence: The incident record, timeline, root-cause analysis and service-credit calculation are available after the event.
UK public-sector agreements demonstrate why this discipline matters. The GOV.UK Service Level Agreement between the Traffic Commissioners and the Driver and Vehicle Standards Agency was implemented on 26 March 2021, with review every three years or sooner if circumstances required. The same document also illustrates that agreements can be tied to formal governance rather than informal operational promises.
Practical rule: If your contract doesn't tell you who acts, who communicates and what happens when the target is missed, you haven't bought resilience. You've bought an expectation.
A Manchester law firm faces the same test when its document system or hosted desktop fails before a tribunal hearing. The board, insurer, client or regulator won't be interested in how quickly a generic ticket was acknowledged. They'll ask whether the firm had a documented control, whether the provider followed it and whether the provider's performance could be evidenced.
What a Service Level Agreement Actually Is
A service level agreement is a measurable contract artefact. It binds a provider to defined service outcomes, explains how performance will be measured and sets out the remedy when the provider falls short. It isn't a marketing promise on a website, and it shouldn't be buried in a master services agreement where operational commitments are hard to find.
The master services agreement, or MSA, normally establishes the legal relationship, payment terms, liability position and termination rights. The SLA should sit alongside it as an operational schedule. Other documents, such as an Acceptable Use Policy, security schedule, data-processing agreement or backup policy, support the SLA but shouldn't replace it.
Seven building blocks to insist on
A credible agreement should contain these elements:
- Scope: List every included service, system, location, support channel and operating window. State exclusions with equal precision.
- Service levels: Define availability, response, restoration, resolution and communication targets using measurable terms.
- Severity model: Explain what makes an incident P1, P2 or P3, based on business impact rather than the customer's preferred label.
- Measurement method: State the clock, timezone, measurement window, monitoring source, pause rules and treatment of scheduled maintenance.
- Accountability: Name the service owner, escalation contacts and customer responsibilities. “The support team” isn't an accountable person.
- Remedies: Define service credits, claim procedures, repeated-breach triggers and termination rights.
- Governance: Set reporting requirements, review meetings, change control, security oversight and the process for amending the agreement.
The public-sector GOV.UK framework service level agreement guidance makes an important point for SME buyers. A framework can set out minimum components while allowing local tailoring. You should use templates as a starting structure, not copy them without adapting the service boundaries and risks of your own business.
The Core Components Every UK SME SLA Must Include
Weak SLAs describe support. Strong ones define an operating model. Push for the following components, then test each one against a realistic outage, cyber incident and supplier failure.
Seven clauses that should survive legal review
Scope and exclusions come first. Name the services, dependencies and customer obligations. If the MSP excludes third-party platforms, require a coordinated escalation obligation rather than accepting that the provider has no responsibility once a vendor is involved.
Availability needs both a target and a denominator. A 99.9% monthly availability target allows roughly 43 minutes of unplanned downtime in a calendar month, or about 8.76 hours across a year, as explained in UK SLA availability guidance from Netix Digital. The contract must say whether scheduled maintenance, customer-side faults, force majeure and upstream outages are excluded, and how those exclusions are evidenced.
Response and restoration must be separated. A response means somebody has acknowledged and taken ownership. A restore target means users can work again, even if the permanent fix comes later.
| Component | What It Must Specify | Typical SME Threshold |
|---|---|---|
| Scope | Services, assets, sites, dependencies and exclusions | Itemised service catalogue |
| Availability | Percentage, measurement window and downtime definition | 99.9% measured monthly |
| Incident response | Severity criteria, channels and first human response | P1 response within 15 minutes, 24/7 |
| Restore or resolution | Workable restoration and permanent-fix expectations | Tier-one backup restore within 4 hours |
| Service credits | Calculation, claim process and repeated-breach remedy | Credit expressed as a percentage of the monthly fee |
| Reporting | Metrics, incident evidence, owner and delivery date | Monthly report with named owner |
| Governance | Review attendees, agenda, change control and escalation | Quarterly service review |
The service level agreement metrics guide gives useful context on how buyers can distinguish operational measures from vague service language. Use it to challenge a proposal that lists ticket counts but omits customer impact, restore performance or recurring-cause analysis.
Security cannot sit in a separate universe
For firms handling personal data, financial information, legal files or safety-critical operations, add explicit obligations for patching, MFA enforcement reporting, endpoint detection, vulnerability escalation, incident classification and breach notification. State who informs you, what information the first notification contains and how the provider coordinates with your legal, insurance and compliance teams.
Also require monthly reporting that shows missed targets, open P1 and P2 incidents, ageing problems, backup exceptions, security events and agreed corrective actions. A quarterly review should examine trends and decisions, not become a supplier presentation with no minutes or owners.
Sample Service Level Agreement Clauses for Common Managed Services
The fastest way to test an SLA is to ask how its words would appear during a real incident. The examples below are negotiation benchmarks, not universal legal wording. Your solicitor should align them with liability, data protection and sector requirements.
Microsoft 365 management
A useful clause might read:
“For a P1 incident affecting tenant-wide mail flow or Teams availability, the provider shall acknowledge the incident within 15 minutes, assign a named incident owner and provide updates at agreed intervals until service is restored. A P2 incident affecting a single mailbox or licence shall receive a response within one hour and a resolution or workaround within eight hours. P3 how-to requests shall receive a response by the next business day.”
The negotiation move is simple. Don't accept “Microsoft issue, customer to contact Microsoft” if your MSP manages the tenant. Require the MSP to coordinate the escalation, record the Microsoft case reference and remain responsible for communication.
Managed backups
For backups, demand an RPO, the maximum acceptable data-loss window, and an RTO, the time required to restore service. Both should be expressed in minutes or hours appropriate to the workload, not hidden behind “best efforts”. Require evidence of restore testing, documented ransomware isolation steps and a named person responsible for approving recovery.
The buyer's primary concern is the evidence requirement. A backup that reports “successful” but has never been restored shouldn't count as resilience.
Hosted desktops
A hosted desktop clause should commit to 99.9% monthly availability, define the measurement source and provide service credits when the target is missed. It should also separate responsibility for the desktop broker, virtual machines, hypervisor, storage, connectivity and customer endpoints.
Many providers create a loophole here. If the broker is available but the underlying hypervisor cannot start desktops, the service is unavailable to your users. The SLA must measure the business service, not whichever component is easiest to defend.
VoIP services
For VoIP, define call-quality measures such as mean opinion score, jitter and packet loss, then connect failures to a remedy. “Voice quality is dependent on the customer's internet connection” is incomplete if the provider supplies the circuit, handsets, network management or SIP service.
The IT support SLA response-time guide can help you assess whether a provider's proposed categories distinguish urgency from convenience.
| Service | Response / Resolve | Availability Target | Measured Credit | Key Clause to Add |
|---|---|---|---|---|
| Microsoft 365 | P1 within 15 minutes, P2 within 1 hour, P3 by next business day | Service-specific | Credit for missed target | MSP owns Microsoft escalation |
| Managed backups | Restore target tied to workload | Platform-specific | Credit for failed restore commitment | RPO, RTO and restore evidence |
| Hosted desktops | Incident response plus restoration | 99.9% monthly | Credit for measured outage | Broker and hypervisor responsibility |
| VoIP | Fault response by severity | Service-specific | Credit linked to quality or outage | Jitter, packet loss and carrier escalation |
From Uptime Promises to Governance and Cyber Resilience
At 9 a.m., a system can show 99.9% availability while your business is still exposed. Uptime confirms that a service responds. It does not confirm that the provider detected a compromise, isolated ransomware, briefed directors or fixed the weakness behind the incident.
The 2025 UK and Ireland IT Sourcing Study examined over 1,000 IT sourcing relationships and more than 1,100 cloud relationships from nearly 400 respondents. For a UK SME, the practical point is direct: assess the provider across the whole relationship, not only by helpdesk response speed.
Governance clauses that make security actionable
Put these requirements in the agreement:
- Security reporting: Evidence of MFA coverage, patching status, endpoint alerts and unresolved high-risk findings.
- Incident ownership: A named provider lead responsible for technical response, supplier escalation and customer communication.
- Breach notification: A defined process covering the initial information set, update rhythm and evidence trail.
- Change control: Approval, testing, rollback and emergency-change records for material alterations.
- Supplier management: A documented escalation route through Microsoft, backup vendors, SIP carriers, cloud hosts and data-centre operators.
- Root-cause action: A corrective-action plan with an owner and due date after material incidents.
Service quality also depends on communication. Ofcom reporting and the UK Customer Satisfaction Index material show that technical compliance does not automatically produce a good service relationship. A provider may meet a response timer while users repeat information, remain confused and wait for a meaningful recovery update. Require the SLA to measure communication quality and ownership, not just elapsed minutes.
Your disaster recovery plan must connect to the SLA. Use this disaster recovery plan guide to check that recovery responsibilities, dependencies and testing align.
An uptime promise without incident governance confirms an outage. It does not confirm that anyone was accountable for recovery.
How to Choose an MSP That Will Actually Hit Its SLAs
Treat the procurement process as an evidence exercise. Every MSP can describe a polished support model. Fewer will show how its engineers, service managers and suppliers behave when a P1 threatens to breach.
Ten buyer-side tests
- Dashboard proof: Ask to see a live or redacted ticket dashboard, including ageing and breached incidents.
- Named ownership: Get the service delivery manager's name and deputy in the contract.
- Escalation route: Check that the matrix includes direct phone numbers, senior contacts and third-party escalation steps.
- Security evidence: Request current evidence for Cyber Essentials Plus or ISO 27001 where relevant to your risk profile.
- Sector references: Speak to customers in engineering, manufacturing, legal, financial or similarly regulated environments.
- Report sample: Review a real monthly report pack. It should show misses, trends, incidents and actions.
- Exit mechanics: Confirm data return, configuration handover, assistance and deletion obligations at termination.
- Insurance: Verify that the provider carries suitable professional indemnity and cyber cover, with certificates available.
- Plain-English SLA: Read the credit formula, exclusions, claim process and breach triggers without needing an interpreter.
- Review discipline: Ask for sample quarterly review minutes showing decisions, owners and due dates.
The managed service provider guide is useful when you're comparing a full-service MSP with a helpdesk-only supplier. The difference matters because your SLA should cover the services you're outsourcing, not just the ticket queue.
Green flags and red flags
| Green flag | Red flag |
|---|---|
| 99.9% monthly availability with defined measurement and reporting | One blanket 99% uptime promise |
| P1 response within 15 minutes with named escalation | “We'll respond as soon as reasonably possible” |
| Quarterly reviews with written minutes | No review owner or meeting obligation |
| Credits linked to measurable breaches | Credits that are discretionary or impossible to claim |
| Clear responsibilities across suppliers | MSP disclaims every third-party dependency |
| Security, patching and incident clauses | No security obligations in the SLA |
A provider that can't quantify its promises shouldn't be trusted with your operations. Score the proposal against your actual business services, then ask the MSP to demonstrate how its systems would prove compliance after an incident.
Common Service Level Agreement Pitfalls and How to Negotiate Past Them
The most dangerous SLA clauses often look commercially reasonable. “Reasonable endeavours”, “subject to third-party availability” and “planned maintenance excluded” can each be acceptable in the right context. Left undefined, they can remove most of the protection you thought you'd purchased.
Five clauses that deserve pushback
“Best efforts” language gives the provider no measurable finish line. Replace it with response, escalation, restore and communication obligations. If a permanent resolution depends on a vendor, require the MSP to provide a workaround and remain accountable for the escalation.
Exclusions that swallow the commitment make the headline availability number decorative. Ask for a complete exclusions schedule, a definition of scheduled maintenance, advance notice requirements and evidence for any claimed exclusion.
Credits below commercial significance fail to change provider behaviour. Require a credit formula tied to the affected service, a clear claim process and stronger remedies for repeated breaches. Credits shouldn't be the only protection where failure creates material operational or regulatory exposure.
Security omissions leave patching, MFA, monitoring and incident communication to goodwill. Put each obligation in the SLA or a clearly incorporated security schedule, with reporting and escalation requirements.
Single-vendor escalation paths create dead time when the outage sits with Microsoft, a carrier or a hosting supplier. The MSP may not control the third party, but it can control case ownership, communication, evidence and escalation.
| Common SLA Pitfall | What It Costs You | Negotiation Fix |
|---|---|---|
| “Reasonable endeavours” | No objective performance test | Set timed response, restore and update duties |
| Broad third-party exclusions | Provider can avoid ownership | Require coordinated escalation and communication |
| Unclear downtime denominator | Disputes over availability | Define monitoring source, window and exclusions |
| Weak service credits | Little commercial incentive | Link credits to the affected service and repeated breaches |
| No root-cause obligation | The same incident can recur | Require analysis, corrective action and due dates |
| Missing review process | Problems remain invisible | Set a named owner and fixed review cadence |
Make the agreement a working control
Require the provider to record when an incident started, when it was detected, who owned it, what suppliers were contacted and when service was restored. Ask for a root-cause report after material incidents, with corrective actions reviewed at the next governance meeting.
Put a customer-side owner against the SLA too. The finance director, operations lead or IT manager should know who checks monthly reports, claims credits and requests amendments. A living agreement needs an owner on both sides.
Service Level Agreement Checklist and FAQs for UK SMEs
Before signing or renewing, mark each item as confirmed, missing or requiring legal review:
- Scope: Every managed service, dependency, site, device and exclusion is itemised.
- Availability: The percentage, monthly measurement window, denominator and exclusions are written down.
- Incident handling: Severity definitions, response targets, restore targets and communication intervals are separate.
- Remedies: Credits have a calculation, claim process and repeated-breach consequence.
- Security: Patching, MFA, monitoring, incident notification and evidence obligations are explicit.
- Escalation: Named contacts exist for the MSP, customer and relevant third-party suppliers.
- Continuity: RPO, RTO, backup testing and recovery responsibilities match the business impact.
- Exit: Data portability, configuration handover, deletion and transition assistance are defined.
- Governance: Reviews occur on a fixed cadence, with minutes, actions and an amendment process.
Frequently asked questions
What does 99.9% uptime mean?
The UK benchmark discussed earlier translates to roughly 43 minutes of unplanned downtime per calendar month, subject to the contract's exclusions and measurement method. Ask whether the figure applies to the whole service or only a component.
How do service credits work?
A credit reduces a future invoice when a defined target is missed. The SLA should state whether you must claim it, the deadline for claiming, the affected fee base and whether repeated breaches create additional rights.
Will an SLA survive a TUPE transfer?
Don't assume it will. Review assignment, supplier-change, personnel-transfer and termination provisions with your solicitor. The operational commitments should remain clear if responsibility moves between providers.
What should regulated firms add?
Legal, healthcare and FCA-supervised businesses should add audit access, security evidence, breach-notification procedures, data-location requirements where relevant, retention duties and cooperation with client or regulator enquiries. The exact wording should reflect the firm's risk assessment and regulatory obligations.
Use this checklist before your next renewal, even if your business is small. A short contract with clear ownership protects you better than a long document filled with undefined promises.
Blowfish Technology provides managed IT support, Microsoft 365 management, hosted desktops, managed backup and disaster recovery, connectivity and VoIP services under measurable service arrangements. Visit Blowfish Technology to discuss an SLA that covers governance, security and multi-vendor escalation, not just uptime.
The Blowfish Technology team. Managed IT, cloud services, software development and connectivity for North West businesses since 1999.