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

A vague statement of work can turn a straightforward project into a dispute about scope, timing and payment. UK businesses often run into trouble because the SOW is too high level, the acceptance process is missing, or the document does not match the main services agreement. That is usually when arguments start about whether extra work was included, whether milestones were actually met, and who carries the risk when a project slips.

A clear statement of work sample helps you avoid those problems before you sign a contract, before you accept the provider's standard terms, and before you rely on a verbal promise about what will be delivered. The right SOW should spell out the services, deliverables, deadlines, assumptions, dependencies, pricing and change process in plain English. If you are a founder, agency, consultant, software developer or growing SME, this guide explains what a statement of work should include, what legal issues to check, and the mistakes that most often lead to costly disagreements.

Overview

A statement of work, often called an SOW, is the project-specific part of a commercial contract that explains exactly what one party will do for the other. In the UK, it usually sits under a master services agreement, consultancy agreement or supplier contract, and it should be detailed enough that both sides can tell what has been promised and when.

A useful statement of work sample should make the commercial deal workable in practice, not just describe the project in broad terms.

• Define the services, deliverables and project scope clearly.
• Set out milestones, deadlines and any dependencies on the customer or third parties.
• Explain pricing, invoicing triggers and what counts as out of scope work.
• Include an approval or acceptance process for deliverables.
• Deal with change requests, delays, assumptions and project governance.
• Check that the SOW matches the main contract on liability, intellectual property, confidentiality and termination.

What Statement of Work Sample Means For UK Businesses

A statement of work turns a broad commercial relationship into specific project obligations. It is the document that usually answers the practical question, “What exactly are we paying for?”

For many UK businesses, the main services agreement contains the legal framework, while the SOW contains the working detail for a particular job. That means the SOW is often where disputes are won or lost. If the supplier says a task was outside scope, or the customer says a milestone was not achieved, the wording of the SOW will usually matter more than the sales pitch or a chain of emails.

What a statement of work usually covers

A good statement of work sample usually includes the core commercial facts that both sides need to rely on during the project.

• The names of the parties and the relevant contract it sits under.
• A description of the project and its objectives.
• Detailed services to be provided.
• Specific deliverables, formats and standards.
• Project stages, milestones and target dates.
• Responsibilities of the supplier and responsibilities of the customer.
• Assumptions and dependencies, such as access to systems, content, approvals or third party tools.
• Fees, expenses and payment timing.
• A process for variations or change requests.
• Testing, acceptance and sign-off steps.
• Any project-specific intellectual property terms, security requirements or service levels.

How an SOW fits with the wider contract

The SOW is not usually a standalone substitute for a full contract, unless it has been drafted to include all the legal boilerplate as well. Most businesses use it alongside a main agreement covering liability caps, confidentiality, intellectual property ownership, data protection, dispute resolution and termination rights.

This matters because an SOW can create confusion if it says one thing and the main agreement says another. For example, the SOW might promise a fixed delivery date, but the main contract may allow extensions where the customer delays approvals. If those documents are not aligned, neither side has a clear picture before work starts.

Why founders and SMEs rely on SOWs

Smaller businesses often move quickly and agree work over calls, proposal decks and email threads. The problem is that those materials rarely deal with the details that matter once the project is under pressure.

A well-drafted statement of work sample is especially useful when:

• You are engaging a consultant for a defined project.
• You are hiring a software developer, designer or marketing agency.
• You are delivering staged work over several months.
• You are charging on a fixed fee basis and need clear scope limits.
• You are depending on the client to provide information, assets or approvals on time.
• You are dealing with bespoke deliverables rather than standard off the shelf services.

In those situations, the SOW becomes the practical operating document for the project team and the legal reference point for the business owners.

What a clear statement of work sample looks like

A clear SOW uses objective language, measurable deliverables and realistic assumptions. It should not read like a sales brochure.

For example, saying “supplier will support the customer’s digital growth strategy” is too vague to manage or enforce. A stronger clause would say the supplier will provide:

• Audit of the customer’s current paid search campaigns by a set date.
• A written recommendations report up to a stated page limit.
• Set-up of a stated number of campaigns in specified platforms.
• Monthly reporting against named metrics.
• Two review meetings per month.

The second version gives both sides something concrete to measure. That is the real value of a strong statement of work sample.

Legal Issues To Check Before You Sign

The main legal risk is not just poor drafting, it is signing an SOW that leaves key commercial assumptions unstated. Before you sign, make sure the document actually reflects how the project will run in real life.

Scope and deliverables

The scope should say what is included and what is not included. If you only describe the end goal and not the actual work, the supplier may think they have priced a narrow job while the customer expects a much broader service.

Check whether the SOW identifies:

• The tasks to be carried out.
• The number and type of deliverables.
• The format of delivery.
• Any limits on revisions, meetings or support.
• Any services expressly excluded from the price.

This is where founders often get caught. A client may assume training, implementation support or post-project fixes are included, but the supplier may have intended to charge extra.

Timing, milestones and dependencies

A delivery date only works if the document also states what the other side must do to keep the project moving. If customer input is needed, the SOW should say so clearly.

Common dependencies include:

• Access to systems, premises or software.
• Provision of branding assets, content or technical specifications.
• Named customer contacts with authority to give instructions.
• Feedback and approvals within stated timeframes.
• Third party cooperation, licences or platform approvals.

If those points are missing, delay arguments can become messy. One side says the deadline was fixed, the other says it was conditional. The SOW should deal with both the target date and the circumstances that justify an extension.

Fees, payment triggers and expenses

The payment terms should match the project structure. A fixed fee project with milestones needs clear invoicing triggers, while a time and materials engagement needs rates, timesheet expectations and expense rules.

Check the SOW for:

• Whether fees are fixed, capped, estimated or variable.
• What triggers each invoice, such as signature, milestone completion or acceptance.
• Whether expenses can be charged and if prior approval is required.
• What happens if the project is paused or terminated early.
• Whether late payment affects timelines or ongoing work.

Do not leave the commercial model to assumption. A project can become unprofitable quickly if the SOW does not deal with overruns, rework or delay costs.

Acceptance testing and sign-off

If you are delivering a bespoke output, the SOW should explain how the customer accepts it. Without an acceptance process, you can end up with endless informal requests for changes and no clear point at which the work is complete.

A sensible acceptance clause may cover:

• How the deliverable will be tested or reviewed.
• The time period for the customer to accept or reject it.
• The grounds on which rejection is allowed.
• The supplier’s right to correct non-conformities.
• When acceptance is deemed to occur, for example if no response is given in time.

This protects both sides. The customer gets a fair process to check the output, and the supplier gets a clear route to completion and payment.

Change control

Projects rarely stay identical from start to finish. A proper change control clause stops a shifting brief from becoming a hidden cost or a hidden obligation.

The SOW should say how either party can request a change, who approves it, and what happens to timing and fees if the change is accepted. Even a simple process is better than none. Without one, teams often rely on Slack messages, calls and meeting notes that are not clear enough to settle a later disagreement.

Intellectual property and licences

The SOW should not promise ownership outcomes that conflict with the main agreement. That is particularly important for software development, design work, written content, technical documentation and other bespoke materials.

Check:

• Who owns newly created materials.
• Whether ownership transfers only after payment.
• Whether pre-existing tools, templates or code remain with the supplier.
• What licence rights the customer gets to background materials.
• Whether third party components are subject to separate terms.

This area causes regular tension where a customer expects full ownership but the supplier intends to reuse frameworks, know-how or underlying assets across clients.

Data protection, confidentiality and security

If personal data will be handled, the SOW should align with the wider contract on UK GDPR responsibilities. The SOW may also need project-specific security commitments if the work involves sensitive systems, customer data or regulated information.

Before you sign, check whether the document identifies:

• What categories of data are involved.
• Whether the supplier acts as a controller or processor in context.
• Any security standards, access controls or incident reporting expectations.
• Confidential information handling during and after the project.

Do not assume generic confidentiality wording is enough if the project involves personal data, internal systems or commercially sensitive material.

Termination and what happens if the project stops

An SOW should deal with what happens if the work ends early. Businesses often focus on delivery and forget to agree the unwind.

Check what the contract says about:

• Termination for convenience or for breach.
• Payment for work done up to the end date.
• Handover of partially completed work.
• Return or deletion of data and confidential materials.
• Continuing rights to use any work already paid for.

That is especially important where one side will have invested significant time before a final deliverable is reached.

Common Mistakes With Statement of Work Sample

Most SOW disputes start with ordinary business shortcuts. The common thread is that one or both sides treat the SOW as an admin document rather than the practical core of the project contract.

Using broad wording copied from a proposal

Sales language is designed to win work, not define obligations. If your statement of work sample simply repeats phrases like “end-to-end support” or “best practice implementation”, it leaves too much open to interpretation.

Replace broad wording with measurable tasks, capped revision rounds, named deliverables and realistic assumptions. Precision is what keeps a project manageable.

Failing to define what is outside scope

Many SOWs explain what will be done but say nothing about what is excluded. That creates room for expectation gaps, especially in creative, technology and advisory projects.

Out of scope items often include:

• Additional meetings beyond the agreed number.
• Training after delivery.
• Migration of legacy data.
• Third party software costs.
• Urgent work outside normal hours.
• Extra rounds of revisions.

If a task is likely to be assumed by the customer, consider naming it and excluding it expressly unless separately agreed.

Leaving milestone dates unconnected to customer actions

A fixed timeline without customer obligations is often unrealistic. If the client must provide feedback, assets or approvals, say when and say what happens if they do not.

Otherwise the supplier can be blamed for delay they did not cause, or the customer may feel pressured by dates that did not account for internal review processes. The contract should deal with this upfront.

Not matching the SOW to the master agreement

An SOW should not sit in legal isolation. If the main contract says one thing and the SOW says another, you need a clear order of precedence and consistent drafting.

Common mismatches include different payment timing, different intellectual property wording, inconsistent liability clauses, and project deliverables that do not fit the agreed service description. Before you sign, read the documents side by side.

Relying on verbal promises or scattered emails

If a point matters commercially, put it in the contract. Verbal assurances about extra support, unlimited revisions or fast approvals are hard to prove and often remembered differently by each side.

This is one of the biggest reasons a statement of work sample should be finalised before the project starts, not halfway through once money has been spent and work has already begun.

Ignoring acceptance criteria

Without objective acceptance criteria, the customer may reject work for reasons that were never part of the brief, or the supplier may push for payment before the customer has had a fair chance to review it.

Even simple criteria help. For example, a website build could specify browser compatibility, page templates, integrations and bug severity thresholds. A policy drafting project could specify document count, issue coverage and revision rounds.

Forgetting project governance

A practical SOW often needs a few operational rules. These can be simple, but they matter.

• Who can give binding instructions.
• How often project meetings occur.
• How issues are escalated.
• Which communication channels count for approvals or change requests.

These details reduce confusion once the project is busy and multiple people are involved on each side.

Treating the template as final without tailoring it

A statement of work sample is a starting point, not a finished answer. A template may be useful, but it still needs to be adjusted to the actual service, pricing model, delivery method and risk profile.

A software development SOW, for example, should not look the same as a recruitment consultancy SOW or a design retainer SOW. The legal framework may be similar, but the details that drive disputes are different.

FAQs

Is a statement of work legally binding in the UK?

It can be, if it forms part of a signed contract or is otherwise incorporated into binding written terms. The key issue is whether the document has contractual effect and works clearly with the main terms.

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

A services agreement usually sets the overall legal terms of the relationship. An SOW usually sets the project-specific details, such as scope, deliverables, milestones and pricing for a particular piece of work.

Can an SOW be used on its own?

Yes, but only if it includes enough legal terms to operate as a full contract. Many businesses prefer to use an SOW with a master agreement so they do not need to renegotiate the legal boilerplate each time.

Who should draft the statement of work?

Usually the supplier drafts the first version because they understand the delivery model, but both sides should review it carefully. The customer should make sure the business outcome, acceptance steps and assumptions are accurately reflected before signing.

What should I do if the other side sends a vague SOW?

Ask for detail before you sign. Focus on scope, exclusions, timing, dependencies, change control, payment triggers and acceptance. If the project is valuable or complex, a contract review is often worth it.

Key Takeaways

• A statement of work is the project-specific document that defines what will be delivered, when, and on what commercial terms.
• A clear statement of work sample should cover scope, deliverables, milestones, dependencies, pricing, acceptance and change requests.
• The SOW should match the wider contract on liability, confidentiality, intellectual property, data protection and termination.
• Most disputes come from vague scope, missing exclusions, unclear approval processes and reliance on verbal promises.
• Before you sign, make sure the document reflects how the project will actually operate, including who must do what and by when.

If you want help with scope drafting, change control terms, intellectual property clauses, or supplier contract review, you can reach us on 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.