Service Level Agreement Template For IT Providers

Yes, an IT support or managed services provider should usually have a service level agreement template ready to tailor for each client.

The nuance is that an SLA is only useful if it matches how your support desk actually works. If you promise 24/7 urgent support, 99.99% uptime and automatic credits, but your team is really set up for business-hours support, the document can create more risk than protection.

A good SLA gives your client confidence while keeping expectations realistic. It sets out what you support, when you support it, how quickly you respond, what happens if you miss a target, and what sits outside the deal.

Do You Need A Service Level Agreement Template For IT Support?

Yes, you should have an SLA template if your business provides IT support, cloud support, managed services, cybersecurity monitoring, hosting, help desk support or similar services.

Your SLA is the part of your contract that turns broad promises like we provide support into practical rules your team and your client can follow. It helps avoid the awkward gap between what the client thought they were buying and what you actually priced.

For example, a client might expect an urgent response within 15 minutes whenever their printer fails. You might see printer faults as a low-priority request with a next-business-day response. If that difference isn't written down, a small ticket can quickly become a relationship problem.

An SLA is especially useful where you offer:

• monthly managed IT services
• remote help desk support
• network monitoring
• server, cloud or software support
• cybersecurity response services
• backup and disaster recovery services
• hosting, uptime or availability commitments

In New Zealand, you also need to make sure your SLA doesn't overpromise or mislead clients. The Fair Trading Act 1986 can apply if your marketing or contract statements create a false impression about your service. The Consumer Guarantees Act 1993 may also be relevant for some services, although business-to-business contracts can often contract out of it where the legal requirements are met and it's fair and reasonable.

The practical point is simple: don't copy a generic SLA and hope it fits. Templates often miss key details, and your SLA should be tailored before you use it with real clients.

What Should A Service Level Agreement Template Include?

A service level agreement template should include the services covered, support hours, priority levels, response targets, uptime commitments, exclusions, remedies and escalation process.

Think of it as your operating manual for client expectations. It should be clear enough that your support team can apply it while handling tickets, not just something that sits in a drawer after onboarding.

Here is a practical fill-in outline you can use as a starting point. This isn't a finished legal document, but it shows the main sections your tailored SLA should deal with.

1. Parties And Background: Name your business, the client and the service package the SLA applies to.
2. Service Scope: List the systems, devices, software, users, locations or environments you support.
3. Support Hours: State your normal support hours, after-hours options and public holiday rules.
4. Support Channels: Explain whether requests must be logged through a portal, email, phone number or monitoring alert.
5. Priority Levels: Define each severity level, such as critical outage, major issue, standard request and minor request.
6. Response Targets: Set the time for acknowledging and starting work on each priority level.
7. Resolution Or Workaround Targets: Include realistic targets if you offer them, or explain when you can't guarantee a fix time.
8. Uptime Or Availability: State the percentage target, measurement period and systems included.
9. Scheduled Maintenance: Set notice rules for maintenance services and explain whether maintenance time is excluded from uptime calculations.
10. Client Responsibilities: Require access, accurate information, supported hardware, licence compliance and timely approvals.
11. Exclusions: Exclude issues caused by third parties, unsupported systems, client changes, outages outside your control and force majeure events.
12. Service Credits Or Remedies: Explain what the client receives if you miss a service level, and whether that remedy is capped.
13. Escalation Process: Set out who gets involved, when and how issues are reviewed.
14. Reporting And Review: Explain service reports, ticket reviews and when the SLA can be updated.

If you also collect, access or store personal information while providing support, your SLA should work with your privacy and security terms. Under the Privacy Act 2020, your client may need to respond quickly if there's a notifiable privacy breach, so your contract should say how you'll notify them and cooperate.

How Do You Set Realistic Response Times And Uptime Targets?

You set realistic response times and uptime targets by matching them to your staffing, tools, service package and the systems you actually control.

A common trap is promising a resolution time when you can only control your first response. If a client's internet provider is down, or a software vendor needs to patch a bug, you may be able to respond quickly but not fix the underlying issue yourself.

Response Time Versus Resolution Time

Your SLA should clearly separate these two concepts:

• Response time: how quickly you acknowledge the issue and start triaging it.
• Resolution time: how quickly the issue is fixed or a workaround is provided.

For many IT providers, response targets are safer and more practical than fixed resolution guarantees. If you do offer resolution targets, make them conditional on things like client cooperation, third-party vendor response times and the issue being within your control.

Priority Levels That Actually Work

A simple priority model might look like this:

• Priority 1 - Critical: full business outage, no practical workaround, major security incident or core system unavailable.
• Priority 2 - High: major function impaired, multiple users affected, workaround available but limited.
• Priority 3 - Standard: one user or non-critical function affected, normal work can continue.
• Priority 4 - Low: general request, minor issue, change request or how-to question.

You can then attach targets. For example, Priority 1 might have a 30-minute response during support hours, while Priority 3 might have a 4-business-hour response. The right numbers depend on your team and pricing.

Uptime Targets In Real Numbers

Uptime targets can sound impressive, but the maths matters. In a 30-day month, 99.5% uptime allows about 3 hours and 36 minutes of downtime. 99.9% uptime allows about 43 minutes of downtime.

If you can't monitor and prove availability, be careful about offering an uptime guarantee. Your SLA should also say what counts as downtime, how it's measured and what doesn't count, such as scheduled maintenance, client-side network faults or cloud provider outages outside your control.

What Remedies Should You Offer If You Miss A Service Level?

Your remedy should be commercially sensible, clearly capped and tied to the specific service level you missed.

The most common remedy in an SLA is a service credit. This is usually a credit against future fees, not a cash refund. For example, if monthly support fees are $2,000 plus GST and you miss the agreed uptime target for that month, the SLA might give the client a 5% credit on that month's recurring fee. That would be a $100 plus GST credit.

The key is to make the credit meaningful without turning one missed target into an unlimited financial exposure. Your SLA should say:

• which failures trigger a credit
• how the credit is calculated
• whether the client needs to request it within a certain period
• the maximum credit available for a month
• whether credits are the client's sole remedy for that SLA failure
• whether credits apply if the client is overdue on invoices

Be careful with automatic penalties. A penalty that doesn't reflect a genuine commercial allocation of risk can cause problems, and very harsh remedies can also create tension with your limitation of liability clause.

You should also avoid promising remedies that conflict with rights the client may have under New Zealand law. If you're contracting with another business for business purposes, you may be able to contract out of parts of the Consumer Guarantees Act 1993, but this needs to be in writing and fair and reasonable. Your terms also still need to comply with the Fair Trading Act 1986, including rules around misleading conduct and unfair contract terms.

Remedies aren't only about money. For some managed services, a better outcome is a clear escalation meeting, root cause analysis, action plan or service review. That can be more useful than a small credit and can help preserve the client relationship.

What Exclusions And Client Responsibilities Should Your SLA Include?

Your SLA should include exclusions and client responsibilities so you aren't held responsible for issues you didn't cause and can't control.

This is one of the most important parts of an IT support service agreement, especially if your client uses a mix of old devices, third-party apps, home networks, cloud platforms and staff-owned equipment.

Common exclusions include:

• outages caused by internet service providers, cloud providers or software vendors
• systems, devices or software not listed in the service scope
• client changes made without your approval
• failure to install recommended updates or security patches
• hardware that's no longer supported by the manufacturer
• issues caused by malware where the client ignored security requirements
• data loss where the client declined your backup recommendations
• scheduled maintenance windows
• force majeure events outside your reasonable control

Your client responsibilities should be just as clear. You might require the client to:

• provide timely access to systems, premises, credentials and key staff
• keep software licences current
• use supported operating systems and hardware
• follow your cybersecurity policies, such as multi-factor authentication
• log tickets through the agreed support channel
• give accurate information when reporting issues
• approve work, purchases or vendor support requests promptly

Say Aria runs a managed IT provider in Wellington. One of her clients refuses to replace an end-of-life server but still expects full uptime support. Aria's SLA says unsupported hardware is excluded from uptime credits, and her support agreement records that the client declined the recommended upgrade.

When the server fails for 6 hours, Aria still helps with recovery. But because the SLA clearly excludes unsupported hardware from uptime credits, the client can't fairly claim a credit for a risk they chose to keep.

This is exactly the kind of practical protection a managed services contract in New Zealand should give you.

How Does An SLA Fit With Your Managed Services Contract?

An SLA should usually sit inside, or alongside, your main managed services contract rather than replacing it.

Your SLA deals with service levels. Your main service agreement deals with the broader commercial and legal terms of the relationship. If you only have an SLA, you may be missing important protections around payment, scope changes, liability, intellectual property, privacy and termination.

Your managed services contract, IT services agreement or IT support service agreement should usually cover:

• the services and onboarding process
• fees, invoicing, GST and payment timing
• minimum terms, renewals and termination rights
• changes to scope, service packages and pricing
• client obligations and acceptable use rules
• confidentiality and information security
• Privacy Act 2020 obligations and breach notification steps
• ownership of documentation, scripts, configurations and materials
• third-party products, licences and vendor terms
• liability caps and exclusions
• subcontractors and remote access arrangements
• how service levels are reviewed and updated

Make sure the documents don't contradict each other. For example, if your main contract says support is available 8.30am to 5.00pm on business days, your SLA shouldn't promise 24/7 Priority 1 support unless that's genuinely part of the package.

You should also decide which document wins if there's a conflict. Many providers say the main contract controls legal and commercial terms, while the SLA controls operational service level details. The right drafting depends on how your packages are structured.

If you're dealing with larger clients, they may ask you to use their own supplier terms. Read these carefully before signing. They may include uncapped liability, strict indemnities, unlimited security obligations or service credits that don't match your pricing.

How Should You Handle Escalation And Reviews?

You should handle escalation and reviews through a clear step-by-step process, so serious issues don't get stuck in the ticket queue.

An escalation process doesn't need to be complicated. It just needs to tell everyone what happens when an issue becomes urgent, isn't progressing or needs a business decision.

A practical escalation process might include:

1. Ticket Logged: The client submits the issue through the agreed channel and receives a ticket number.
2. Initial Triage: Your team assigns a priority level based on the SLA definitions.
3. Technical Escalation: If the issue can't be resolved at first level support, it moves to a senior technician or specialist.
4. Client Contact Escalation: If you need approvals, access or a decision, the issue goes to the client's nominated contact.
5. Management Escalation: If a target is missed or the issue is business-critical, your account manager or service lead becomes involved.
6. Post-Incident Review: For major incidents, you provide a short summary of the cause, impact, steps taken and future actions.

Your SLA should also explain how often you'll review service levels. For monthly managed services, you might include quarterly service reviews. For smaller clients, an annual review may be enough.

Reviews are a good time to check whether the SLA still matches the client's environment. If they've doubled their staff, added new sites or moved key systems to the cloud, the original support package may no longer fit.

Keep records of major incidents, credits, review meetings and agreed changes. Without a written record, you may struggle to show what was agreed if expectations drift over time.

Key Takeaways

• A service level agreement template is useful, but it should be tailored to your services, team capacity and client package before you use it.
• Your SLA should clearly cover support hours, priority levels, response targets, uptime, exclusions, remedies and escalation steps.
• Be careful with uptime guarantees and fixed resolution times unless you can control, monitor and prove them.
• Service credits should be clear, capped and consistent with your wider liability position.
• Your SLA should work with your managed services contract, privacy terms and main commercial terms, not replace them.
• Clear exclusions and client responsibilities help protect you when issues are caused by unsupported systems, third-party outages or client decisions.

If you'd like help with tailoring your service level agreement, setting realistic support terms, preparing your managed services contract or reviewing your privacy and data security clauses, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.