Statement of Work: What to Include in Your SOW

A vague scope is one of the fastest ways for a project to go off track. Founders often agree to broad deliverables in emails, skip the detail around timing and approvals, or assume a standard services agreement will cover everything. Then the work expands, deadlines slip, and nobody is quite sure what was actually promised.

A well-drafted statement of work (sow) fixes that problem. It sets out exactly what is being delivered, when, how changes are handled, and what each side needs to do for the project to succeed. That matters whether you are engaging a software developer, marketing agency, consultant, designer, or specialist contractor.

This guide explains what a statement of work (sow) is, what to include in your sow template, when New Zealand businesses usually need one, and the common mistakes to avoid before you sign a contract or spend money on company setup.

Overview

A statement of work (sow) is the project-level document that turns a broad commercial deal into practical working instructions. It usually sits under a master services agreement or services contract and records the specific services, deliverables, milestones, fees and responsibilities for a particular piece of work.

A good sow should be clear enough that a new person joining the project could read it and understand what must happen next, what counts as completion, and what falls outside the agreed scope.

Identify the parties, project name and start date.
Describe the services and deliverables in specific, measurable terms.
Set milestones, deadlines and dependencies.
Record the client’s responsibilities, inputs and approvals.
Explain fees, payment timing and any assumptions behind pricing.
Deal with changes in scope, delays and extra work.
Confirm who owns intellectual property and what licences apply.
Address confidentiality, privacy policy requirements, and data handling where relevant.
State acceptance testing or sign-off criteria.
Make sure the sow matches the main contract and does not contradict it.

What Statement of Work Sow Means For New Zealand Businesses

A statement of work (sow) gives New Zealand businesses a practical way to define a project without rewriting the whole contract each time. It is usually not a standalone legal idea on its own. Its legal effect depends on how it fits into the broader contract between the parties.

For many SMEs, the sow is the document people actually use day to day. The master agreement might cover liability, confidentiality, disputes, payment terms and termination at a high level, but the sow is where the commercial detail lives.

What a sow actually does

The main job of a sow is to remove ambiguity. If you are paying a supplier to build a website, integrate software, produce a marketing campaign, or deliver a consulting project, the sow should spell out exactly what is included.

That usually means setting out:

the scope of services
specific deliverables
timing and milestones
the roles of each party
acceptance criteria
fees and expenses
the process for changes

Without that detail, arguments often arise over whether a task was included, whether revisions are unlimited, whether delay is the supplier’s fault, or whether extra fees can be charged.

How a sow works with a services agreement

Most businesses use a sow together with a separate services agreement, contractor agreement or master services agreement. The main contract sets the legal framework. The sow then applies that framework to a specific project.

For example, your main contract might say that intellectual property created for the client will transfer once all fees are paid. The sow would then identify what is being created, such as source code, design files, training materials or written reports.

Your main contract might also include general confidentiality and privacy obligations. The sow can add project-specific rules, such as where customer data will be stored, who may access it, and whether any subcontractors are involved.

Why this matters in New Zealand

New Zealand businesses often work in fast-moving projects where the scope evolves quickly. That is common in software development, digital marketing, construction-related consulting, managed services, and specialist advisory work. A short email exchange may feel efficient at the start, but it creates risk once money has been spent and expectations diverge.

A carefully drafted sow can also support compliance with wider legal obligations. Depending on the project, that may include obligations relating to:

fair and accurate representations about services under the Fair Trading Act 1986
privacy and personal information handling under the Privacy Act 2020
consumer-facing service standards in some situations, including obligations that may arise if services are supplied to consumers
intellectual property ownership, licensing and trade mark use
record-keeping and evidence if a payment or performance dispute arises

The sow is not a substitute for the main contract, but it is often the document that makes the contract workable in practice.

What should be in a sow template

Your sow template should be detailed enough to use across repeat projects, but flexible enough to suit different service lines. Most businesses should include the following sections.

Parties and project details. Name the supplier and client correctly, include NZBN or company details if relevant, record the date, and identify the related master agreement if there is one.
Background and project objective. Briefly state what the project is intended to achieve. This helps with interpretation later if scope is disputed.
Scope of services. Describe the actual work to be done. Avoid generic wording like “ongoing support as required” unless you also define limits.
Deliverables. List the outputs the client will receive, in concrete terms. State format, quantity, version, and whether drafts are included.
Out of scope items. This is where founders often get caught. If a task is not included, say so clearly.
Timeline and milestones. Set dates or milestone triggers, and note any assumptions such as access to systems or timely feedback from the client.
Client dependencies. Record what the client must provide, such as content, approvals, technical access, branding files, or internal stakeholder attendance.
Fees and payment terms. Say whether pricing is fixed fee, hourly, retainer or milestone-based. Note what happens if the scope changes.
Variations process. Explain how additional work is approved, priced and documented before it starts.
Acceptance criteria. State how the client confirms that work has been accepted, and whether there is a review period.
Intellectual property. Clarify who owns pre-existing materials, who owns new deliverables, and what licence rights apply.
Confidentiality and privacy. Include project-specific handling rules if personal information, customer data or commercially sensitive material is involved.
Assumptions and exclusions. This helps prevent disputes where pricing relied on a limited number of revisions, meetings or integrations.
Sign-off. Make sure the sow is approved by authorised people before work begins.

When This Issue Comes Up

The need for a statement of work (sow) usually appears when a project has moving parts, staged delivery, or a real chance of scope creep. If the work cannot be described in a single sentence on an invoice, a sow is often worth using.

Many businesses first think about a sow only after a project becomes difficult. The better time is before you sign a contract, before you onboard a supplier, and before either side starts work.

Common founder situations where a sow helps

A software developer is building a custom app, website or integration and the features may change over time.
A marketing agency is delivering a campaign with strategy, creative work, media setup and monthly reporting.
A consultant is engaged for a transformation project with workshops, recommendations and implementation stages.
An IT provider is supplying managed services, migration work or cybersecurity support with detailed technical tasks.
A product business is hiring a designer or developer to create branding, packaging assets, or e-commerce functionality before launch online.
A growing company is using contractors across multiple client projects and needs a repeatable project template.

Projects with higher legal and commercial risk

Some projects need extra care because the commercial risk is higher. That includes jobs where one or more of the following apply:

the budget is significant
there are strict timeframes tied to launch, funding, or customer terms
personal information will be handled
new intellectual property will be created
third-party software or licences are involved
subcontractors will do part of the work
the supplier is making claims about outcomes, performance or compliance

In those cases, a one-page scope summary often is not enough. The business case for a more detailed sow is much stronger.

When a simple quote may not be enough

A quote can state a price, but it usually does not deal with dependencies, change requests, acceptance testing, or ownership of project outputs. That gap matters when things change halfway through.

For example, a founder may approve a quote for “website build and launch” expecting copywriting, SEO setup, analytics integration and post-launch support. The supplier may have priced only design implementation and basic deployment. If the quote does not spell out the detail, both sides may feel the other has moved the goalposts.

A sow makes those expectations visible at the start.

Businesses using repeat engagements

If your business delivers services to multiple customers, a sow can make sales and delivery more efficient. You can keep one core services agreement in place, then issue a new sow for each project. That helps with consistency, record keeping and staff handovers.

It also reduces the chance that different team members promise different things. Sales can use the sow template to define what was sold, operations can use it to deliver, and finance can use it to invoice against milestones.

Practical Steps And Common Mistakes

The best sow templates are specific, realistic and tied to how the project will actually run. The main risk is not legal jargon. The main risk is leaving practical gaps that turn into disputes later.

Step 1: Define the deliverables, not just the activity

Many sows describe effort instead of output. “Provide development support” or “assist with strategy” is too loose on its own. A better approach is to define the actual result the client will receive.

For example:

three wireframe concepts for the homepage and product page
a working API integration between named systems
two training sessions of up to 90 minutes each
a final report in PDF format with recommendations and implementation roadmap

That level of detail makes it easier to price the work and decide when it is complete.

Step 2: Separate what is included from what is excluded

Most scope disputes happen because no one recorded the exclusions. If revisions are capped, say how many rounds are included. If content writing, third-party licences, or stakeholder workshops are excluded, say so clearly.

Useful exclusions often include:

third-party software costs and subscriptions
hosting, domain or infrastructure fees
travel and out-of-pocket expenses
training beyond a stated number of sessions
support after go-live
integration with systems not named in the sow

This is especially important before you print marketing materials, launch a website, or promise a customer delivery dates based on work another supplier has not clearly committed to provide.

Step 3: Build in a variation process

Projects change. Your sow should assume that from day one. A simple variation clause can say that either party may request a change, the supplier will assess timing and price impact, and the change must be approved in writing before work starts.

Without that process, teams often keep working informally, then argue later about extra fees or delay. That is one of the most common commercial mistakes in service projects.

Step 4: Tie timing to dependencies

A date on its own can be misleading. If delivery depends on the client supplying data, approving designs, or giving system access, the sow should say so.

Good wording often links milestones to client actions, such as:

draft delivery within 10 business days after receipt of all required content
testing begins once the client confirms access credentials and test data
launch date is subject to the client approving final assets by a specified deadline

This protects both sides. The client knows what it must do, and the supplier is less likely to wear the full risk of delay caused by missing inputs.

Step 5: Set acceptance and sign-off rules

If a sow does not explain how deliverables are accepted, projects can drift in endless review cycles. Set a review period, define what counts as a defect, and state whether silence amounts to acceptance after a reasonable time.

Acceptance criteria might include:

the deliverable materially matches the agreed specification
testing confirms core functions work in the agreed environment
the client has five business days to request fixes that relate to the agreed scope
change requests outside scope are handled as variations

Founders often miss this point when engaging developers or designers, then feel stuck in unlimited revisions.

Step 6: Deal with intellectual property early

Ownership of project outputs should never be left to assumption. If the supplier uses pre-existing tools, templates, code libraries or know-how, the sow and main contract should distinguish those background materials from the new deliverables created for the client.

Questions to resolve include:

does the client own the final deliverables outright, or receive a licence to use them
when does ownership transfer, on creation or only after full payment
can the supplier reuse general know-how or non-confidential components
are any third-party assets included, and what licence terms apply
can the client modify the deliverables after handover

This is particularly important in software, branding, digital content and product design work.

Step 7: Check privacy and data handling

If the project involves personal information, the sow should say what data will be accessed, why, and what restrictions apply. A generic confidentiality clause may not be enough if a provider will process customer, employee or user information.

Depending on the project, you may need to address:

who controls the personal information and who processes it
what security measures are expected
whether data can be stored or accessed overseas
how long information is retained
what happens to data at the end of the project

That can support compliance with the Privacy Act 2020 and help avoid practical misunderstandings during implementation.

Common mistakes businesses make with sow templates

Several problems come up again and again.

Using generic wording that sounds polished but does not say what will actually be delivered.
Letting the sow contradict the main services agreement on payment, IP or liability.
Failing to identify assumptions behind the price.
Leaving milestones unattached to any client responsibility.
Not stating what happens if a project pauses or is terminated early.
Ignoring out-of-scope work because the team wants to move quickly.
Forgetting to get formal sign-off from someone with authority.

A useful final check is to ask whether a person who was not in the sales conversations could deliver the project from the sow alone. If not, the scope probably needs more work.

FAQs

Is a statement of work legally binding in New Zealand?

It can be, if it forms part of a valid contract and is properly incorporated into the agreement between the parties. The safest approach is to make the sow expressly subject to a signed services agreement or master agreement.

What is the difference between a sow and a services agreement?

A services agreement sets the overall legal terms of the relationship. A sow sets the project-specific details, such as deliverables, milestones, scope, fees and client responsibilities.

Can I use one sow template for every client project?

You can use a standard template, but each sow should be tailored to the actual work. Reusing broad wording without adjusting deliverables, timing, assumptions and exclusions is where many disputes start.

Do I need a sow for small projects?

Not always. For very simple, low-risk work, a clear quote and contract may be enough. If the project has multiple stages, custom deliverables, revisions, technical dependencies or privacy issues, a sow is usually worth having.

Should a sow cover intellectual property and privacy?

Yes, at least at a practical project level. The main contract may contain the core legal clauses, but the sow should still identify what is being created, what data is involved, and any project-specific rules around use, access and handover.

Key Takeaways

A statement of work (sow) turns a broad service arrangement into a clear project plan with legal and commercial value.
The strongest sow templates define deliverables, timelines, client responsibilities, fees, assumptions, exclusions and the variation process.
Your sow should work with the main services agreement, not conflict with it.
Projects involving software, consulting, marketing, data handling or custom creative work often need more detailed scope wording.
Common mistakes include vague deliverables, missing exclusions, no acceptance criteria, and unclear intellectual property terms.
Before you sign, make sure the sow is specific enough that both sides can tell what success looks like and what happens if the scope changes.

If your business is dealing with statement of work sow and wants help with contract drafting, scope and variation clauses, intellectual property terms, privacy obligations, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.

Statement of Work (SOW): What to Include in Your SOW Template