What is a scope of work? How to write one for client projects

What is a scope of work?

A scope of work (often shortened to SOW) is a written description of the work a provider agrees to do for a client. It names the deliverables, the boundaries of the project, the timeline and the conditions for calling each piece finished.

For a service business, the scope usually sits inside the proposal the client signs, next to the context, the approach and the price. On larger engagements it can also be a standalone document attached to a contract. Where it lives matters less than what it says: the scope is the reference both sides return to when a question comes up in the middle of the project.

A good scope answers four questions without anyone having to ask you:

• What exactly will the client receive?
• What is not included?
• When will each part be delivered, and what does that depend on?
• How will both sides agree that a deliverable is done?

Scope of work vs statement of work

The two terms overlap, and both are abbreviated SOW, which is why they get mixed up.

• Scope of work: the description of the work itself. Deliverables, exclusions, timeline and acceptance.
• Statement of work: a broader document, common in procurement and larger contracts, that usually contains the scope plus commercial and management terms such as pricing, payment schedule, reporting and governance.

In practice, a statement of work contains a scope of work. For most agency, studio and consulting projects, a clear scope inside a signed proposal, with the price and terms beside it, does the job a statement of work would do. If your client’s procurement team asks for a formal statement of work, the scope you have already written becomes its core section.

What to include in a scope of work

Most scopes that cause trouble are missing one of these eight parts.

1. Objective. One or two sentences on what the project is for, so every deliverable can be checked against it.
2. Deliverables. Each item the client receives, with its format and quantity: “Primary logo, secondary mark and favicon, as SVG and PNG” rather than “logo design”.
3. Out of scope. What is not included, written down even when it feels obvious. Anything left unsaid is something a client can reasonably assume is included.
4. Assumptions and client responsibilities. What you need from the client (content, access, approvals, one decision-maker) and by when.
5. Timeline and milestones. Dates tied to the client’s feedback, and what happens to the schedule when feedback is late.
6. Revisions. A number of rounds per deliverable, not “revisions included”.
7. Acceptance. How a deliverable is approved, and what counts as approval if the client does not respond.
8. Change requests. How new requests are quoted and approved before work on them starts.

Payment milestones are not part of the scope itself, but they should match the delivery milestones it describes.

How to write a scope of work

1. Start from the objective. Write the outcome the client is paying for before you list a single task.
2. List deliverables as things, not effort. If the client cannot check it, rewrite it.
3. Write the exclusions next. For each deliverable, note the closest thing a client might expect that you are not providing.
4. State your assumptions. Content, access, feedback times, the number of people approving.
5. Put dates on milestones, not tasks. Link each date to the client input it depends on.
6. Define done. For each deliverable, say how it is approved and how many rounds of revisions are included.
7. Agree the change process. A short rule for requests that arrive after signature.

Then read the scope as the client would. If a new person on either side could tell whether a request is in or out of scope without asking you, it is ready.

To skip the blank page, copy our scope of work template, which follows this structure.

Scope of work examples

The difference between a scope that protects both sides and one that invites argument is often a single line. Three examples from service projects:

Full, filled-in versions of all three are in the scope of work template. If you write proposals for this kind of work, see the video production proposal template and the branding proposal template.

Common scope of work mistakes

• Describing effort instead of output. “40 hours of design” says what you will spend, not what the client gets.
• No exclusions. The request that starts scope creep is usually the one nobody wrote down.
• Open-ended revisions. “Until you are happy” has no end date.
• Dates with no dependencies. A deadline that ignores late feedback becomes your problem the first time feedback is late.
• Scope in one document, price in another. When the client approves them separately, they drift apart.

Keep the scope where the client decides

A scope works best when the client reads it in the same place they approve the price and sign. In Pegasy, the scope is a section of an interactive proposal: Scope of Work, Deliverables, In / Out and Assumptions sections sit next to the offer and your terms. The client reviews it on the web, can ask a question or request a change, and signs the exact version they read.

See how it works on proposal software for service businesses, or browse more guides and templates in Resources.

Questions about scope of work

Who writes the scope of work?

Usually the provider, because they know what the work involves. The client reviews it, and the person who signs on their side should be able to approve both the work and the budget.

How long should a scope of work be?

Long enough that every deliverable, exclusion and milestone is clear. For many creative and consulting projects that is one to three pages. The test is clarity, not length.

Is a scope of work a contract?

A scope describes the work. Whether it is enforceable depends on how it is agreed and on the law where you work. This guide is not legal advice: for large or regulated engagements, have your agreement reviewed by a lawyer in your jurisdiction.