SaaS Pilot Agreements in New Zealand: What to Include

A SaaS pilot can help a founder win a serious customer, test product fit and build a stronger sales case. It can also create messy expectations if access is switched on before the commercial rules are clear. Common mistakes include treating a pilot like a casual demo, letting the customer upload live personal information without privacy terms, or promising enterprise-level support before a full subscription has been agreed.

A SaaS pilot agreement in NZ should do more than say how long the trial runs. It should set boundaries for data use, support, uptime, feedback, intellectual property, payment, cancellation and what happens if the customer converts to paid terms.

A well-drafted software trial agreement in NZ gives both sides enough confidence to test the product without accidentally creating an open-ended licence, an unpaid implementation project or a custom development commitment.

SaaS Pilot Agreement Checklist For New Zealand Founders

A pilot agreement should define the experiment, limit the risks and make the next commercial step easy to understand.

Many SaaS founders offer a pilot during the pre-sales stage, especially for larger B2B customers. The customer wants to see whether the software works with their team, systems and data. The founder wants a credible pathway to a paid subscription, case study, reference or larger rollout.

The problem is that a pilot often sits between several different documents. It is not quite a sales proposal, not quite a full master services agreement and not quite a standard website trial. A dedicated proof of concept agreement for software can bridge that gap.

At a practical level, your pilot customer agreement should answer these questions:

• Who can use the platform? Identify the customer entity, authorised users, administrators and any third-party contractors.
• What version of the product is being tested? Describe the modules, integrations, sandbox access, beta features and any excluded functionality.
• How long does the pilot run? State the start date, end date, onboarding period and whether extensions need written agreement.
• Is the pilot free or paid? Set out pilot fees, implementation charges, GST treatment, invoicing, payment timing and expenses.
• What data can be used? Decide whether the customer may upload real customer data, employee data, test data, anonymised data or sample data only.
• What support is included? Specify onboarding sessions, response times, channels, training, bug fixes and what counts as out-of-scope consulting.
• What happens to feedback? Clarify whether you can use suggestions to improve the product and whether the customer receives any ownership rights.
• What are the success criteria? Record the outcomes the pilot is designed to test, such as workflow time saved, reporting quality, integration performance or user adoption.
• How does conversion work? Explain whether the pilot automatically ends, renews, converts to paid terms or requires a new subscription order.
• What happens at the end? Deal with data deletion, export, account closure, unpaid amounts and continuing confidentiality obligations.

A common founder moment is the Friday afternoon email from a prospective enterprise customer saying they are ready to start testing next week. The customer sends a procurement questionnaire, asks for admin access and wants their operations team invited immediately. That is exactly when a clear pilot document helps. It lets you say yes to the commercial opportunity while still controlling the legal and operational exposure.

For early-stage SaaS businesses, the pilot agreement does not need to be longer than necessary. What matters is that it is specific. A vague statement like access to the platform for evaluation purposes leaves too many gaps. A stronger clause might say that the customer may use the named analytics module for up to 20 internal users for a 60-day evaluation, using non-production data unless otherwise approved in writing.

Scope Access And Trial Limits

The scope clause should make it clear that the customer is testing a limited product for a limited purpose, not receiving a full commercial rollout, software licence or implementation services.

This is where many SaaS trial terms fall over. Founders want to be helpful, so they give access to extra features, add extra users, join repeated training calls and build small custom workflows. The customer may then assume these extras are included in the full product or that the pilot includes an implementation project.

Your pilot scope should cover the product, the users and the permitted use. For example, the agreement can say the customer may use the software internally to assess suitability for its business operations and must not use it to provide services to third parties, run production-critical processes or process prohibited categories of data.

Access controls are especially relevant where your product integrates with payroll, HR, finance, healthcare, education or customer relationship management systems. If the customer connects the wrong account or grants excessive permissions, your team may end up handling data or system access that you did not plan for. The pilot agreement should require the customer to manage its user permissions, keep login details secure and promptly remove users who no longer need access.

A strong access section can include:

• the maximum number of users, seats, projects, records, API calls, API access or storage volume included in the pilot;
• whether access is to a sandbox, staging environment, beta environment or live production instance;
• whether the customer can invite affiliates, contractors, consultants or external advisers;
• restrictions on reverse engineering, scraping, benchmarking, security testing or competitive analysis;
• whether the customer can publish results, screenshots or performance comparisons; and
• your right to suspend access for security issues, misuse, non-payment or breach of the pilot terms.

Usage limits should be commercially realistic. If the customer needs 10 users to run a meaningful test, a two-user pilot may not prove much. On the other hand, if the customer wants 300 users, a production integration and a board report, that may be closer to a paid implementation than a simple trial.

Time limits also need care. A pilot might run for 30 days, 60 days or 90 days, depending on the sales cycle and product complexity. The agreement should say whether the pilot starts when the document is signed, when access is provided or when onboarding is completed. If onboarding depends on the customer providing data, credentials or technical contacts, the agreement should explain what happens if the customer delays.

Founders should avoid automatic extensions that roll on indefinitely. A pilot that keeps running without a decision can consume support time and cloud costs without revenue. A better approach is to require written agreement for extensions and to reserve the right to charge additional fees if the customer wants more time, users or functionality.

A pilot can also include acceptance or success criteria, but these should be carefully framed. If the criteria are too vague, the customer may argue the pilot failed for subjective reasons. If they are too strict, your sales team may be boxed into an unrealistic pass or fail test. Useful criteria might include completion of agreed onboarding tasks, successful import of sample data, generation of specified reports or participation in review meetings.

Data Privacy Security And Confidentiality

Data terms should say exactly what information can enter the pilot environment and how each party must protect it.

New Zealand SaaS founders should pay particular attention to the Privacy Act 2020 where the pilot involves personal information. Personal information can include customer names, email addresses, usage logs, employee details, health information, student records or any information about an identifiable individual.

If the customer uploads personal information into the platform, both sides need to understand their roles. The customer may be collecting and deciding how to use the information, while your SaaS business may be hosting, processing or accessing it to provide the pilot. Your agreement should align with the Privacy Act 2020 and the Information Privacy Principles, including limits around collection, use, disclosure, storage, security and access.

A practical pilot document should deal with:

• Data categories: whether the customer may upload personal information, confidential business information, sensitive operational data or only dummy data.
• Permitted processing: what you can do with the data, such as host it, analyse it, troubleshoot issues, generate reports or provide support.
• Data location and subprocessors: whether cloud hosting, analytics, support tools or third-party vendors are used, especially if information is stored or accessed overseas.
• Security measures: the technical and organisational protections you apply, such as access controls, encryption practices, logging, backups and staff access restrictions.
• Privacy incidents: how the parties will notify each other if there is unauthorised access, loss, disclosure or a suspected notifiable privacy breach.
• Deletion or return: what happens to customer data when the pilot ends and whether backups are handled under your usual retention processes.

A common mistake is to say that all customer data remains the property of the customer, then say nothing else. Ownership is only one part of the issue. You still need rights to process the data for the pilot, maintain the platform, investigate errors and generate aggregated insights if that is part of your product analytics. If you want to use de-identified or aggregated data to improve the service, state that clearly and avoid using data in a way that can identify the customer or individuals unless the agreement permits it.

Security expectations can also become a sales blocker. Enterprise customers may ask for penetration testing reports, security questionnaires, insurance details or data processing terms. A pilot agreement can set a sensible baseline without overpromising. For example, avoid guaranteeing that the platform is free from all vulnerabilities. Instead, describe your security approach and require the customer to promptly report suspected security issues.

Confidentiality should work both ways. You may receive the customer's operational information, data samples, technical architecture and procurement materials. The customer may receive your pricing, product roadmap, beta features, documentation and trade secrets. The agreement should limit use of confidential information to the pilot, restrict disclosure and require reasonable steps to keep it secure.

Non-disclosure terms are especially useful when the pilot involves unreleased features. If your customer is testing a new AI feature, workflow builder or integration, you may not want screenshots or performance comments shared publicly. A clear confidentiality clause can protect the pre-release product while still allowing the customer to discuss the pilot internally with relevant staff and advisers.

Fees Support Uptime Feedback And Conversion Terms

The commercial terms should stop the pilot from quietly becoming unpaid consulting, free production use or an accidental transfer of product rights.

A free pilot is not legally simpler than a paid one. Even without fees, the customer receives access to valuable software and you may receive data, feedback or a future sales opportunity. The agreement still needs boundaries.

If the pilot is paid, set out the amount, GST, invoicing and payment timing. Make clear whether fees are refundable if the customer decides not to proceed. If you charge implementation, migration, configuration or training fees separately, separate them from the platform access fee. This helps avoid arguments about whether extra work was included.

For unpaid pilots, consider whether there are hidden costs. Cloud usage, support calls, onboarding and custom setup can add up. The agreement can reserve your right to charge for out-of-scope work, extra storage, additional integrations or extension periods.

Support terms should match the stage of the relationship. A pilot customer may need onboarding and responsive help, but that does not mean they should receive full enterprise service levels or support and maintenance commitments. Your support clause can specify:

• the support channels available, such as email, ticketing portal or scheduled calls;
• support hours, especially if your team is based in New Zealand and the customer has overseas staff;
• the number of onboarding or training sessions included;
• the customer's responsibility to provide technical contacts and timely information;
• what counts as a defect compared with a feature request or configuration issue; and
• when additional professional services will require a separate quote.

Uptime commitments need careful wording. A founder may feel pressure to promise 99.9 percent availability because it sounds standard, but that kind of service level may be inappropriate for a temporary pilot, beta feature or early-stage infrastructure. If you do provide an uptime target, explain any exclusions, such as scheduled maintenance, third-party outages, customer systems, misuse or events outside your control.

For many pilots, it is better to say the platform is provided for evaluation and testing, with no guarantee that it will be uninterrupted or error-free. That said, avoid using trial wording to hide material limitations if you know the product is not fit for the proposed test. The Fair Trading Act 1986 prohibits misleading or deceptive conduct in trade, so your sales statements, proposal and agreement should match the product's actual capabilities.

The Consumer Guarantees Act 1993 can also be relevant in some business transactions, although many B2B SaaS arrangements address statutory guarantees through commercial contracting where the law allows. Do not rely on a generic disclaimer without checking whether it is appropriate for your customer type and transaction.

Feedback ownership is a key issue for software companies. Customers may suggest improvements, new dashboards, automation rules, prompts, reports or integrations. Your agreement should say that feedback can be used by your business to improve the product without owing compensation or giving the customer ownership of those improvements. If the customer is paying for custom software development, treat that separately and specify who owns the resulting code, configurations, documentation and deliverables.

Intellectual property terms should preserve your ownership of the software, source code, platform design, documentation, trade marks and pre-existing materials. A pilot customer should usually receive a limited, revocable, non-exclusive right to use the platform for the agreed pilot purpose. If you are using open-source components, third-party APIs or licensed data, make sure your pilot terms do not grant rights you do not have.

Conversion terms are the bridge between the pilot and the full customer contract. Decide whether the customer will sign a separate subscription agreement, accept standard SaaS terms, or enter an order form that incorporates your main terms. The pilot agreement can say that access ends unless the parties agree paid subscription terms by the end date.

Some founders prefer an automatic conversion clause. For example, if the customer does not cancel before the pilot ends, a monthly subscription begins. This can work for lower-touch online trials, but it may be risky for enterprise pilots where procurement approval, a data processing agreement and security reviews are still underway. If you use automatic conversion, the price, subscription period, renewal rules and cancellation rights need to be clear.

A more controlled approach is to include an optional conversion pathway. The pilot terms can say the parties will review the pilot outcomes before the end date, discuss commercial subscription terms and sign a separate order form if the customer proceeds. This keeps pressure on the sales process without pretending that the full deal is already finalised.

FAQs

Do I Need A Separate Pilot Agreement If I Already Have SaaS Terms?

Usually, yes. Standard SaaS terms are designed for ongoing paid use, while a pilot deals with temporary evaluation, limited access, trial data, pre-sales support and conversion steps. You can sometimes use a short pilot order form that incorporates your main SaaS terms, but the pilot-specific limits should still be clear.

Can A Free Pilot Still Create Legal Risk?

Yes. A free pilot can still involve confidential information, personal data, product reliance, feedback, support obligations and intellectual property issues. The absence of payment does not remove the need for clear terms, especially if the customer uses real business data or expects technical support.

Should Customers Use Real Data Or Test Data In A Software Trial?

Test data is often safer at the early evaluation stage. If real personal information or sensitive business data is needed for a meaningful test, the agreement should address privacy, security, access controls, breach notification, data location and deletion at the end of the pilot.

Who Owns Improvements Suggested During The Pilot?

Your SaaS business should usually retain ownership of product improvements, especially where suggestions relate to general platform features. If the customer is funding bespoke development or expects exclusive rights, address that in a separate custom development clause or services statement.

What Should Happen When The Pilot Ends?

The agreement should state whether access stops, data is exported or deleted, unpaid fees become due, confidentiality continues and the customer can move to a paid subscription. Avoid leaving the account active without a clear commercial basis.

Key Takeaways

• A SaaS pilot agreement in New Zealand should define the trial purpose, users, product scope, time period and usage limits.
• Data and privacy clauses matter from the start, especially where the pilot involves personal information under the Privacy Act 2020.
• Support, uptime and implementation commitments should reflect a pilot relationship, not an unlimited enterprise rollout.
• Feedback and intellectual property terms should let you improve your product without giving away ownership of your software or roadmap.
• Conversion terms should explain whether the pilot ends, extends, automatically converts or moves to a separate paid subscription agreement.
• Clear pilot terms help founders say yes to pre-sales opportunities while keeping costs, data risk and customer expectations under control.

If you are preparing a paid or free SaaS pilot, Sprintlaw New Zealand can help with your pilot terms, privacy and data clauses, feedback ownership wording and conversion pathway to a full subscription. Contact us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.