How to write a scope of work

What a scope of work is for

A scope of work (SOW) has one job: to make sure you and the client are picturing the same project. Most disputes on a build aren't about bad work, they're about a difference in what "done" meant. One side assumed the price included content entry, migration and three rounds of changes; the other side didn't. The SOW is where you settle that before anyone starts.

It is also the document that has to survive the sale. A good scope isn't filed away once the contract is signed, it's the reference your delivery team builds from, the thing you check a "quick change" against, and the record you point to when the project drifts. Write it as a live plan, not a formality.

The eight sections every SOW needs

You can add more, but a scope of work is thin without these eight. Think of them as the questions a nervous client and a careful developer would both want answered.

1. 1Overview and objectives, one paragraph on what the project is and what success looks like.

Keep it in business terms: "a Shopify store that lets you sell subscriptions and ship internationally", not a feature dump.

1. 1In scope, the concrete deliverables. Pages, templates, integrations, migrations, features.

This is what the price buys.

1. 1Out of scope, the things a reasonable person might assume are included but aren't. This

section prevents more arguments than any other. More on wording it below.

1. 1Deliverables and acceptance, what you'll actually hand over, and how you'll both agree it's

done. "Client sign-off within five working days of staging link" beats "when finished".

1. 1Timeline and milestones, the phases, dependencies and the dates that depend on the client

(content, approvals, access). Name the dependencies or you'll own the delays.

1. 1Pricing and payment terms, the number, what it covers, the schedule, and any contingency.

For how to reach and present the figure, see how to price a website.

1. 1Assumptions, what has to be true for the price to hold: client provides copy, one brand

applies, hosting exists, no third-party blockers. Assumptions are quiet exclusions; write them down.

1. 1Change control, how a request for something new gets priced, approved and added. A scope

without a change process is a scope that leaks.

How to write the in-scope and out-of-scope lists

The out-of-scope list is the most valuable part of the whole document, and the part most people skip. Naming what a project doesn't include turns every later "can you just also…" into a visible decision instead of a silent assumption.

Write both lists as parallel, specific pairs. Vague scope is where money is lost.

• Weak: "SEO included."

Strong: "In scope: page titles, meta descriptions and a submitted sitemap for the 12 built pages. Out of scope: ongoing SEO, link building, content writing beyond the supplied copy."

• Weak: "Responsive design."

Strong: "In scope: layouts tested on latest Chrome, Safari, Firefox and Edge, plus iOS and Android. Out of scope: Internet Explorer and legacy browser support."

For a deeper method, including a phrase bank for common exclusions, read in-scope vs out-of-scope. And because content changes are the single biggest source of overrun, decide your revision limits before you send the document, not after the client asks for a fifth round.

Build change control in from the start

Every project changes. The question is whether change is a crisis or a routine. A clear change control clause makes it routine: any request outside the agreed scope is written up as a change, priced, and approved before work starts. No approval, no work; approved, it's added to the scope and the total.

This is not about being rigid. It's about making "yes" easy and safe. When the process is agreed up front, saying yes to a new idea is a two-line note and a price, not an awkward conversation about whether it was "supposed to be included". Our full guide to handling change requests covers the wording and the workflow.

A short worked example

Here's the shape of a tight in/out block for one feature of a brochure site:

Contact and enquiry In scope: a contact page with a validated enquiry form, spam protection, and email notifications to one inbox. Submissions stored in the CMS for 90 days. Out of scope: CRM integration, automated email sequences, and multi-step or conditional forms. Assumption: client provides the destination inbox and privacy-policy copy.

Three short blocks and there is almost nothing left to argue about. Do that for each part of the build and the SOW writes itself.

Common mistakes

• No out-of-scope section. The single most expensive omission. If it isn't excluded, a client

can reasonably assume it's included.

• Deliverables without acceptance. "Design the homepage" has no finish line. "Design the

homepage, up to two revision rounds, signed off within five working days" does.

• Silent dependencies. If your timeline assumes copy by a certain date, say so, or the delay

becomes yours.

• A scope you never look at again. If the document dies at signature, you've lost its best use.

Keep it as the reference delivery builds from. That's the whole idea behind ScopeDeck's quote-to-spec-to-tasks workflow, the scope you sold becomes the plan you build.