Alex is Sprintlaw’s co-founder and principal lawyer. Alex previously worked at a top-tier firm as a lawyer specialising in technology and media contracts, and founded a digital agency which he sold in 2015.
- What Is A Statement Of Work (SoW), And When Do You Need One?
- Why A Statement Of Work Template Matters For Small Businesses
What To Include In A Statement Of Work Template (UK Checklist)
- 1. Parties And Project Overview
- 2. Scope Of Services (What You Will Do)
- 3. Out Of Scope (What You Won’t Do)
- 4. Deliverables And Acceptance Criteria
- 5. Timeline, Milestones, And Client Responsibilities
- 6. Pricing, Payment Structure, And Expenses
- 7. Change Control (Variations)
- 8. Intellectual Property (IP) And Materials
- 9. Confidentiality And Data Handling
- 10. Termination And Handover (Project Exit)
- Key Takeaways
If you’re running a small business, it’s common to reach a point where a “handshake deal” (or even a short email thread) just doesn’t feel safe enough anymore.
Maybe you’re delivering a project for a client, onboarding a contractor, or rolling out ongoing services on a monthly basis. Either way, you need everyone to be crystal clear on what’s included, what’s not, and what happens if things change.
That’s where a Statement of Work (SoW) comes in. In this guide, we’ll walk you through how to use a statement of work template in a practical, UK-friendly way, and what to include so it actually protects your business (not just “looks professional”).
What Is A Statement Of Work (SoW), And When Do You Need One?
A Statement of Work (often shortened to “SoW”) is a document that sets out exactly what work is being delivered under a particular agreement.
Think of it as the “project blueprint” that sits alongside your main contract. Your contract is the legal framework (payment terms, liability, IP, termination and so on). Your SoW is the operational detail (scope, milestones, deliverables, timeline, acceptance criteria).
In practice, you’ll often see a SoW used where:
- Work is complex (there are multiple deliverables or phases)
- Requirements may change (you need a variation process and clarity on what change costs)
- Multiple stakeholders are involved (you want one shared “source of truth”)
- You’re supplying services repeatedly, but each job is slightly different (separate SoWs under one master agreement)
Common examples include marketing services, software development, consulting projects, design work, events, construction/supply and install projects, and managed services.
If you’re already using a broader services contract like a Service Agreement, a SoW is often the missing piece that stops disputes about “what we thought you meant”.
Why A Statement Of Work Template Matters For Small Businesses
Using a statement of work template can save you time, reduce back-and-forth, and help you scale your business without reinventing the wheel every time.
But the real value is risk management.
Without a well-written SoW, a lot of common (and expensive) arguments become more likely, such as:
- Scope creep (the client keeps asking for “small extras” that add up)
- Pricing disputes (you think it’s out of scope; they think it’s included)
- Delay arguments (they didn’t provide inputs on time, but blame you for the timeline slipping)
- Quality/acceptance disputes (you delivered what you thought was agreed, but they claim it’s not “done”)
It’s also useful internally. A strong SoW helps your team deliver consistently, because it forces you to define what “done” looks like.
Just keep in mind: a generic template is a starting point, not a magic shield. If your SoW doesn’t match the way you actually deliver work, it can create problems rather than solve them.
What To Include In A Statement Of Work Template (UK Checklist)
So what should your statement of work template UK include?
There’s no single “official” format, but for most small businesses, a solid SoW will cover the following sections.
1. Parties And Project Overview
- Legal names of the parties (matching your contract and any relevant registration details, where applicable)
- Short description of the project/services
- Reference to the main agreement (for example, “This SoW is entered into under the Master Services Agreement dated…”)
- SoW effective date and (if relevant) end date
This sounds basic, but it matters. If you’re contracting with the wrong legal entity, it can make enforcement difficult later.
2. Scope Of Services (What You Will Do)
This is the heart of the SoW. Be specific and practical.
Consider including:
- A list of the services you will provide
- Any assumptions you’re relying on (for example, “Client will provide brand assets within 5 business days”)
- What resources you will provide (people, tools, software, equipment)
- Dependencies (what must happen first before you can deliver)
If you want your SoW to prevent disputes, write this section like you’re explaining it to someone who wasn’t in the sales calls.
3. Out Of Scope (What You Won’t Do)
This section is often what saves you when scope creep starts.
Out-of-scope items could include:
- Extra revisions beyond an agreed number
- Additional pages/features
- Expedited delivery
- On-site work (if your pricing assumes remote delivery)
- Third-party costs (platform fees, paid media spend, licensing fees)
A helpful drafting approach is: if a client might reasonably assume it’s included, and you don’t want it included, spell it out here.
4. Deliverables And Acceptance Criteria
Deliverables are the tangible outputs you’re providing (reports, designs, features, campaigns, training sessions, installations).
Acceptance criteria define how the deliverables are approved. This is crucial because “looks good to me” is not a reliable legal test.
Your SoW can include:
- Deliverable descriptions (with enough detail to avoid ambiguity)
- Format (PDF, source files, working software environment, physical handover)
- Acceptance testing process (how and when they test/review)
- Acceptance timeframe (for example, “Deemed accepted if no written issues are raised within 5 business days”)
If your main contract includes limitations around disputes and risk, make sure it’s consistent with your acceptance process. A properly drafted Limitation Of Liability clause is often part of that bigger picture.
5. Timeline, Milestones, And Client Responsibilities
Most projects derail because of timing issues and missing inputs.
Include:
- Start date and estimated completion date
- Milestones (what is delivered by when)
- Review/feedback windows
- Client responsibilities (providing access, information, approvals, assets)
- What happens if the client is late (does the timeline extend? can you charge for rework?)
This is also where many businesses include communication rules (weekly check-ins, single point of contact, decision-making authority).
6. Pricing, Payment Structure, And Expenses
Your SoW should clearly explain how pricing works for this specific project.
Depending on your model, that could include:
- Fixed fee (with milestone payments)
- Time and materials (hourly/day rates)
- Retainer (monthly recurring services)
- Performance-based components (where appropriate and measurable)
Also clarify:
- Invoice schedule
- Payment due dates
- Whether VAT applies
- Reimbursable expenses and approval thresholds
If payment terms are mainly in your “master” contract, your SoW can still summarise pricing while pointing back to the contract for late payment interest, invoicing mechanics, and other standard terms.
7. Change Control (Variations)
Even well-scoped projects change. The difference between a smooth project and a dispute is whether you have a clear change process.
Your SoW should set out:
- How changes are requested (in writing, via email, through a ticketing system)
- How you will assess impact on fees and timeline
- When a change becomes binding (for example, only when both parties sign a “Change Order”)
- What happens if the client asks you to start work before signing the variation
This part works best when it aligns with your broader contract drafting approach. If you’re updating terms mid-project, you may be dealing with an Addendum or a contract amendment, so it’s worth keeping the language consistent.
8. Intellectual Property (IP) And Materials
Many SoWs involve creating or modifying valuable business assets: code, designs, copy, training materials, frameworks, plans, videos.
You’ll want clarity on:
- What pre-existing IP each party owns (and keeps owning)
- Who owns what is created during the project
- Whether the client gets an assignment of IP, or a licence to use it
- When IP transfers (often tied to payment in full)
If your work involves licensing content or software rather than handing over ownership, the SoW should match the position set out in your broader Software Licence Agreement or other IP terms (where relevant).
9. Confidentiality And Data Handling
If you’re receiving client data, commercial information, login credentials, or business plans, confidentiality should be addressed.
Often, confidentiality sits in the main agreement, but it’s still smart for your SoW to:
- Identify any particularly sensitive information (where relevant)
- Note how it will be shared (secure channels, access controls)
- Clarify at a high level whether personal data will be processed as part of the services
If you will be processing personal data for a client, you’ll usually also need appropriate UK GDPR terms in place (often a separate data processing agreement or data protection schedule), so it’s worth making sure your contracts are set up correctly.
10. Termination And Handover (Project Exit)
A good SoW also plans for what happens if the project ends early or changes direction.
Consider covering:
- What happens to work-in-progress
- Whether partially completed milestones are payable
- Handover obligations (files, access, documentation)
- Support/transition period (if relevant)
In most cases, the legal mechanics of ending the arrangement will be in the main contract, but the SoW can set expectations around the practical “handover” steps. If you need to formally end a contract relationship, a Deed Of Termination may be appropriate in some situations.
How To Use A Statement Of Work In Your Contracting Process
It’s one thing to have a statement of work template. It’s another thing to use it correctly (and consistently) across your projects.
Here’s a practical process many small businesses use.
Step 1: Use A “Master Agreement + SoW” Structure
For repeat client work, it’s often cleaner to have:
- a master agreement (your standard legal terms), and
- a separate SoW for each project or phase.
This way, you don’t renegotiate liability, dispute clauses, IP principles, and termination terms every time. You just issue a new SoW with the commercial details.
Step 2: Make Sure The Contract Clearly Incorporates The SoW
To avoid confusion, your contract should say (in plain terms) that:
- the SoW forms part of the agreement, and
- if there’s a conflict, which document “wins” (the master agreement or the SoW).
This is the kind of small drafting detail that makes a big difference when there’s a disagreement later.
Step 3: Keep The SoW Operational, Not Legalese
A SoW is not the place to cram in pages of legal boilerplate. That belongs in the main agreement.
Your SoW should read like a project plan that the client, your delivery team, and finance team can all understand.
Step 4: Use The SoW To Control Scope Creep
When a client requests extras, you can respond with a simple, professional message:
- confirm whether it’s in scope, and
- if not, offer a variation with an updated fee/timeline.
This keeps the relationship friendly while still protecting your time and margins.
Step 5: Get Sign-Off Before You Start Work
It’s tempting to “get started” to keep momentum. But if you begin work before the SoW is agreed, you can end up in a messy position where you’ve delivered value without clear payment terms or acceptance criteria.
If you want to move fast, you can agree the master agreement first, and then turn around SoWs quickly for each phase.
Common Mistakes With Statement Of Work Templates (And How To Avoid Them)
Templates can be useful, but there are a few predictable traps that small businesses fall into.
Using A SoW As A Substitute For A Contract
A SoW typically doesn’t cover everything you need to protect your business (liability, dispute resolution, warranties, IP ownership structure, termination rights, and more).
If you only have a SoW and no proper contract, you’re relying heavily on general contract principles and whatever can be inferred from emails and conduct. That’s rarely a comfortable position to be in.
Being Vague About Deliverables
Words like “support”, “optimisation”, “design work”, “development”, and “strategy” can mean very different things to different people.
Your SoW should define those terms through specifics: what will be delivered, how many rounds, what format, what’s excluded, and what “done” looks like.
Forgetting Client Responsibilities
If your timeline depends on client inputs (content, approvals, access), spell that out and link it to timeline extensions.
This is one of the easiest ways to reduce “you missed the deadline” arguments.
Not Having A Change Control Process
Without a variation process, change requests become informal, and informal change requests become scope creep. Then scope creep becomes unpaid work.
Even a simple “written change request + written approval” rule can help enormously.
Inconsistency Between The SoW And The Main Contract
If your SoW says one thing and your contract says another (for example, different payment timings or different IP ownership), you’re inviting confusion.
This is where having a lawyer set up a consistent structure can save you headaches later.
Key Takeaways
- A Statement of Work (SoW) is where you define the practical details of a project: scope, deliverables, milestones, acceptance criteria, pricing and change control.
- Using a statement of work template is a great way to standardise projects, but you still need to tailor each SoW to how the work will actually be delivered.
- For many small businesses, a “master agreement + SoW” approach is the cleanest way to handle repeat work without renegotiating your legal terms each time.
- A strong SoW should clearly include what’s in scope and out of scope, client responsibilities, the acceptance process, and how variations will be priced and agreed.
- Common mistakes include using a SoW without a proper contract, being vague about deliverables, and failing to include a clear change control process.
- If your SoW touches IP, confidentiality, or personal data, make sure it aligns with your wider contract and (where relevant) includes the right UK GDPR terms.
This article is general information only and isn’t legal advice.
If you’d like help putting together a Statement of Work structure that actually fits your services (and works smoothly with your contracts), you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.


