Support and Maintenance Agreements in New Zealand

A support and maintenance agreement is often signed quickly, right after software is purchased, implemented, or handed over. That is where businesses get caught. Common mistakes include assuming "support" means unlimited help desk access, relying on a sales promise instead of the contract wording, and missing the gap between a bug fix and a new feature request. Another frequent problem is signing the provider's standard terms without checking service levels, response times, or what happens if the system goes down during business hours.

If your business depends on software, cloud systems, websites, apps, POS systems, integrations, or managed IT services, this agreement matters more than many founders expect. It decides what the provider must actually do after go-live, how quickly they must respond, what is excluded, and who carries the risk when something breaks. This guide explains what a support and maintenance agreement means in New Zealand, the legal issues to check before you sign, and the mistakes SMEs commonly make when they accept standard terms too fast.

Overview

A support and maintenance agreement sets the rules for ongoing technical support, updates, bug fixes, monitoring, and system upkeep after a product or service has been delivered. In New Zealand, the contract usually works alongside wider contract law principles and may sit in the background of statutory obligations, including under the Consumer Guarantees Act in some business-to-consumer situations and the Fair Trading Act when service claims are marketed.

Define exactly what support services are included, such as help desk access, remote troubleshooting, on-site visits, monitoring, patches, and updates.
Check the service levels, including support hours, response times, resolution targets, severity levels, and any planned maintenance windows.
Separate bug fixes from upgrades, enhancements, change requests, and third party issues.
Confirm fees, overage charges, annual increases, and what triggers additional work charges.
Review liability limits, warranty wording, exclusions, and how data loss, downtime, and indirect loss are treated.
Make sure privacy, confidentiality, security responsibilities, and access rights are clearly allocated.
Check the term, renewal process, termination rights, and what handover help is available when the relationship ends.

What Support and Maintenance Agreement Means For New Zealand Businesses

A support and maintenance agreement is the contract that keeps your system usable after delivery, not a vague promise that the provider will "help if anything comes up".

For many New Zealand businesses, the agreement sits behind core operations. That might be an ecommerce platform, booking system, payroll integration, field service app, CRM, membership portal, or internal business software. If the system slows down, fails, or becomes insecure, the commercial cost can be immediate.

The contract should say what the provider is maintaining, what support channels are available, when support can be accessed, and what standard of service applies. Without that detail, it is hard to prove whether the provider has fallen short.

What the agreement usually covers

The scope varies, but most support and maintenance agreements deal with ongoing operational support rather than major redevelopment. A well-drafted contract often includes:

incident logging and help desk support
bug diagnosis and bug fixes
software patches and security updates
performance monitoring
backup or disaster recovery support, where relevant
scheduled maintenance
access to technical documentation
escalation procedures
reporting on service issues or outages

It may also cover hardware support, managed services, hosting support, or third party software coordination. That needs to be spelled out. A provider may support only its own product and exclude problems caused by hosting services, APIs, plugins, user error, or unauthorised changes.

What it usually does not cover

The main trap is assuming maintenance includes development work. It often does not.

Contracts commonly exclude:

new features or functionality
customisation work outside the original scope
training beyond a set allowance
issues caused by your staff, contractors, or third party vendors
problems arising from unsupported operating systems or browsers
on-site work unless specifically booked
data correction where the issue comes from incorrect business input

This distinction matters before you approve a quote or dispute an invoice. A provider may classify your request as a change request, even if your team sees it as fixing something that should already work.

Why the New Zealand context matters

In New Zealand, business contracts generally have wide room to set commercial terms, but the drafting still matters because the starting point is what the parties actually agreed. If the provider made broad claims about uptime, response times, integration capability, or support availability before you signed, those statements may also matter, especially if they were misleading.

The Fair Trading Act can affect how services are advertised and described. If a provider markets premium support, 24/7 coverage, or guaranteed response standards, those claims should match the contract and the real service model.

Where services are supplied to consumers, the Consumer Guarantees Act can impose minimum standards that cannot simply be contracted away. In business-to-business arrangements, parties sometimes agree to contract out of parts of that regime where the law allows and the contracting requirements are met. Whether that is effective depends on the facts and the wording, so it is worth checking before you sign.

Privacy is also a live issue. If the provider accesses customer records, staff information, health information, or account data while performing support, the Privacy Act 2020 may affect how personal information is handled, secured, and disclosed.

Legal Issues To Check Before You Sign

The most useful version of this contract is specific, measurable, and honest about what happens when things go wrong.

Before you sign a contract, focus on the parts that decide performance, risk, and exit. Founders often spend time on price and miss the clauses that matter most once the system is live.

1. Scope of services

The scope should identify the systems, software versions, modules, environments, and devices covered. If you have a customised platform, make sure the contract states whether custom code is included.

Check whether the agreement includes:

business hours support only, or after-hours support
phone, email, portal, or chat support
remote support only, or on-site attendance
preventive maintenance as well as reactive support
support for integrations and third party tools
test environment support as well as production environment support

General wording creates arguments later. Specific wording prevents them.

2. Service levels and response times

If uptime or system responsiveness matters to your business, service levels should not be an afterthought.

Look for a clear service level schedule covering:

how incidents are prioritised, such as critical, high, medium, and low
how quickly the provider must acknowledge a ticket
target times to start work
target times to restore service or provide a workaround
planned maintenance windows and notice periods
service credits or other consequences if standards are missed

A response time is not the same as a fix time. Businesses often discover this only after a major outage, when the provider responds within 30 minutes but takes three days to resolve the issue.

3. Fees and extra charges

The pricing model needs to match the way your business actually uses support.

Check whether fees are:

fixed monthly or annual fees
based on user numbers, devices, tickets, or environments
subject to annual review or automatic increases
different for standard hours and after-hours work
different for support versus project or development work

Ask what falls outside the recurring fee. If the agreement says extra work is charged at the provider's current rates, make sure those rates are identified or tied to a method for setting them.

4. Warranties and disclaimers

The provider will usually give limited warranties and broad exclusions. That is normal, but the wording should still be tested against your risk.

Some agreements promise that services will be performed with reasonable care and skill. Others go further and warrant that software will materially conform to specification. Many then narrow those promises through exceptions.

Watch for disclaimers saying the provider does not guarantee uninterrupted or error-free operation, is not responsible for third party products, or is not liable where you failed to follow instructions. These may be commercially acceptable, but they should not hollow out the whole deal.

5. Liability and indemnities

This is where founders often get caught. A low contract fee does not mean the business impact of failure is low.

Review:

the liability cap, and whether it is tied to fees paid in a short period such as 12 months
whether different caps apply to confidentiality breaches, privacy breaches, or intellectual property infringement
whether indirect or consequential loss is excluded
whether data loss, corruption, or cyber incidents are specifically addressed
any indemnity you must give the provider, especially for customer content, instructions, or third party claims

If your operations depend heavily on the system, a liability cap set at one month's fee may be too low to reflect the real risk.

6. Data access, privacy, and security

If the provider can access your live systems, they may also access personal information, commercially sensitive data, or confidential records.

The agreement should deal with:

who can access your data and for what purpose
security measures expected of the provider
whether subcontractors are used
where data is stored or accessed from
notification steps for security incidents or privacy breaches
return, deletion, or retention of data on exit

Do not assume a short support contract can ignore privacy. If support personnel log into customer-facing systems or internal databases, privacy and confidentiality terms matter, and a separate data processing schedule may also be needed.

7. Intellectual property and access rights

Support work can create documentation, scripts, patches, or configuration changes. The contract should say who owns those outputs and what rights each party has to use them.

This is especially relevant where the provider maintains custom software built for your business. You do not want a dispute later over whether you can continue using modified code or move to another support provider.

8. Term, renewal, and termination

You need an exit route before the relationship becomes difficult.

Check:

the initial term and whether it auto-renews
notice periods for non-renewal
termination rights for repeated service failures
termination rights for insolvency, security breaches, or material breach
whether prepaid fees are refundable
whether the provider must assist with transition or handover

Auto-renewals are common. Businesses miss them when the service is quiet, then find themselves locked in for another year.

9. Dispute process and contract mechanics

A practical dispute clause can save time and cost. It should say who the business contacts are, how notices must be sent, whether senior escalation is required, and whether mediation is expected before court action.

Also check whether the provider can change support terms, pricing, or policies by notice alone. A one-sided variation clause can shift the commercial deal after signing.

Common Mistakes With Support and Maintenance Agreement

The most common mistakes come from treating the agreement as admin, when it is really an operating risk document.

Assuming support means unlimited support

Many providers offer support within defined channels, hours, and monthly usage levels. Unlimited support is rare unless the contract says so clearly. Before you accept the provider's standard terms, check ticket limits, fair use wording, and exclusions for training or configuration advice.

Relying on verbal promises

If a salesperson says there will be same-day fixes, priority support, or no charge for minor changes, that should appear in the signed contract or schedule. Before you rely on a verbal promise, ask for the wording to be inserted.

Missing the difference between maintenance and development

A bug fix restores agreed functionality. Development adds or changes functionality. That line can become blurry in custom software projects, and it often drives invoice disputes. The agreement should define each category and explain how change requests are approved.

Accepting weak service levels

A contract can look polished and still offer very little protection if it has no resolution targets, no outage process, and no consequence for repeated failure. If your business trades online, books customer appointments, or processes orders through the system, service levels need to reflect that reality.

Ignoring data and privacy issues

Support providers often have administrator access. That means they may see customer information, staff records, or commercially sensitive data. If the agreement says little about security, subcontracting, incident reporting, or data deletion, there is a real gap.

Overlooking termination and handover

The relationship can end at the exact moment your business is under pressure, such as after a pricing dispute or service failure. If the contract does not require reasonable transition assistance, access to records, credential handover, or cooperation with a replacement provider, moving away can be messy and expensive.

Signing a liability cap that is too low

Providers often cap liability at the fees paid in the last 6 or 12 months. That may be commercially standard, but it should still be assessed against the likely impact of downtime, data issues, or security failures. Low fees do not remove operational dependence.

The support and maintenance agreement may not stand alone. It may interact with:

the original software development or supply agreement
a master services agreement
service level schedules
statement of work documents
privacy terms or data processing schedules
licensing terms for software and third party tools

If these documents do not align, the parties may each think a different rule applies.

Not reviewing the contract as the business grows

A support arrangement that worked for a small team may not suit a growing business with more users, longer trading hours, and greater reliance on integrations. Review the agreement when your business adds new systems, expands trading hours, or takes on more sensitive data.

FAQs

What is a support and maintenance agreement?

It is a contract that sets out the provider's ongoing obligations after a system, software product, website, or IT service has been delivered. It usually covers support access, bug fixes, updates, maintenance tasks, fees, and service levels.

Do I need a written support and maintenance agreement in New Zealand?

A written contract is strongly recommended. Without one, it is much harder to prove what was promised, what response times apply, what is excluded, and what happens if the relationship breaks down.

Does maintenance include new features?

Usually not. Maintenance commonly covers bug fixes, patches, and upkeep of existing functionality. New features, upgrades, and changes are often treated as separate chargeable work unless the contract says otherwise.

Can a provider limit its liability in the agreement?

Often yes, especially in business-to-business contracts. But the cap, exclusions, and indemnities should be reviewed carefully so they are commercially acceptable for your business and the type of system being supported.

What should I check before signing the provider's standard terms?

Focus on scope, service levels, fees, exclusions, privacy and security obligations, liability caps, renewal mechanics, and exit support. Those clauses usually matter more in practice than the opening sales summary.

Key Takeaways

A support and maintenance agreement should clearly define what support is included, what is excluded, and how issues are prioritised and resolved.
Service levels matter. Response times, resolution targets, support hours, and outage handling should match the way your business actually operates.
Do not assume maintenance includes upgrades, customisations, or new development work. The contract should separate those categories.
Fees, liability caps, privacy obligations, security terms, and termination rights are the main legal and commercial risk points to review before you sign.
Verbal promises, marketing statements, and informal emails should be reflected in the signed agreement if they are important to your decision.
Exit planning is part of the deal. Make sure the contract covers renewal, termination, transition help, and access to your systems and data.

If you want help with service levels, liability caps, privacy terms, or exit rights, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.