What a Good IT Support SLA Looks Like (With Real Examples)

If you’re a business owner in the UK with 10–200 people, you’ll have felt the small-but-constant drag of IT issues: slow logins, flaky Wi‑Fi, or the odd Monday morning server hiccup that turns a whole day into a juggling act. That’s why a clear, practical Service Level Agreement (SLA) matters. This piece explains, in straightforward terms, what a good IT support SLA looks like — with real, usable examples you can copy or adapt.

Why the SLA is a business document, not a geek brochure

An SLA should be written for the person who signs the invoices, not the person who likes building tiny networks in their spare time. Senior teams care about three things: money, time and reputation. A decent SLA shows how the IT supplier will keep downtime short, predictable and inexpensive — and what happens when they don’t.

Core elements every SLA must include

• Scope: Which systems and users are covered? Be specific: on‑site desktops, cloud services, email, backups, phones, printers. Exclusions (personal devices, unauthorised software) should be explicit.
• Contact and escalation: Who you call first, expected response times, and who you escalate to if the problem isn’t solved.
• Response vs resolution: Response time is when somebody picks it up; resolution time is when the issue is fixed. Both matter.
• Severity definitions: A 1–4 scale (Critical to Low) with plain English examples — for instance, “Critical: entire office can’t access email or core applications.”
• Performance targets: Clear, measurable targets for each severity level.
• Reporting and review: Monthly tickets, recurring meetings, and reviews after major incidents.
• Penalties and remedies: Credits, refunds or extra support if targets aren’t met. Keep these reasonable — you want accountability, not a legal arms race.
• Change control and maintenance windows: When routine work will happen (avoid Monday mornings), and how you’re notified of planned downtime.
• Data protection and compliance: GDPR responsibilities, who’s the data processor, backups, and retention periods.

Reasonable metrics for UK businesses of your size

Small and mid‑sized firms in the UK don’t need the same 15‑minute disaster guarantees as a major bank. Aim for practical targets that balance cost and risk. Here are sensible starting points you can tweak for your industry.

• Critical (business‑stopping): Response within 30–60 minutes, target resolution within 4–8 hours or a defined workaround within 2 hours.
• High (major impact to several users): Response within 1–2 hours, resolution within 1 working day.
• Medium (single user or non‑urgent): Response within 4 hours, resolution within 3 working days.
• Low (general advice, routine requests): Response within 1 working day, resolution within 5–10 working days.

Real examples: practical SLA clauses you can use

Below are sample clauses. These aren’t case studies — they’re templates you can drop into a draft SLA.

Example clause: Severity definitions

Severity 1 (Critical): Core business systems unavailable to all users (e.g. email, accounting software). Response: 30 minutes. Target: resolution or workable workaround within 4 hours. Availability: 07:00–19:00 Mon–Fri; out‑of‑hours support optional.

Example clause: Response and resolution

Response means initial contact from an engineer or automated ticket acknowledgement. For Severity 2 incidents, initial response within 2 hours and target resolution within 1 working day. If a resolution is delayed, supplier must provide hourly updates until service restored.

Example clause: On‑site attendance

Where an issue cannot be resolved remotely, on‑site attendance will be scheduled within 4 working hours of confirmation for Severity 1 incidents in our Greater London, South East and Midlands service area; outside these areas, attendance target is next working day. Local travel delays such as severe weather or public transport strikes will be communicated and re‑scheduled.

Example clause: Service credits

If the supplier fails to meet Severity 1 targets for two or more events in a calendar month, the customer is entitled to a service credit equal to 10% of that month’s service charge per missed target, capped at 50% for the month. Credits are the sole financial remedy unless fraud or gross negligence is proven.

What to negotiate (and what to accept)

Expect some give and take. Faster response times cost more. Three practical negotiation points:

• Ask for business hours cover as standard and out‑of‑hours as optional add‑on.
• Negotiate capped service credits rather than open liability — it keeps both parties working to solve issues instead of suing over them.
• Agree on a practical definition of ‘resolved’. A fix that restores business operations (workaround) is often preferable to a long, perfect technical fix that leaves you offline in the meantime.

Red flags to watch for

• Vague language: “reasonable endeavours” is lawyer‑speak for “we’ll try, but no promises”.
• No escalation path: If your day‑to‑day contact is unreachable, who’s next?
• Unclear scope: If backups, cloud services or security updates aren’t listed, assume they’re excluded.
• Unrealistic promises: 15‑minute resolution for all incidents is usually expensive and unnecessary for most SMEs.

How to use the SLA in practice

An SLA isn’t a document you sign and forget. Use it as the basis for monthly reviews. Look at ticket trends, agree improvements, and make small changes to the wording if real life shows a gap — for example, adding clarity around patch schedules or staff‑return procedures after long holidays like Christmas or bank holiday weekends.

FAQ

Do I need a 24/7 SLA?

Only if your business operates round‑the‑clock or an outage outside office hours would materially hit revenue or reputation. Many UK businesses are well served by robust business‑hours cover plus a paid on‑call service for nights and weekends.

What’s the difference between response time and resolution time?

Response time is when an engineer acknowledges the issue. Resolution time is when the issue is fixed or a reliable workaround is in place. Both should be in the SLA so you know how long you’ll be in limbo.

How strict should penalties be?

Penalties should create accountability, not rancour. Service credits tied to measurable breaches are common and practical. Heavy financial penalties can lead to defensive behaviour and higher costs overall.

Should backups be in the SLA?

Yes. The SLA should state what is backed up, how often, retention periods and the expected recovery time. If GDPR or industry regulations apply, include those requirements explicitly.

Final thoughts

A good IT support SLA balances realism and protection. It gives you predictable costs, reasonable response and resolution targets, and a simple escalation route when things go wrong. Use the sample clauses above to draft a version that fits your team size, location and risk tolerance — whether you’re in a terraced office in Leeds, a commuter belt HQ in Reading, or a showroom in Manchester.

If you want to cut downtime, reduce surprise costs and sleep a bit easier, start by tightening the SLA: be precise about scope, agree practical response targets, and lock in regular reviews. It’s a small administrative effort that pays back in time, money, credibility and calm.