How to Write a Scope of Work

A scope of work defines what you will deliver, when you will deliver it, and what is not included. It is the section of a contract that does the most work, and the one that causes the most problems when it is vague.

The usual failure is not a missing SOW. It is a SOW that describes the work in terms too general to be useful. "Design and develop a website" is a project description, not a scope of work. It does not tell either party what "done" looks like, how many revisions are included, or what happens when the client asks for something that was not discussed.

Why Scope of Work Documents Fail

Most scope disputes trace back to one of three problems:

The deliverables were described in general terms. "Website redesign" can mean anything from a homepage refresh to a 50-page rebuild with custom functionality. When the deliverable is vague, the client fills in the gaps with their expectations and the provider fills them in with their assumptions. These rarely match.

Exclusions were not stated. When only inclusions are listed, every new request becomes a debate about whether it was "implied" in the original scope. Listing exclusions explicitly makes these conversations straightforward: "That is listed as out of scope. We can add it with a change order."

The client's responsibilities were not defined. Projects stall because the client did not provide content, feedback, or access on time. If the SOW does not define what the client owes and when, the provider has no basis for adjusting the timeline when inputs are late.

Start With the Project Overview

Open with two to three sentences describing what the project is, why it exists, and what success looks like. This is not a summary for lawyers. It is a shared reference point that keeps everyone oriented when details get granular.

A project overview like "Redesign the company's public-facing website to improve lead conversion, reduce bounce rate, and align the visual identity with the 2026 rebrand" gives the deliverables section a foundation. Every item in the SOW should trace back to this purpose.

Define Deliverables Precisely

Each deliverable should be specific enough that both sides can agree, without ambiguity, on whether it was delivered.

Weak: "Website" Strong: "5-page responsive marketing website (Home, About, Services, Case Studies, Contact) built on Next.js, including mobile-responsive design, contact form integration, and basic analytics setup"

Weak: "Brand guidelines" Strong: "Brand guidelines document covering logo usage (primary, secondary, monochrome), color palette (primary, secondary, accent with hex/RGB values), typography (headings, body, captions), and voice and tone direction"

The discipline of writing specific deliverables forces clarity about what the project actually includes. If you cannot describe a deliverable precisely, the scope is not defined yet.

Set Acceptance Criteria

For each deliverable, define what "done" means and how the client will confirm it:

• How many revision rounds are included (two rounds is a common default)
• What the review period is (five business days is standard)
• What happens if the client does not respond within the review period (deemed accepted is a reasonable default)
• What constitutes a revision versus a new request (revisions refine existing work within the agreed scope; new requests add to it)

Without acceptance criteria, deliverables stay in an open-ended revision cycle that neither party planned for.

List Exclusions

This section prevents more disputes than any other part of the SOW. State explicitly what the project does not include.

For a website project, typical exclusions might be: copywriting, photography, stock image licensing, ongoing maintenance after launch, SEO optimization beyond basic technical setup, third-party integrations not listed in the deliverables, and browser support beyond the latest two versions of major browsers.

The statement of work template includes a dedicated exclusions section. Filling it out forces the conversation about boundaries before the work starts, which is where that conversation is cheapest to have.

Define Client Responsibilities

The SOW should specify what the client must provide and when:

• Content and copy by specific dates
• Access to systems, platforms, and tools
• Feedback within agreed review periods
• A designated point of contact with decision-making authority
• Timely approval at milestones

Critically, define what happens to the timeline when client inputs are late. A standard clause: "Project timelines will be extended day-for-day for any delay in client-provided materials or approvals." This protects your schedule without being adversarial.

Structure the Timeline With Milestones

Break the project into phases with dates and deliverables attached to each one. Milestones create checkpoints where both sides can confirm alignment and where payments are often tied.

A typical milestone structure:

1. Kickoff and discovery (Week 1) · Requirements confirmed, access collected
2. Design (Weeks 2-3) · Wireframes and visual concepts delivered, client review
3. Development (Weeks 4-6) · Build against approved designs, staging review
4. Review and revisions (Week 7) · Client feedback incorporated
5. Launch (Week 8) · Final delivery and handoff

Each milestone should include a review period. Without one, the project timeline stretches indefinitely while feedback sits in someone's inbox.

Include a Change Order Process

Scope changes are inevitable. The question is not whether they will happen but how they are handled when they do.

A change order process defines:

• How out-of-scope requests are submitted (in writing)
• How impact is assessed (timeline and cost)
• Who approves the change and how
• When work begins (after written approval, not before)

This process protects both sides. The client gets a clear picture of the cost before committing. The provider does not absorb uncompensated work. And the original scope remains intact as a reference point.

Start From a Template

The statement of work template on InkDraft includes all of these sections: project overview, deliverables, acceptance criteria, exclusions, responsibilities, milestones, and change orders. Start from it, adjust the specifics to your engagement, and the structure will keep the scope conversation grounded.