How To Include A Scope of Work In Your Service Agreement (2026 Updated)

If you sell services, you already know the tricky part isn’t always doing the work - it’s making sure everyone agrees on what the work is.

That’s exactly what a Scope of Work (often called a “SOW”) is for. When it’s properly included in your service agreement, it can prevent scope creep, payment disputes, and those awkward “but I thought that was included” conversations.

This 2026 update reflects how service businesses are operating right now: remote delivery, faster project timelines, more use of subcontractors, and more client expectations being set through emails, DMs and online proposals. A solid Scope of Work helps you keep things clear (and enforceable) from day one.

What Is A Scope of Work (And Why Does It Matter In New Zealand)?

A Scope of Work is the part of your service agreement that describes, in practical terms, what you will do for the client - and just as importantly, what you won’t do.

In plain English, it’s where you set expectations about:

• the deliverables you’ll provide
• the tasks included (and excluded)
• timeframes and milestones
• inputs you need from the client
• how changes are handled
• how you’ll measure “done”

In New Zealand, having a clear Scope of Work isn’t just “nice to have”. It can be crucial evidence if there’s later a disagreement about what was promised and what was delivered.

It also supports your broader compliance and risk management. For example:

• If you’re making statements about what your service includes, you’ll want consistency with the Fair Trading Act 1986 (which is all about misleading or deceptive conduct).
• If you provide services to consumers, you may also have obligations under the Consumer Guarantees Act 1993 (like performing services with reasonable care and skill).

A well-drafted SOW helps you deliver what you promised, and helps your client understand what they’re paying for.

How Is A Scope of Work Different From A Service Agreement?

A lot of people use “Scope of Work” and “service agreement” interchangeably, but they’re not the same thing.

Generally:

• The service agreement is the overarching legal contract - it sets the relationship rules (payment terms, liability, termination, confidentiality, IP ownership, dispute resolution, and so on).
• The Scope of Work is the project-specific or engagement-specific detail - what work is being delivered this time.

Many businesses structure it this way because it gives you flexibility. Your “master” agreement can stay the same, and you can attach new Scopes of Work each time the client wants a new project or a new phase.

That’s especially useful if you’re delivering ongoing services (like marketing, bookkeeping, IT support, HR consulting, design, or development) where the details change month-to-month.

If you’re still building your legal foundations, it’s often worth starting with a properly drafted Service Agreement and then deciding how you’ll handle SOWs (as a schedule, annexure, or standalone document) based on your workflow.

When A Separate Scope of Work Makes The Most Sense

A separate SOW tends to work best when:

• you deliver projects in stages or “phases”
• you have repeat clients who buy different services over time
• you need quick sign-off on a new piece of work without renegotiating the entire contract
• the pricing varies per project and you want that captured clearly each time

When You Might Keep The Scope Inside The Main Agreement

It can be cleaner to keep the scope within the agreement if:

• it’s a one-off job with no repeat work expected
• the work is simple and the deliverables are fixed
• you want one document only (e.g. for smaller engagements)

There’s no one “right” structure - what matters is that the scope is clear, consistent, and legally connected to the terms that protect you.

What Should You Include In A Scope of Work?

A good Scope of Work is detailed enough that both sides can confidently say: “Yes, that’s what we agreed.”

At the same time, it shouldn’t be so complicated that it becomes impossible to use (or is constantly out of date). The goal is clarity, not paperwork for the sake of it.

1. Parties And Project Overview

Start with the basics:

• who the supplier/provider is (your legal entity name)
• who the client is
• a short description of the engagement (one or two sentences)

This sounds obvious, but it’s helpful when you later have multiple SOWs signed over a long relationship.

2. Deliverables (What You Will Actually Provide)

This is the heart of the scope.

Where possible, list deliverables as concrete items, not vague outcomes. For example:

• “Draft and deliver 6 blog posts (1,000–1,200 words each)”
• “Design 10 social media templates in Canva and supply editable files”
• “Provide fortnightly Xero reconciliation and quarterly management reports”
• “Develop and deploy a landing page with a contact form and basic analytics”

If the deliverable is something less tangible (like coaching or consulting), describe the structure:

• number and length of sessions
• format (Zoom, in person, phone)
• what’s included between sessions (if anything)

3. Inclusions And Exclusions (How You Stop Scope Creep)

One of the simplest ways to avoid disputes is to include an exclusions list.

Examples of common exclusions:

• “Copywriting is excluded unless specifically stated.”
• “Paid advertising budget is excluded.”
• “Website hosting and domain costs are excluded.”
• “Printing and physical production are excluded.”
• “Responding to customer support enquiries is excluded.”

This is where you can also clarify assumptions, like “client will provide all branding assets within 5 business days” or “client will supply product photographs”.

If you have a standard approach to how the work runs, you can also cross-reference your main agreement terms for things like variations and approvals, so the scope stays focused on the “what”.

4. Timeframes, Milestones, And Dependencies

Timeframes are often where relationships get strained, so it’s worth being specific.

You might include:

• start date and end date (or an estimated completion date)
• milestones (e.g. draft delivery date, review dates, final delivery)
• dependencies (e.g. “timeline assumes client feedback within 3 business days”)

A practical tip: specify what happens if the client is late with feedback or inputs. If you don’t, you may end up wearing timeline pressure for something outside your control.

5. Acceptance Criteria (How You Decide The Work Is “Done”)

Acceptance criteria can be as simple as:

• “Deliverables are accepted when provided by email in PDF and DOCX format.”
• “Client has 5 business days to request reasonable revisions, otherwise the deliverable is deemed accepted.”

This is especially important for creative work, software builds, and other deliverables where “done” can otherwise become subjective.

6. Fees, Payment Milestones, And Extra Charges

It’s common for the payment terms to sit in the service agreement, but the SOW should still be clear about the commercial deal for that specific project.

Common approaches include:

• Fixed fee (e.g. $5,000 + GST for the project)
• Hourly rate (e.g. $180 + GST per hour, billed monthly)
• Milestone-based (e.g. 40% upfront, 30% on draft, 30% on completion)
• Retainer (e.g. $2,000 + GST per month for up to 10 hours)

If you’re using milestone payments, make sure the scope lines up with those milestones. Otherwise, you can end up in a situation where you’ve completed work but can’t clearly link it to a payment trigger.

How Do You Attach The Scope of Work To A Service Agreement?

It’s not enough to have a Scope of Work sitting in an email chain or a PDF proposal. You want it to be contractually linked to your service agreement, so the protections in your agreement actually apply to the work being done.

Here are the most common ways to do it.

Option 1: Scope of Work As A Schedule Or Annexure

This is the most straightforward method.

• The service agreement includes “Schedule 1 – Scope of Work”.
• The scope is physically attached to the agreement document.
• Both parties sign the agreement (including the schedule).

This is clean for one-off projects, or where you’re only expecting to have one scope.

Option 2: Master Service Agreement + Multiple Scopes of Work

This is a common model for agencies, consultants, IT providers, and other ongoing service businesses.

Your agreement should clearly say that:

• each SOW forms part of the agreement once signed/accepted
• if there’s any inconsistency, the agreement or the SOW takes priority (and in what order)
• you can issue new SOWs over time without re-signing the full agreement

This is where getting the drafting right matters - because if the documents don’t “talk” to each other properly, you can end up with enforceability problems.

When you’re setting up your contract suite, it can also be worth thinking about what else you need alongside your SOW, like confidentiality and IP provisions in your main terms. For example, your agreement may need a proper Non-Disclosure Agreement approach (or NDA clause) if you’re handling sensitive business information during delivery.

Option 3: Online Acceptance (But Still Contractually Clear)

Many service businesses now onboard clients online - via e-sign, client portals, or checkout flows.

That’s fine, but you still need to ensure:

• the client is clearly accepting both the agreement and the specific SOW
• the documents are properly identified (version, date, title)
• you can prove acceptance later if there’s a dispute

If you’re relying on “acceptance by email” or “acceptance by payment”, you’ll want your contract drafted to support that workflow. Otherwise, you may find yourself arguing about whether there was actually a binding agreement at all.

Common Scope of Work Mistakes (And How To Avoid Them)

Most Scope of Work disputes come down to one thing: the scope didn’t match what either side expected.

Here are some common traps we see (and how to sidestep them).

Using Vague Language That Can’t Be Measured

Terms like “ongoing support”, “a full brand package”, or “SEO optimisation” can mean very different things to different people.

Instead, define:

• what activities are included (and how many)
• what tools/platforms you’ll use
• what you’ll deliver (files, reports, sessions)
• how many revisions are included

Not Saying What’s Excluded

Exclusions feel uncomfortable at first (especially when you’re trying to win work), but they’re one of the easiest ways to keep clients happy.

When expectations are clear, you can confidently say “yes” to the right work - and confidently quote extra work as a variation.

Not Having A Variation Process

Changes happen. The problem isn’t change - it’s change without a process.

Your agreement should explain how variations work (for example, written approval, updated SOW, change request process, and revised fees/timeframes). If you don’t have this, you can end up doing extra work “informally” and then struggling to get paid for it.

Forgetting About IP Ownership

If you deliver creative work, software, branding, strategy documents, or templates, your client may assume they “own everything” just because they paid you.

IP ownership should be covered clearly in your service agreement (and aligned with what you say in the scope). If you’re licensing pre-existing tools, templates, or code, that needs to be stated properly too.

Depending on your business model, you might need a dedicated IP Licence arrangement rather than a simple “assignment” of IP.

Misalignment With Your Marketing Or Sales Promises

If your website or proposal says you provide something, but your scope doesn’t include it (or your scope contradicts it), you can end up exposed to disputes - and potentially issues under the Fair Trading Act 1986 if claims are misleading.

A practical habit is to treat your SOW as the “single source of truth”, and ensure sales material is consistent with it.

Not Thinking About Privacy When You Collect Or Handle Data

A Scope of Work often includes tasks like:

• accessing customer databases
• running email campaigns
• processing bookings
• handling employee or patient/client information

If personal information is part of delivery, you should be mindful of your obligations under the Privacy Act 2020. In many cases, a clear Privacy Policy and appropriate confidentiality/data handling clauses in your service agreement are essential.

Key Takeaways

• A Scope of Work (SOW) sets out exactly what services you’re providing, what’s excluded, and how the work will be delivered, which helps prevent scope creep and payment disputes.
• Your SOW should be contractually linked to your service agreement so your key protections (like liability limits, payment terms, termination rights, and confidentiality) apply to the work.
• Strong SOWs usually include deliverables, inclusions/exclusions, timeframes, client responsibilities, acceptance criteria, pricing, and a clear variation process.
• Keeping your SOW clear and consistent with your sales promises can reduce the risk of disputes and help you stay compliant with laws like the Fair Trading Act 1986 and Consumer Guarantees Act 1993.
• If your services involve handling personal information, make sure your contractual documents reflect your Privacy Act 2020 obligations and your operational reality.
• Templates can be a risky shortcut - having a lawyer draft or review your service agreement and SOW structure can save you major headaches later.

If you’d like help putting together a Scope of Work that actually works in practice (and fits cleanly into a service agreement), you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.