Service Level Agreement Template For SaaS Support

What should you promise in your SaaS support SLA without accidentally promising the world?

The reassuring answer is that your service levels can be clear, commercially attractive and still sensible for your business. You don't need to guarantee perfection. You need to define what you'll measure, when the promise applies, what happens if you miss it, and what sits outside your control.

For SaaS businesses, a well-drafted service level agreement is less about legal jargon and more about expectation-setting. It helps your customers understand your uptime, support response times, maintenance windows, security incident process and remedies if something goes wrong.

Do You Need A Service Level Agreement For SaaS Support?

Yes, you usually need a service level agreement if your SaaS product is business-critical to your customers or you're making promises about uptime or support.

Your SLA can sit as a schedule to your SaaS terms, broader service agreement, master services agreement or software support agreement. It doesn't always need to be a standalone contract. What matters is that it works together with your main terms, especially your payment terms, acceptable use rules, privacy policy, IP ownership, liability limits and termination rights.

An SLA is especially useful if your customers rely on your software for things like:

• customer bookings or payments
• staff rostering or payroll inputs
• inventory, logistics or operations
• client communications
• reporting, analytics or compliance records

If you sell to larger customers, you'll often be asked for an uptime service level agreement before procurement signs off. If you sell to smaller customers, a simple and well-explained SLA can reduce back-and-forth because everyone can see what support they get.

Be careful with copying a generic service level agreement template from overseas. Australian law can affect how your clauses work, particularly under the Australian Consumer Law, the unfair contract terms regime and the Privacy Act 1988 if you're handling personal information.

For example, you can't simply say your business has no responsibility at all if the law gives your customer rights that can't be excluded. In some cases, your customer may be a consumer under the Australian Consumer Law, including some business customers where the goods or services supplied are priced at $100,000 or less or otherwise meet the legal test.

What Should Your SaaS SLA Actually Measure?

Your SaaS SLA should measure things your team can track objectively, not broad promises like best support or always available.

Good service levels are specific enough that both sides can tell whether you've met them. If the metric needs a debate every time, it's probably not drafted clearly enough.

For SaaS support, common metrics include:

• Availability: the percentage of time the hosted service is available during a measurement period.
• Support response time: how quickly you acknowledge or start working on a support request.
• Resolution target: how quickly you aim to fix or provide a workaround, if you want to include this.
• Incident updates: how often you'll update the customer during a major outage or security incident.
• Maintenance notice: how much notice you'll give before planned downtime.

Try to avoid promising resolution times unless your team can control the fix. For many SaaS products, the time to resolve a problem can depend on third-party hosting, payment providers, customer configuration, integrations or the customer's own network.

A safer approach is often to promise response times and update intervals, then say you'll use reasonable efforts to resolve the issue or provide a workaround.

Example: Measuring A P1 Incident

Say Maya runs a Sydney-based SaaS platform that helps allied health clinics take online bookings. Her largest customer asks for 24/7 support with a 15-minute fix time for any issue.

That sounds great for the customer, but it's risky if Maya's team can't guarantee it. A more workable SLA might say:

• a P1 issue means the production platform is unavailable for all users
• support will respond within 30 minutes, 24/7
• updates will be provided every 60 minutes until service is restored
• Maya's team will use reasonable efforts to restore service as soon as practicable

That gives the customer a serious support commitment without turning every outage into an automatic breach of contract.

How Do You Set Uptime, Maintenance Windows And Exclusions?

You set uptime properly by defining the percentage, the measurement period, what counts as downtime and what doesn't count.

A common starting point for SaaS is monthly uptime, such as 99.5%, 99.9% or 99.95%. The higher the number, the harder and more expensive it's to meet. Before you agree to a figure, check whether your infrastructure, monitoring tools and support coverage can actually back it up.

Here's what those numbers can mean in practice for a 30-day month:

• 99.5% uptime: up to 216 minutes of downtime in the month.
• 99.9% uptime: up to 43.2 minutes of downtime in the month.
• 99.95% uptime: up to 21.6 minutes of downtime in the month.

Your SLA should say whether uptime is measured across the whole platform, a specific production environment, core features only or each customer's account. If you don't define this, a customer may argue that a minor feature issue counts as platform downtime.

Planned Maintenance

Your SLA should exclude planned maintenance from downtime if you give the required notice and schedule it in the agreed maintenance window.

For example, you might say planned maintenance can occur between 10:00 pm and 2:00 am AEST on Sundays, with at least 48 hours' notice, except for urgent security patches. If your customers operate nationally or globally, think carefully about time zones and peak usage times.

Common Exclusions

Your uptime promise should usually exclude downtime caused by:

• planned maintenance carried out under the SLA
• emergency maintenance needed to protect the platform
• the customer's internet connection, hardware or local systems
• third-party services outside your reasonable control
• the customer's misuse, unauthorised changes or breach of your acceptable use policy
• beta features, sandbox environments or free trials, if you don't want the SLA to apply to them

Keep these exclusions fair and reasonable. Since unfair contract terms can attract penalties in Australia, especially for standard form small business contracts, one-sided clauses that let you avoid responsibility too broadly can create legal risk.

How Should Support Response Categories Work?

Support categories should match the business impact of the issue, not just the customer's level of frustration.

This is where many SaaS SLAs become messy. If every bug is labelled urgent, your team loses the ability to prioritise genuine outages. A clear severity table helps your support team and your customer speak the same language.

You might use categories like these:

• Priority 1: the production service is unavailable or a critical function is unusable for all or most users.
• Priority 2: a major function is impaired, but the customer can still use the service with a workaround.
• Priority 3: a non-critical bug affects limited functionality or a small group of users.
• Priority 4: general questions, feature requests, training requests or cosmetic issues.

Then attach realistic response targets. For example:

• P1: response within 30 minutes, updates every 60 minutes
• P2: response within 4 business hours, updates each business day
• P3: response within 1 business day
• P4: response within 2 business days

These numbers are just examples. Your targets should reflect your team size, customer plan tiers and whether you offer after-hours support.

Be precise about the difference between a response and a resolution. A response usually means your team has acknowledged the request and started triaging it. A resolution means the issue is fixed, worked around or otherwise closed. If your SLA doesn't define this, customers may expect a full fix within the response time.

You can also link support levels to plan types. For example, enterprise customers may get 24/7 P1 support, while standard customers get business hours support. That's fine, as long as your sales material and contract terms say the same thing.

Can You Offer Service Credits Without Taking On Unlimited Liability?

Yes, you can offer service credits as the customer's remedy for missed service levels, but the clause needs to be drafted carefully.

Service credits are usually a credit against future fees, not a cash refund. They can be a practical middle ground. Your customer gets a meaningful remedy if you miss your uptime target, while your business avoids open-ended claims for every disruption.

A service credit clause should cover:

• when a credit is available
• how the credit is calculated
• the maximum credit for each month
• how and when the customer must request the credit
• whether credits are the customer's sole remedy for the service level failure
• what happens if the customer has unpaid invoices

Worked Example: Uptime Credit

Say your SLA promises 99.9% monthly uptime for a customer paying $2,000 per month. In a 30-day month, that allows about 43.2 minutes of downtime.

If the platform has 90 minutes of unplanned downtime that counts under the SLA, you've missed the target. Your credit structure might say:

• uptime below 99.9% but at least 99.0% gives a 10% credit
• uptime below 99.0% but at least 95.0% gives a 25% credit
• uptime below 95.0% gives a 50% credit

On those numbers, the customer receives a 10% credit, which is $200 against a future invoice.

You'd usually also include a monthly cap, so the total credits can't exceed a set percentage of the monthly fees for the affected service. This helps you avoid a situation where one outage creates disproportionate financial exposure.

That said, don't assume a service credit clause solves everything. Under the Australian Consumer Law, some guarantees and remedies can't be excluded. Liability caps and exclusive remedy clauses also need to be considered carefully, especially for standard form contracts with small business customers.

What Should Your Service Level Agreement Template Include?

Your service level agreement template should include the operational details your team can follow and the legal limits your business needs.

The outline below isn't a finished legal document, and it should be tailored before you use it. A template often misses the practical details that make an SLA work for a real SaaS product, such as your support hours, hosting setup, customer plans, support and maintenance process and incident process.

1. Parties And Related Agreement: identify your business, the customer and the main SaaS terms or software support agreement the SLA attaches to.
2. Service Description: describe the production SaaS service covered by the SLA and any excluded features, trials or beta tools.
3. Availability Commitment: state the uptime percentage, measurement period and monitoring method.
4. Downtime Calculation: define downtime and explain how availability is calculated.
5. Maintenance Windows: set out planned maintenance times, notice periods and urgent maintenance rules.
6. Support Channels: list approved support channels, such as email, ticket portal or phone for certain plans.
7. Severity Levels: define P1 to P4 or your preferred categories based on business impact.
8. Response Targets: set response times, update intervals and any business hours limits.
9. Customer Responsibilities: require the customer to provide enough information, cooperate with troubleshooting and maintain their own systems.
10. Exclusions: list events outside the SLA, including customer-side issues, third-party outages and misuse.
11. Service Credits: explain eligibility, calculation, caps, claim process and whether credits apply to future fees only.
12. Security Incidents: describe how you'll assess, contain and communicate security incidents affecting the service.
13. Privacy And Data Breach Process: align the SLA with your Privacy Act 1988 obligations, including the Notifiable Data Breaches scheme if it applies.
14. Liability And Legal Carve-Outs: connect the SLA with your liability cap and make sure you don't exclude rights that can't legally be excluded.
15. Changes To The SLA: explain how updates can be made and when customers will be notified.

Security incidents deserve their own clause. Not every security event is an eligible data breach, but you should still have a process for triage, containment, investigation and customer updates. If the Notifiable Data Breaches scheme applies and there's an eligible data breach, affected individuals and the Office of the Australian Information Commissioner may need to be notified as soon as practicable after the required assessment.

Make sure your SLA lines up with what your website, proposals and sales team are saying. If your sales deck promises 24/7 support but your contract says business hours only, that mismatch can cause disputes and unhappy customers.

Key Takeaways

• A SaaS SLA should measure clear things like uptime, response times, update intervals and maintenance notice.
• Define downtime carefully, including exclusions for planned maintenance, customer-side issues and third-party services outside your control.
• Use support categories based on business impact so your team can prioritise serious incidents properly.
• Service credits can be a useful remedy, but they should include claim rules, caps and a clear calculation method.
• Your SLA needs to work with Australian law, including the Australian Consumer Law, unfair contract terms rules and the Privacy Act 1988 where personal information is involved.
• A template is a helpful starting point, but your SLA should be tailored to your product, infrastructure, support model and customer base.

If you'd like help with your SaaS service levels, software support terms, service credit clauses or privacy and security incident wording, you can reach us at 1800 730 617 or team@sprintlaw.com.au for a free, no-obligations chat.