Legal Documents a Field Service Software Company Needs in New Zealand

If you run a field service software company, the legal risk usually does not show up in your code first. It shows up when a customer says the platform caused a scheduling error, a subcontractor mishandles customer data, or your standard terms stay silent on service levels and liability.

Many founders make the same mistakes: they accept a supplier's paper without negotiation, rely on a short proposal instead of a proper SaaS agreement, or collect location and job-site information without a privacy policy or data protection terms that match how the software actually works.

The right legal documents help you set the commercial rules before a dispute starts. For a New Zealand software business selling tools for trades, maintenance teams, installers, cleaners, or mobile technicians, that means getting clear on subscriptions, implementation work, uptime expectations, data use, IP ownership, subcontracting, and reseller arrangements. This guide explains which contracts matter, what each one should cover, and the main issues to check before you sign.

Overview

A field service software company usually needs more than one contract because the business is rarely just selling access to a platform. Most providers also handle onboarding, integrations, support, mobile app use, customer data, and third party services, each of which creates different legal risk.

• A master customer agreement or SaaS agreement should set subscription terms, permitted use, payment, renewals, service levels, data rights, and liability limits.
• A privacy policy and internal privacy documents should match how you collect technician, customer, and location data under the New Zealand Privacy Act 2020.
• Implementation statements of work should separate project services from ongoing software access.
• Supplier and subcontractor agreements should deal with hosting, development, support, and data handling responsibilities.
• Employment or contractor agreements should clearly address confidentiality, intellectual property ownership, and post-termination obligations.
• Reseller, referral, and channel partner agreements may be needed if you sell through industry partners or consultants.

What Legal Documents for Field Service Software Company Means For New Zealand Businesses

For a New Zealand field service software company, the key legal documents define how your platform is sold, how customer data is handled, and who carries the risk when things go wrong.

This matters because field service platforms often sit at the centre of real-world operations. If your software allocates jobs, records proof of service, tracks technician locations, stores customer contact details, or generates invoices, your contract position needs to reflect that operational importance.

Customer SaaS Agreement

Your main customer contract is usually the most important document in the business. Before you sign a customer, you want a written agreement that covers the actual product and service model, not a recycled software template.

A strong SaaS agreement will usually include:

• the subscription model, including user limits, site limits, modules, and add-ons
• payment terms, invoicing, overdue amounts, and rights to suspend for non-payment
• the subscription term, renewal process, and notice periods
• service description, exclusions, and any customer dependencies
• uptime targets or service levels, if offered
• support hours, response times, and escalation processes
• permitted use rules and restrictions on misuse, copying, reverse engineering, or unauthorised access
• data ownership, access rights, and what happens to customer data at the end of the contract
• privacy and security commitments
• warranties, disclaimers, and limits on liability
• termination rights, including for breach, insolvency, or repeated non-payment
• dispute resolution and governing law, usually New Zealand law for NZ based businesses

Founders often get caught when the contract says very little about implementation and support, but the sales process promises a lot. If your team is offering migration, onboarding, workflow configuration, or integration support, the documents need to separate those services from the software licence or subscription.

Statement of Work or Implementation Agreement

If you customise workflows, map data, build integrations, or assist with rollout, you should document that project work separately. This helps avoid confusion about what is included in the recurring subscription fee and what is one-off professional services work.

Your implementation document should spell out:

• scope of work and deliverables
• project assumptions and customer responsibilities
• timeframes and milestones
• acceptance process
• change request procedures
• fees, expenses, and payment triggers
• who owns any custom developments or integration outputs

This is especially useful where a customer expects software implementation to fix a broader operational problem. The contract can make it clear that your business provides software and agreed services, not a guarantee that the customer's field team will achieve any particular commercial result.

Privacy Policy and Data Processing Terms

Field service software often handles personal information from several groups at once: technicians, dispatchers, end customers, tenants, residents, and site contacts. A privacy policy is not just a website formality, it should accurately explain what personal information you collect and why.

Depending on your model, your customer may be the business collecting information through your platform, while you act as a service provider processing that information on their behalf. In practice, your customer agreement should deal with:

• what data the customer uploads or controls
• what data you collect directly
• how data is stored and secured
• whether data is transferred or hosted overseas
• how long data is retained
• how privacy requests, corrections, and incidents are handled
• what happens to data when the agreement ends

Under the Privacy Act 2020, New Zealand businesses need to be transparent about collection, use, storage, and disclosure of personal information. If your software uses GPS tracking, job photos, signatures, call recordings, or AI features that analyse service records, your privacy notice and internal privacy documents should match those functions.

Terms With Suppliers and Subcontractors

Most software companies depend on third parties, even if customers never see them. Hosting providers, outsourced developers, support contractors, SMS providers, map providers, and payment processors can all affect your legal position.

You should have contracts that deal with:

• service standards and availability
• security responsibilities
• confidentiality
• intellectual property rights
• subcontracting limits
• liability and indemnities
• termination and exit support

If a subcontractor touches customer data or writes product code, a handshake deal is not enough. Before you rely on a verbal promise, get the IP and confidentiality position in writing.

Employment and Contractor Agreements

Your team creates product assets, code, documentation, playbooks, and customer relationships. That makes employment and contractor documents central, not peripheral.

These agreements should usually cover:

• ownership of intellectual property created during the engagement
• confidentiality obligations
• permitted use of company systems and information
• return of property and access credentials on exit
• post-termination restrictions where appropriate and enforceable
• clear status of worker classification, especially for contractors

Founders sometimes assume they automatically own work product from freelance developers or implementation consultants. That assumption can fail if the contract is silent or badly drafted.

Partner, Referral, and Reseller Agreements

Many field service software companies grow through accountants, consultants, franchise groups, equipment suppliers, or industry associations. If another business is introducing customers or reselling your product, that relationship needs its own contract.

You may need terms covering:

• whether the partner is a referral source, authorised reseller, or implementation partner
• commission structure and payment conditions
• branding permissions and marketing claims
• who contracts with the end customer
• support responsibilities
• territory or exclusivity issues
• termination and treatment of existing customers

This is also where the Fair Trading Act 1986 matters. If partners describe your software in misleading ways, your business may still face the commercial fallout.

Legal Issues To Check Before You Sign

Before you sign a contract for field service software, the main job is to test whether the paper matches how the product is actually sold, delivered, and used.

Many software disputes start because the commercial team agreed to one thing, the legal terms say another, and the customer relies on whichever version suits them later. A careful contract review before you sign is cheaper than trying to fix a mismatch after rollout.

Scope and Deliverables

Be precise about what the customer is buying. If the platform includes web access, mobile apps, dispatch tools, GPS tracking, invoice generation, API access, and training, the documents should distinguish core features from optional extras.

Check whether the contract clearly addresses:

• what features are included at the agreed price
• whether implementation, data migration, and training are included or separately billed
• who is responsible for integrations with third party systems
• what assumptions apply to customer readiness and internal resources

Service Levels and Support Promises

If you offer uptime commitments or support response times, draft them carefully. Loose service language can create unrealistic expectations, especially for customers whose technicians rely on the app while out on jobs.

Before you accept the provider's standard terms, or before you issue your own, make sure they say:

• whether service levels are binding commitments or targets
• what maintenance windows and planned outages are allowed
• which support channels are available
• what credits or remedies apply if service standards are not met
• what events are excluded, such as outages caused by third party infrastructure or customer devices

Liability and Risk Allocation

Liability clauses decide who absorbs the cost when software performance, data loss, or implementation problems cause harm. This is where founders often accept broad exposure without realising it.

Review:

• any cap on liability and whether it is tied to fees paid
• excluded loss categories, such as indirect or consequential loss
• indemnities for IP infringement, privacy breaches, or misuse
• warranty wording about performance, compatibility, and uninterrupted service
• carve-outs that remove the liability cap for specific issues

The right position depends on your bargaining power, product maturity, and customer type. Enterprise customers may push for more protection, but that should still be commercially manageable.

Intellectual Property Ownership

Your contracts should make it obvious that the platform, source code, documentation, and know-how remain your property, except to the extent you expressly agree otherwise.

Pay special attention to:

• custom configuration versus custom development
• ownership of integration code or bespoke modules
• rights to use feedback, suggestions, and aggregated analytics
• customer data ownership versus software ownership

If a customer is paying for extensive customisation, they may assume they own what is built. If that is not the commercial deal, say so clearly before you sign.

Privacy, Security, and Data Hosting

A field service platform often carries detailed operational information, including names, addresses, access instructions, service histories, and technician movements. That data profile changes the legal conversation.

Check:

• whether your privacy documents match the product's actual functionality
• whether overseas hosting or support access needs to be disclosed
• what incident notification obligations apply
• what minimum security steps are promised
• whether customers need contractual commitments about deletion, export, or return of data

Consumer and Fair Trading Risk

Even in business to business software deals, your marketing statements matter. The Fair Trading Act 1986 prohibits misleading or deceptive conduct in trade, and broad sales claims can become a problem if they overstate what the software can do.

If your customers include smaller businesses, think carefully about product promises around automation, savings, compliance outcomes, and integration capability. Sales decks, demos, and proposal emails can all shape expectations before the contract is signed.

Common Mistakes With Legal Documents for Field Service Software Company

The most common mistake is using generic software terms that do not reflect the way field service platforms operate in practice.

That usually leaves gaps around mobile use, implementation work, technician data, subcontracted support, and operational reliance. Here are the errors that come up most often.

Using One Short Proposal as the Whole Contract

A proposal can help with pricing and scope, but it rarely covers data rights, liability, privacy, service levels, termination, and IP in enough detail. If the proposal is all you have, key issues will be left to implication and argument later.

Promising Outcomes the Contract Does Not Support

Founders often promise that the software will reduce missed jobs, improve technician utilisation, or integrate smoothly with legacy systems. Those claims may be commercially sensible, but they should not become unqualified legal promises unless you are prepared to stand behind them.

Align your sales language with the contract. If assumptions matter, write them down.

Ignoring Data Flows

Many field service businesses focus on customer company data and forget the personal information layer. The platform may collect employee location data, end customer contact details, access notes, or photos from private premises.

If your privacy policy is generic, or your customer terms do not explain each party's role in handling data, the legal position can become unclear quickly.

Leaving IP Ownership Vague With Developers

If you use freelance developers, agencies, or offshore teams, make sure the contract clearly assigns IP to your business and protects confidential information. Without that, ownership disputes can surface when you seek investment, sell the business, or release a new product feature.

Accepting Customer Procurement Terms Without Review

Larger customers may send their own procurement paper, privacy schedules, or security annexures. Those documents often contain heavy indemnities, broad audit rights, strict service credits, or unlimited liability for data issues.

Before you sign, compare those terms against your delivery model and insurance position. Do not assume they are standard or harmless.

Failing To Separate Services From Subscription Access

When implementation services and SaaS access are mixed together in one vague fee description, disputes about delays, change requests, or acceptance become harder to manage. Separate documents or at least separate sections can save a lot of confusion.

Overlooking Business Structure and Registration Basics

The contract set will not fix an underlying entity issue. Make sure the correct New Zealand legal entity is contracting, whether that is a company registered through the Companies Office or another suitable business structure. If you trade under a brand name, check that your branding and trade mark position are consistent with the entity actually signing the contracts.

That point sounds basic, but it matters when invoices, liability caps, IP ownership, and enforcement rights all depend on the right entity being named.

FAQs

Do I need a separate SaaS agreement and implementation agreement?

Usually, yes. If you provide both software access and project work, separate documents or clearly separated sections make scope, fees, acceptance, and liability much easier to manage.

Does a field service software company need a privacy policy in New Zealand?

In most cases, yes. If you collect personal information through your website, app, or platform, your business should have a privacy policy that reflects your actual data practices and complies with New Zealand privacy requirements.

Who owns customer data in a field service platform?

That should be dealt with expressly in the contract. Many SaaS agreements state that the customer owns or controls its uploaded data, while the software provider owns the platform, code, and related IP.

Can I rely on standard terms from overseas?

Not safely without review. Overseas templates often miss New Zealand legal context, including privacy language, Fair Trading Act risk, local governing law, and the way NZ SMEs usually buy software services.

What if a customer sends me its own procurement terms?

Review them carefully before you sign. Customer paper can shift major risk onto your business, especially around indemnities, security obligations, service levels, and uncapped liability.

Key Takeaways

• A field service software company in New Zealand usually needs a tailored customer SaaS agreement, not just a short proposal or invoice terms.
• Implementation or onboarding work should be documented separately so scope, fees, and change requests are clear.
• Privacy documents should match how your platform handles personal information, including technician data, job-site details, photos, and location tracking where relevant.
• Supplier, subcontractor, employee, and contractor agreements should protect confidentiality, allocate data responsibilities, and confirm intellectual property ownership.
• Before you sign a customer or supplier contract, review service levels, liability caps, indemnities, data clauses, and termination rights carefully.
• Generic overseas templates and unreviewed customer procurement terms are common sources of avoidable risk for NZ software businesses.

If you want help with SaaS agreements, privacy terms, implementation contracts, or supplier and contractor documents, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.