Service Level Agreement Template For IT Support

Maya runs a small managed IT support business in Leeds. A new customer is ready to sign, but they want a guarantee that critical tickets will be fixed within four hours, their systems will stay online 99.9% of the time, and they will get money back if anything goes wrong.

That sounds reasonable on paper. But Maya knows some outages are caused by the customer's internet provider, old hardware, missed licence renewals or staff ignoring security updates. If her contract doesn't separate what she controls from what she doesn't, one bad month could wipe out her profit.

A service level agreement template can be a useful starting point for IT support, but it needs to be shaped around your actual services, tools, customers and risk. This is especially true if you're an MSP promising uptime, helpdesk support, cyber monitoring or managed devices.

Do You Need A Service Level Agreement For IT Support?

Yes, if you're promising response times, uptime, support hours or service credits, you should have a written SLA that sits with your IT support contract or managed service agreement.

An SLA turns general promises like we respond quickly into measurable commitments. For example, it can say a Priority 1 ticket gets an initial response within 30 minutes during support hours, while a low-priority request gets a response within one business day.

For an IT support provider, the SLA isn't just a customer service document. It's also a risk document. It should answer practical questions like:

• What counts as a support request?
• When does the response clock start and stop?
• Are targets measured during business hours or 24/7?
• What happens if the customer doesn't give you access or information?
• Are service credits the customer's only remedy for missed targets?
• Which outages are excluded because they're outside your control?

Without a clear SLA, customers may expect every issue to be urgent, every downtime event to be your fault, and every delay to justify a refund. A well-drafted SLA helps set fair expectations from day one, which makes onboarding smoother and disputes less likely.

What Should An IT Support SLA Template Include?

An IT support SLA template should include the services covered, performance targets, exclusions, customer responsibilities, reporting rules and the remedies available if targets are missed.

It's usually best to use the SLA as a schedule to your main IT support contract or managed service agreement. The main agreement deals with the bigger legal terms, such as fees, payment, liability, confidentiality, intellectual property, termination and data protection. The SLA then deals with the day-to-day service commitments.

Here is a fill-in outline you can use as a starting point. A lawyer should tailor it before you use it with customers, because small wording changes can make a big difference to your risk.

1. Parties And Customer Sites: Name your business, the customer, supported locations, users, devices and systems.
2. Services Covered: Describe the IT support, helpdesk, monitoring, backup, security, patching or managed services included.
3. Services Excluded: List anything outside scope, such as project work, unsupported software, user training, third-party outages or after-hours work.
4. Support Hours: State your normal support hours, emergency hours, public holiday rules and any 24/7 cover.
5. Priority Levels: Define Priority 1, 2, 3 and 4 tickets using clear business impact descriptions.
6. Response And Resolution Targets: Set measurable response times and, if appropriate, target resolution times.
7. Uptime Commitments: Explain any availability target, how uptime is measured, and what downtime doesn't count.
8. Customer Responsibilities: Require timely access, accurate information, supported hardware, licences, backups and security practices.
9. Security Incidents: Set out notification steps, incident handling roles and data protection responsibilities.
10. Service Credits: Explain when credits apply, how they're calculated, caps, claim deadlines and exclusions.
11. Reporting And Review: State how performance is reported and how the SLA can be reviewed as the customer's systems change.

If you're using an IT support contract template, check whether it already contains SLA wording. Many templates mix the commercial agreement and SLA together, which can work for simple support packages. For managed services, a separate SLA schedule is usually cleaner because you can update service levels without rewriting the whole contract.

How Should You Set Response Times For A Helpdesk?

You should set helpdesk response times by priority level, support hours and business impact, not by promising the same turnaround for every ticket.

A common mistake is saying all issues will be responded to as soon as possible or fixed within a fixed number of hours. That can be hard to manage when one customer has a full outage and another has a printer issue.

A clearer helpdesk service level agreement usually separates response targets from resolution targets. A response target is when you first acknowledge and start assessing the issue. A resolution target is when you aim to fix or work around the issue. Resolution is harder to promise because you may rely on third-party vendors, customer approvals or replacement hardware.

Example Priority Structure

• Priority 1 - Critical: The customer's core system is unavailable and there's no reasonable workaround. Initial response within 30 minutes during covered hours.
• Priority 2 - High: A major function is affected, but part of the business can continue. Initial response within 2 hours.
• Priority 3 - Medium: A single user or non-critical function is affected. Initial response within 1 business day.
• Priority 4 - Low: General request, change, advice or minor issue. Initial response within 2 business days.

Your SLA should also explain how tickets are logged. For example, you might only measure SLA times for tickets submitted through your helpdesk portal or emergency phone line, not a text message to one technician.

Make sure you define when the clock pauses. If you ask the customer for a password, screenshot, approval or physical access and they don't respond, your SLA should say the target is paused until they provide what you need.

Can You Promise Uptime Without Taking On Too Much Risk?

Yes, but only if the uptime promise is carefully defined and tied to systems you actually control.

Uptime promises can sound simple, but they're often where MSP risk becomes expensive. If you promise 99.9% availability, you need to know what service that applies to, how it's measured, and what downtime is excluded.

For example, 99.9% uptime over a 30-day month allows about 43.2 minutes of downtime. If the relevant service is down for 120 minutes, the customer may expect a credit. But the result should be different if 80 of those minutes were caused by the customer's internet connection or a cloud provider outage outside your control.

Worked Example

Maya's customer pays a monthly managed services fee of £2,000. Her SLA promises 99.9% uptime for the firewall service she manages, measured monthly. The SLA says outages caused by the customer's ISP, power failure, unauthorised changes, scheduled maintenance and third-party platforms are excluded.

One month, the customer has 120 minutes of firewall downtime. After checking the logs, 70 minutes were caused by an unauthorised customer configuration change and 50 minutes were caused by Maya's delayed patch rollback. Only the 50 minutes count against the SLA.

Because 99.9% uptime allows about 43.2 minutes of downtime in that month, the excess is 6.8 minutes. If the SLA gives a 5% service credit for missing the uptime target, the credit is £100. If the SLA also caps monthly credits at 20% of the monthly fee, Maya's maximum exposure for SLA credits that month is £400.

That type of drafting gives the customer a real remedy, while stopping the SLA from becoming an unlimited guarantee for every system failure.

What Happens When A Security Incident Or Customer Delay Affects The SLA?

It depends on the cause, but your SLA should clearly say that customer delays, missing access, unsupported systems and certain security events can pause or exclude service targets.

Security incidents are a major issue for IT support providers because a cyber event can disrupt systems, trigger privacy obligations and create urgent customer pressure. Your contract shouldn't treat a ransomware attack the same way as a normal support ticket.

If you handle personal data for your business customers, UK GDPR and the Data Protection Act 2018 may apply. In many MSP arrangements, your customer is the controller and your business is the processor. That usually means your agreement needs UK GDPR Article 28 data processing clauses, including confidentiality, security measures, sub-processors, assistance with data subject requests and breach notification.

For personal data breaches, a controller may need to notify the Information Commissioner's Office within 72 hours of becoming aware of a notifiable breach. As a processor, you generally need to tell the controller without undue delay after becoming aware of a personal data breach. Your SLA should work alongside those duties, not accidentally promise a slower process.

Customer Dependencies To Include

• Providing administrator access, credentials and remote access promptly.
• Keeping hardware, software and licences supported and paid for.
• Following your security requirements, such as multi-factor authentication and patching.
• Approving changes, downtime windows and replacement equipment.
• Keeping agreed backups, unless backup management is part of your service.
• Not making unauthorised changes to systems you manage.

If a customer doesn't meet these responsibilities, your SLA should say the affected service levels are paused or don't apply for the affected incident. This is a fair way to protect your team without avoiding responsibility for the parts you control.

How Do Service Credits And Remedies Work?

Service credits work by giving the customer a pre-agreed account credit if you miss a service level, usually subject to caps, claim rules and exclusions.

Credits can be useful because they give customers certainty without turning every missed target into a legal dispute. For example, your SLA might say that if you miss a monthly uptime target, the customer gets a credit equal to 5% of that month's recurring fee for the affected service.

Keep the remedy proportionate. If a customer pays £500 per month, a £50 credit may be fair for a minor missed target. It would be risky to leave the contract open to uncapped claims for lost profits, lost revenue or business interruption, especially when IT outages can have knock-on effects.

Your main agreement should also include liability limits. In business-to-business contracts in England and Wales, the Unfair Contract Terms Act 1977 can affect whether certain exclusions and limits are enforceable, especially if they aren't reasonable. You also can't exclude liability for death or personal injury caused by negligence. This is an area where tailored advice is worth getting, because a badly drafted limitation clause can leave you more exposed than you realise.

Service Credit Drafting Checklist

• Say whether credits are the customer's sole remedy for the specific SLA failure.
• Link credits to the fee for the affected service, not the customer's whole business loss.
• Set a monthly cap, such as a percentage of the monthly recurring fee.
• Require the customer to claim within a set period after the end of the month.
• Exclude incidents caused by the customer, third parties, scheduled maintenance, force majeure events and unsupported systems.
• State that credits don't apply while invoices are overdue, if that fits your commercial model.

Also think about repeated failures. A customer may reasonably want a right to terminate if you miss key service levels several months in a row. That can be a better outcome than an open-ended damages claim, as long as the trigger is clear and fair.

Key Takeaways

• A service level agreement template is a starting point, not a finished contract for your IT support business.
• Your SLA should sit alongside your managed service agreement or IT support contract, with each document doing a different job.
• Response times, resolution targets and uptime promises need clear definitions, exclusions and measurement rules.
• Customer dependencies matter. If a customer doesn't provide access, approvals, licences or safe systems, your SLA should say what happens.
• Security incidents need separate wording that lines up with UK GDPR, the Data Protection Act 2018 and your breach response process.
• Service credits can be a sensible remedy, but they should be capped and tied to the affected service.

If you'd like help with your IT support SLA, managed service agreement, data protection clauses or service credit wording, you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.