Templates

Scope of work template

A free scope of work / statement of work template, overview, in/out of scope, deliverables, milestones, revisions, change control and sign-off.

No card needed. 2 clients and 5 quotes free forever. Unlimited teammates.

What this template is, and who it's for

A scope of work (statement of work) is the reference document for a project: what's being done, who does what, the milestones, and how changes are handled. It's for agencies, studios, freelancers and consultants who want a clear, signable definition of the engagement, especially on fixed-price work where "what's included" decides whether the job is profitable.

"Scope of work" and "statement of work" are used interchangeably; this template covers both.

How to use it

  1. 1Copy the block below as Markdown or PDF.
  2. 2Fill in the overview, deliverables and milestones for your specific project.
  3. 3Keep the In scope / Out of scope, Revisions and Change control sections intact,

they're what a SOW is for. Adjust the specifics, never delete the guardrails.

  1. 1Get it signed by both sides before work starts.

The template

# Statement of Work, [Project Name]

Between: [Your Studio] ("Supplier") and [Client Company] ("Client")
Date: [DD Month YYYY]
SOW reference: [SOW-0001]

1. Overview

[One or two paragraphs: the project's purpose, the business context, and the outcome it should achieve. Anyone new to the project should understand it from this section alone.]

2. Objectives

  • [Objective 1, measurable where possible]
  • [Objective 2]
  • [Objective 3]

3. In scope

  • [Workstream / deliverable 1, with any limits, e.g. up to n pages]
  • [Workstream / deliverable 2]
  • [Workstream / deliverable 3]

4. Out of scope

The following are explicitly excluded and, if required, will be handled as a change:

  • [Item 1, e.g. content creation / copywriting]
  • [Item 2, e.g. third-party licence costs]
  • [Item 3, e.g. post-launch support and hosting]

5. Deliverables

#DeliverableFormatAcceptance
1[e.g. Approved sitemap][PDF][Client sign-off]
2[e.g. Design templates][Figma / PDF][Client sign-off]
3[e.g. Live website][URL][Passes agreed test list]

6. Milestones & timeline

MilestoneTarget datePayment
Kickoff / deposit[date][40]%
Design sign-off[date][30]%
Launch[date][30]%

Dates assume Client feedback within [n] working days at each stage.

7. Revisions

Each design and build stage includes [2] rounds of revisions. Rounds beyond this are billed at [£rate]/hour under the change-control process below.

8. Change control

Any request outside Section 3 (In scope) is handled as a Change Request:

  1. 1Either side raises the change in writing.
  2. 2Supplier provides impact on cost and timeline within [n] working days.
  3. 3Work proceeds only once the Client approves the change in writing.

No change is actioned, and no fee incurred, without written approval.

9. Assumptions & dependencies

  • [Client supplies content and brand assets by date]
  • [Access to hosting, accounts, or third parties provided by date]
  • [Approvals given by a named decision-maker]

10. Contingency

A contingency of [10%] (£[…]) covers reasonable unforeseen work. It is drawn on only via the change-control process; unused contingency is not charged.

11. Commercials

  • Fees: £[…] (ex VAT), invoiced per the milestone table above.
  • Invoices due within [14] days. Late payment may pause work.

12. Sign-off

Signed for [Client Company]: __________________ Date: __________ Signed for [Your Studio]: __________________ Date: __________


---

What makes a good scope of work

  • Out of scope carries more weight than in scope. Two people rarely disagree about what's

included; they disagree about what isn't. Naming exclusions is where a SOW prevents disputes.

  • Make deliverables acceptance-testable. "A website" is a wish. "A live website that passes the

agreed test list" is a deliverable you can be paid for. Give each one an acceptance condition.

  • Tie milestones to payments. Payment against milestones keeps the project moving and protects

your cash flow if priorities drift.

  • Write the change-control process before you need it. A defined route for changes, raise,

cost, approve in writing, turns "just a quick tweak" into a calm, priced decision.

  • State your assumptions. Most overruns come from a dependency that slipped, not the work

itself. Writing the assumptions down makes a missed client deadline the client's issue, not yours.

Build your SOW faster in ScopeDeck

A SOW is meant to be the definition of the work, so it shouldn't die the moment it's signed. In ScopeDeck the scope is a live document: you write it once, and the same section tree becomes the specification and the delivery task list. In-scope, out-of-scope and revision limits stay attached, amendments are tracked in version history, and delivery works from the agreed scope rather than re-reading a PDF. Start free, no card needed.


FAQ

None, in practice, the terms are used interchangeably, and both abbreviate to SOW. This template serves either. A SOW is usually part of, or attached to, a wider contract.