How to Write a Scope of Work (SOW) - Template + Examples

A clear Scope of Work prevents 90% of client disputes. Here's how to write one that protects you and sets clear expectations.

Scope of Work Template

Essential SOW Sections

1. Project Overview - 2-3 sentences describing the project goal and context.
2. Objectives - Bulleted list of specific objectives.
3. Deliverables - Table with deliverable, description, format, and due date.
4. What's Included - Specific services/items, number of revisions included.
5. What's NOT Included (Critical!) - Out-of-scope items. Additional work quoted separately.
6. Timeline - Phases with descriptions, start dates, end dates.
7. Client Responsibilities - What you need from the client: access, content, approvals, response times.
8. Budget - Total and payment schedule.
9. Change Request Process - Changes documented in writing, approved by both parties, may adjust timeline/budget.
10. Acceptance - Signature lines for both parties.

A Scope of Work Is a Fence, Not a Wish List

The purpose of a scope of work is to make it obvious, months later and to people who were not there, what was included and what was not. Every dispute about a project traces back to a sentence somebody read two different ways. A good SOW is written specifically to be hard to misread.

The Out-of-Scope Section Is the Most Valuable Part

Most scopes list what is included and stop. The section that saves the relationship is the one listing what is not. It costs you nothing to write and it prevents the conversation where a client believed something was covered and you believed it obviously was not.

Write it plainly: "Not included: content writing, photography, hosting fees, third-party license costs, migration of data older than 24 months, training beyond the two sessions listed above." Nobody is offended by a clear boundary agreed in advance. They are offended by an invoice that arrives after the fact.

Deliverables Need a Definition of Done

"Website" is not a deliverable. "Five-page WordPress site on the client's hosting, responsive at mobile and desktop, with the contact form delivering to one named address, accepted after one round of revisions" is a deliverable, because there is a moment where everyone agrees it exists.

For each item, state the format, the quantity, and the acceptance condition. If acceptance depends on someone's judgment, name whose judgment and how long they have to exercise it.

Assumptions Are Where Schedules Die

Almost every late project is late because something the vendor assumed would arrive did not. Write the assumptions down and attach consequences:

• "Client provides final copy by [date]. Each week of delay moves the delivery date by one week."
• "Client provides one named decision-maker for approvals."
• "Client provides admin access within three business days of kickoff."

This is not defensiveness. It is the only fair way to be judged on a schedule you do not fully control.

Change Orders, Written Before You Need One

Decide in the SOW how a change gets handled, because the moment you need that process is the worst possible moment to invent it. A workable version: any request outside the deliverables list gets a written estimate of hours and cost, and no work starts until the client approves in writing. It sounds bureaucratic and it takes about four minutes per change. It is the difference between a profitable project and a project you resent.

Payment Tied to Milestones, Not Calendar Dates

Tie payments to deliverables that you control, not to dates that depend on the client's review speed. "50% on acceptance of design" is better than "50% on October 15," because you can be ready on time and still not be paid if the client is slow.

The Checklist Before Anyone Signs

• Are all deliverables countable and defined?
• Is there an explicit out-of-scope list?
• Are assumptions written down, with consequences?
• Is there a named process for changes?
• Is the number of revision rounds stated?
• Do payment triggers depend on things you control?
• Is there a named contact on each side?
• Does the schedule have an actual start condition, not just an end date?

These are drafting practices, not legal advice. Have an attorney review any agreement you intend to rely on.