What Should Your SaaS SLA Promise?

Priya runs a growing New Zealand SaaS platform for appointment bookings. A larger customer is ready to sign, but they send back one big request: they want 99.99% uptime, 24/7 phone support and a refund if anything goes wrong.

That can feel like a compliment and a red flag at the same time. Your product is being taken seriously, but one overconfident service promise can turn a normal outage into a contract problem.

The good news is that your SaaS service level agreement in NZ doesn't need to promise perfection. It needs to be clear, realistic and fair, so customers know what to expect and you don't accidentally take responsibility for outages outside your control.

What Is A SaaS Service Level Agreement?

A SaaS service level agreement, often called an SLA, is the part of your customer contract that explains what level of service you aim to provide and what happens if you don't meet it.

For most SaaS businesses, your SLA sits inside your SaaS terms and conditions, IT services agreement, master services agreement or enterprise customer agreement. It usually covers:

• Availability: when your platform should be accessible to customers.
• Uptime: the percentage of time your system should be available over a set period.
• Support: how customers can contact you and how quickly you'll respond.
• Maintenance: when you can take the system offline for planned updates.
• Exclusions: events that don't count against your uptime commitment.
• Service credits: the credit a customer may receive if you miss the agreed service level.

An SLA is different from a general promise that your software will work well. It's more precise. If you say 99.9% uptime measured monthly, you need to know what that actually means, how you'll measure it and what remedy applies if you miss it.

This is where many early SaaS contracts become risky. A template might say your service will be available at all times, without explaining maintenance windows, third-party outages or customer-side issues. Documents work best when they match how your product actually runs.

What Uptime Should You Promise Customers?

It depends on your product, infrastructure and customer base, but you should only promise an uptime level you can comfortably support and measure.

Uptime is usually expressed as a percentage over a month, quarter or year. A higher percentage sounds better, but it leaves you less room for ordinary incidents.

Using a 30-day month as a guide:

• 99% uptime allows 7 hours and 12 minutes of downtime per month.
• 99.5% uptime allows 3 hours and 36 minutes of downtime per month.
• 99.9% uptime allows 43 minutes and 12 seconds of downtime per month.
• 99.95% uptime allows 21 minutes and 36 seconds of downtime per month.

For a small but serious SaaS business, 99.5% or 99.9% monthly availability may be more realistic than 99.99%, especially if you rely on third-party hosting, payment gateways, messaging tools or external APIs.

Choose The Right Measurement Period

A monthly uptime commitment is common because customers get a clear reporting period. A quarterly or annual period gives you more flexibility, but customers may see it as less responsive.

If your customers use your platform for business-critical work, they may expect monthly measurement. If your platform is helpful but not mission-critical, a quarterly target might be easier to manage.

Define What Counts As Downtime

Your software uptime commitment should say exactly what downtime means. For example, you might define downtime as a complete inability to access the production application, measured from your monitoring tools.

You might exclude:

• slow performance that doesn't prevent use of the core service
• issues affecting only one feature, unless that feature is central to the plan
• problems caused by the customer's internet connection, device or browser
• customer misconfiguration or unauthorised changes
• planned maintenance and emergency maintenance

If you don't define downtime, customers may treat every bug, delay or third-party interruption as a breach of the SLA.

What Should Your SaaS SLA Clause Cover?

Your SaaS SLA clause should cover the service level, measurement method, support process, maintenance rights, exclusions and the customer's remedy if you miss the target.

A practical SLA clause usually deals with the following points.

1. The Covered Service

Be specific about which part of your product is covered. Is it the main web app, mobile app, API, admin portal or all of them?

If some features are beta, experimental or dependent on third parties, say so. You may decide that beta features aren't covered by the SLA at all.

2. The Uptime Target

State the percentage and the measurement period. For example, you might promise 99.9% availability of the production platform in each calendar month.

Avoid saying the service will be available 24/7 without any qualification. That can sound like a guarantee of uninterrupted service, which is rarely realistic.

3. Scheduled Maintenance

Your SLA should give you the right to perform maintenance. You might say scheduled maintenance is excluded from downtime if you give reasonable notice, such as 48 hours, unless urgent maintenance is needed to protect security or stability.

If your customers are in different time zones, think carefully about when maintenance windows will happen.

4. Support Hours And Response Times

Support commitments should match your team and pricing. For example:

• Standard support: email support from 9am to 5pm New Zealand time on business days, with an initial response within 1 business day.
• Priority support: faster response times for higher-tier plans.
• Critical incident support: faster triage where the platform is unavailable for all users.

Be careful with words like fix, resolve or immediately. A response time is much easier to promise than a resolution time, because the actual fix may depend on diagnosis, customer information or a third-party provider.

5. Customer Responsibilities

Your customer should also have responsibilities. For example, they may need to:

• use the software within published limits
• keep login details secure
• maintain compatible browsers and systems
• give you enough information to investigate an incident
• avoid using the service in a way that overloads or disrupts it

This helps stop an SLA from becoming a one-way promise where you carry every technical risk.

Should You Offer Service Credits In A SaaS Contract?

Yes, service credits can be useful, but they should be carefully limited and tied to the fees the customer actually pays.

A service credit is usually a credit against future invoices, not a cash refund. It gives the customer a fair remedy if you miss the SLA, while helping you avoid open-ended liability for every outage.

For example, your SLA might say:

• if monthly availability falls below 99.9%, the customer receives a credit equal to 5% of that month's subscription fee
• if it falls below 99%, the credit increases to 10%
• the total credit for any month is capped at 25% of the monthly fee
• the customer must request the credit within 30 days after the end of the affected month
• the credit is the customer's sole remedy for failing to meet the uptime commitment

The exact numbers should match your pricing, margins and customer risk. A $99 per month self-serve plan shouldn't carry the same service credit structure as a $20,000 per year enterprise contract.

Example: A Sensible Service Credit Structure

Say Hana runs a Wellington SaaS platform that helps gyms manage memberships. Her standard plan costs $300 per month. She offers 99.5% monthly availability and gives a 10% credit if availability drops below that level, capped at one month's fees per year.

That gives customers confidence that Hana takes reliability seriously, but it doesn't turn a short outage into a major financial exposure. For larger customers, she can negotiate higher support levels in a separate order form.

If you use service credits, make the claim process simple but controlled. Ask customers to notify you within a set period, include the date and time of the outage and explain how it affected their use of the service.

How Do New Zealand Laws Affect Your SaaS Terms?

New Zealand law doesn't set one standard uptime percentage for SaaS contracts, but your promises still need to be accurate, fair and backed by your actual service capability.

The Fair Trading Act 1986 matters because you must not mislead customers about your software, support or reliability. If your website says 99.99% uptime, enterprise-grade security or 24/7 support, your contract and operations need to support those claims.

The Fair Trading Act also restricts unfair contract terms in standard form consumer contracts and small trade contracts. For SaaS businesses, this can matter if you use standard online customer contracts with small business customers. Terms that let you change key service promises whenever you like, avoid all responsibility or impose one-sided penalties can attract scrutiny.

The Consumer Guarantees Act 1993 can also be relevant. If you supply services to consumers, statutory guarantees may apply. For business customers acquiring services in trade, you can sometimes contract out of the Consumer Guarantees Act, but only if both parties are in trade, the agreement is in writing and the contracting out is fair and reasonable.

The Privacy Act 2020 is another key piece for many SaaS products. If you handle personal information, your availability and support promises should sit alongside privacy and security obligations. If a privacy breach has caused serious harm or is likely to do so, you'll generally need to notify the Office of the Privacy Commissioner as soon as practicable and notify affected individuals, unless an exception or permitted delay applies.

Your SaaS terms and conditions should work together as a whole. The SLA should line up with your privacy terms, acceptable use rules, limitation of liability, data backup wording, suspension rights and termination rights. If those clauses conflict, customers may push back or misunderstand what you've promised.

Common Mistakes To Avoid

The easiest mistake is promising more than your current systems, people and suppliers can actually deliver.

Watch out for these common issues:

• Promising 100% uptime: even major platforms avoid absolute uptime promises.
• Forgetting third-party dependencies: hosting, payment, email, SMS and AI tools can all fail outside your control.
• Offering 24/7 support without a 24/7 team: customers will expect real coverage, not a mailbox you check the next morning.
• Not excluding scheduled maintenance: routine updates can accidentally count as downtime.
• Giving refunds instead of credits: refunds can create cashflow strain and may go beyond what you intended.
• Leaving service credits uncapped: a cap helps keep the remedy proportionate to the subscription fee.
• Using different promises in different places: your website, proposal, order form and terms should all say the same thing.

It's also worth reviewing your SLA as your product grows. A promise that worked for your first 20 customers may not suit enterprise customers, regulated industries or international users.

Key Takeaways

• Your SLA should promise realistic reliability, not perfection.
• Define uptime, downtime, maintenance and exclusions clearly so everyone knows what counts.
• Service credits can be a fair remedy, but they should be capped and linked to subscription fees.
• Your support promises should match your team, hours and pricing model.
• New Zealand laws like the Fair Trading Act 1986, Consumer Guarantees Act 1993 and Privacy Act 2020 can shape how your SaaS terms are drafted.
• Your SLA should fit neatly with the rest of your SaaS terms, privacy wording and liability limits.

If you'd like help with your SaaS customer terms, uptime and support clauses, service credit wording or privacy and data obligations, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.