Statement of Work Sample: How to Write a Clear SOW Contract for New Zealand Businesses

A vague statement of work can turn a straightforward project into an expensive argument. New Zealand businesses often run into trouble when the scope is too broad, milestones are not defined, or the supplier’s standard terms quietly override what was discussed in meetings. Another common problem is relying on a proposal or email chain instead of a proper SOW contract with clear written terms that spell out who is doing what, by when, and on what assumptions.

If you are hiring a developer, marketing agency, consultant, designer, manufacturer, or specialist contractor, a clear statement of work sample can save a lot of stress before you sign. The right document helps you pin down deliverables, fees, timelines, acceptance criteria, change requests, and ownership of the final work. It also helps if the project slips, the brief changes, or one side says something different was promised.

This guide explains what a statement of work means in practice for New Zealand businesses, what clauses matter most, where founders usually get caught, and how to write an SOW that is actually useful when the project gets tested.

Overview

A statement of work is the part of a contract that describes the project in practical detail. It usually sits under a master services agreement, consultancy agreement, contractor agreement, or supplier contract, but it can also be a standalone schedule if the main terms are already agreed.

A good SOW reduces ambiguity before you sign, aligns the commercial deal with the legal terms, and gives both sides a workable reference point if there is a delay, scope change, or dispute.

• Identify the parties, project name, and related contract documents.
• Describe the services and deliverables in plain, measurable terms.
• Set out milestones, deadlines, dependencies, and review periods.
• State the fees, payment triggers, expenses, and invoicing process.
• Define acceptance criteria, testing steps, and sign-off requirements.
• Explain the process for variations, extra work, and timeline extensions.
• Deal with intellectual property, confidentiality, privacy, and use of third party material.
• Check liability caps, warranties, termination rights, and dispute provisions.

What Statement of Work Sample Means For New Zealand Businesses

A statement of work is where the real project expectations should live. The main agreement sets the legal framework, but the SOW is the working document that says what success looks like.

For many founders, the commercial conversation happens first. A provider sends a proposal, there are a few calls, and everyone feels aligned. The risk is that the final contract only includes broad wording such as “marketing support”, “website development”, or “advisory services as requested”. If the details sit in loose emails or verbal promises, the contract may not reflect the deal you thought you had.

A statement of work sample gives you a structure for turning those conversations into a document that can actually be used. In practice, that means writing down the deliverables, assumptions, exclusions, responsibilities, and sign-off process in a way that a person outside the project could still follow.

When a New Zealand business should use an SOW

You will usually want a statement of work when the work is project-based, staged, technical, or likely to change over time. It is especially useful where the price depends on scope, or where delays can happen because one side must provide information, approvals, or access.

Common business situations include:

• software builds, integrations, and app development
• website design and e-commerce projects
• branding, creative, and marketing campaigns
• consulting and advisory engagements
• manufacturing, product development, and prototyping
• managed services with separate work packages
• specialist contractor work with detailed milestones

What a statement of work sample should include

A useful statement of work sample is specific enough to manage the project, but still practical to update. The best contract drafting usually avoids fluff and focuses on items that can be checked objectively.

Your SOW should usually include:

• Project summary: the business objective, background, and what the parties are trying to achieve.
• Scope of services: the actual work to be performed, with enough detail to avoid assumptions.
• Deliverables: the documents, outputs, code, reports, designs, training, or other items to be provided.
• Exclusions: work that is not included, even if people might assume it is.
• Timeline: start date, milestones, key deadlines, and dependencies.
• Client responsibilities: information, approvals, access, feedback, personnel, systems, or assets the client must provide.
• Pricing: fixed fee, time and materials, milestone payments, recurring charges, and approved expenses.
• Acceptance process: how deliverables are tested, reviewed, accepted, or rejected.
• Variation process: what happens if the client wants changes, or if assumptions prove wrong.
• Legal overlays: confidentiality, intellectual property, privacy, warranties, and liability settings.

Why SOWs matter under New Zealand contract practice

New Zealand contract disputes often come down to what was agreed, what was left unstated, and whether the written terms match the parties’ conduct. A clear SOW helps because it creates a contemporaneous record of scope and expectations. That can matter well before any formal dispute arises. It affects whether an invoice is payable, whether a milestone has been met, and whether a request counts as extra work.

It also helps with related legal obligations. If a business is supplying services, general consumer and fair trading rules may still influence how those services are described and delivered in some situations, especially if marketing claims or service quality promises are broad. If personal information will be handled during the project, privacy obligations and data protection steps should line up with the SOW so each party knows who is collecting, storing, or accessing data and for what purpose.

A short practical example

Suppose a Christchurch retailer hires a developer to build a custom online ordering tool. The proposal says “build online order portal with inventory integration”. That sounds clear until testing starts.

Questions quickly follow. Does integration include setup with the retailer’s current system, or only an API connection? Who supplies the product data? Is mobile optimisation included? How many rounds of revisions are part of the fee? If the retailer changes the checkout flow after the wireframes are approved, is that included or a variation?

A proper statement of work sample answers those points upfront. That is what turns a hopeful brief into a workable contract.

Legal Issues To Check Before You Sign

The biggest legal risk is not the heading, it is the mismatch between the SOW and the rest of the contract. Before you sign a contract, make sure the commercial detail in the statement of work actually works with the legal terms around payment, liability, ownership, confidentiality, and termination.

Scope and deliverables

Scope should be detailed enough that both sides can tell whether the work has been done. Words like “support”, “assist”, “optimise”, or “complete implementation” can be too loose on their own.

Describe:

• what will be delivered
• the format of each deliverable
• the standard or specification it must meet
• what is excluded
• what assumptions the supplier is relying on

If the project has technical requirements, attach them. If the brief is likely to evolve, define the baseline scope first so later changes can be measured against it.

Timing, dependencies, and delay rights

A deadline only makes sense if the dependencies are stated. If the client must provide data, access, content, approvals, or internal contacts, the SOW should say so and explain what happens if those inputs are late.

Check whether the contract allows timeline extensions where:

• the client causes delay
• there is a change request
• third party systems are unavailable
• the parties are waiting on approvals or information

This is where founders often get caught. The supplier misses the date, but says the brief changed or approvals were late. If the SOW does not deal with dependencies, the argument becomes much harder to resolve.

Fees and payment triggers

Payment terms should tie to something measurable. “50 percent upfront, 50 percent on completion” sounds simple, but what counts as completion? If there are milestones, list exactly what must happen before each invoice can be issued.

Look closely at:

• deposit amounts and whether they are refundable
• milestone descriptions
• timesheet approval rules for hourly work
• expense approval requirements
• late payment rights and suspension rights
• whether GST is addressed correctly

If pricing is based on assumptions, write those assumptions down. If they change, the SOW should permit a revised quote or variation.

Acceptance criteria and sign-off

Acceptance criteria are often the difference between a manageable project and a stalled one. If there is no review process, one side may say the work is done while the other says it is not usable.

A sensible SOW can set out:

• the review period after delivery
• how defects or non-conformities must be notified
• the difference between defects and change requests
• when acceptance is deemed to occur
• whether use of the deliverable counts as acceptance

This matters particularly for software, design work, content production, and manufacturing projects.

Variations and scope creep

Every project changes. The question is whether your contract treats that as included work or chargeable variation.

Before you accept the provider’s standard terms, check that the variation clause explains:

• who can request a change
• how changes must be documented
• when the supplier can refuse a change
• how price and timing adjustments are approved
• whether work can begin before the variation is signed off

If there is no variation process, scope creep usually turns into fee disputes, delay claims, or damaged business relationships.

Intellectual property and third party material

Ownership is a major issue in many SOW contracts. A client may assume that paying for work means owning everything. A supplier may assume they keep ownership of pre-existing tools, templates, code libraries, and know-how. Both can be right in part, depending on the contract.

Check:

• who owns the final deliverables
• who owns background IP brought into the project
• whether third party software, stock content, or licensed assets are involved
• what licence each party gets to use the other’s material
• whether payment is a condition of IP transfer

If you are commissioning branded materials, software, training content, or proprietary systems, this clause deserves careful drafting before you rely on a verbal promise about ownership.

Confidentiality, privacy, and data handling

If the supplier will access customer lists, staff records, platform logins, analytics, or any other sensitive business information, the SOW should work with the confidentiality and privacy clauses in the main agreement.

For New Zealand businesses, this may include clarifying:

• what information can be accessed
• who is authorised to access it
• how long it can be retained
• whether subcontractors can use it
• what security steps are expected
• what happens at the end of the project

Where personal information is involved, the parties should also make sure their practices align with the Privacy Act 2020 and any relevant internal privacy processes or privacy notice requirements.

Liability, warranties, and termination

The legal protection in the contract should match the project risk. A low value design brief may justify a simple allocation of risk. A custom software build affecting customer operations may need more thought.

Pay close attention to:

• liability caps and carve-outs
• exclusion of indirect or consequential loss
• warranties about skill, care, and compliance with specifications
• termination rights for breach, convenience, or prolonged delay
• what happens to partially completed work on termination

If the contract can be terminated for convenience, the SOW should say what fees are still payable for work performed, committed costs, and handover assistance.

Common Mistakes With Statement of Work Sample

The most common mistake is treating the SOW as a sales document instead of a project control document. It should not just sound good, it should answer the practical questions that come up once work starts.

Using vague outputs

Terms like “strategy support”, “full build”, or “ongoing advice” often create room for disagreement. Better drafting breaks work into outputs that can be checked and signed off.

For example, instead of “website package”, spell out the number of templates, revisions, integrations, content migrations, browser compatibility requirements, and post-launch support period, if those are part of the deal.

Leaving out exclusions

If something is not included, say so. Clients often assume training, data migration, testing, stakeholder workshops, or regulator-facing work is part of the fee when the supplier thinks otherwise.

Exclusions are not unfriendly. They are one of the simplest ways to avoid friction before you sign.

Failing to tie payment to milestones

When milestone wording is loose, invoicing becomes subjective. “Phase 2 completed” does not help much if the phase is not defined anywhere.

A better approach is to tie payment to dated deliverables, signed approvals, or objective events such as delivery of a report, release of a tested module, or completion of agreed training hours.

Ignoring client obligations

Many projects fail because the customer has not allocated time, staff, content, approvals, or system access. If your business is the client, the SOW should record what you must provide. If your business is the supplier, this protects you from being blamed for delays you did not cause.

Letting the proposal and contract conflict

This happens often when a proposal promises more than the legal document reflects. The provider may say the proposal is only indicative, or the contract may contain an entire agreement clause saying only the signed terms count.

Before you sign, compare the proposal, quote, SOW, schedules, and standard terms side by side. If they differ, fix the mismatch directly.

Skipping the variation process

If changes are likely, the contract should assume they will happen. Otherwise people start “just making a few tweaks” and the project drifts into unpaid work or budget blowouts.

A short written variation form is usually enough. It should record the requested change, added fees, timeline effect, and approval from the right person.

Forgetting post-completion support

Some disputes start after delivery, not during the project. Think about warranty periods, bug fixes, knowledge transfer, documentation, and handover obligations.

If your business needs ongoing support after completion, make sure the SOW says whether that support is included, limited, or separately chargeable.

Overlooking industry-specific issues

Some projects need more than a basic template. A health business, fintech provider, manufacturer, or education provider may have sector-specific compliance expectations, record-keeping standards, or system security requirements that should be reflected in the SOW.

The same applies if the supplier will handle regulated content, marketing claims, or customer data. The SOW should reflect the real operating environment, not just generic contract language.

FAQs

Is a statement of work legally binding in New Zealand?

Yes, if it forms part of a signed contract or is otherwise incorporated into binding contractual terms. The key issue is whether the document clearly forms part of the agreement and is consistent with the main contract.

What is the difference between an SOW and a services agreement?

A services agreement sets the general legal terms, such as liability, confidentiality, payment mechanics, and termination. A statement of work sets the project-specific details, such as scope, deliverables, milestones, assumptions, and pricing for that piece of work.

Can an email or proposal count as a statement of work?

Sometimes, but it is risky. Emails and proposals often leave out acceptance criteria, variation rules, ownership terms, and legal protections. A clearer signed SOW is usually much safer before you sign or before work begins.

Who should prepare the statement of work, the client or the supplier?

Either side can prepare it, but both should review it carefully. The supplier often drafts the technical scope, while the client should check that deliverables, timings, assumptions, and ownership match the commercial deal.

Do I need a lawyer to review an SOW contract?

Not for every small project, but legal review or a contract review can be worthwhile where the work is high value, technically complex, business-critical, or likely to involve intellectual property, privacy issues, or negotiated liability terms.

Key Takeaways

• A statement of work sample should translate a commercial discussion into a practical contract document with clear scope, deliverables, timelines, and payment triggers.
• The main risk is ambiguity, especially around milestones, acceptance criteria, client responsibilities, and variations.
• Your SOW should work with the rest of the contract, particularly on intellectual property, confidentiality, privacy, liability, and termination.
• Exclusions and assumptions matter just as much as inclusions, because they stop people relying on unspoken expectations.
• Before you sign a contract, compare the proposal, SOW, and standard terms to make sure they do not contradict each other.
• If you are reviewing or negotiating statement of work sample and want help with scope drafting, IP ownership, liability clauses, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.