---
title: "Scoping work and writing a statement of work"
description: "Clear scope prevents most disputes Many client conflicts begin with different assumptions about what was included. A clear statement of work (SOW) or…"
url: https://optimizeall.com/learn/negotiation-and-client-management/scoping-and-sow
updated: 2026-10-05
---

Negotiation & Client Management · Scoping, change requests and contracts · lesson 10 of 18 · 14 min

# Scoping work and writing a statement of work

## Clear scope prevents most disputes

Many client conflicts begin with different assumptions about what was included. A clear **statement of work (SOW)** or scope document aligns expectations before work starts and gives both sides a reference when questions arise.

## The discovery conversation

Before scoping, understand:

- **Objectives:** What business outcome does the client want?
- **Deliverables:** What tangible outputs are needed?
- **Constraints:** Budget, deadlines, brand guidelines, technical systems, regulations.
- **Stakeholders:** Who approves? Who provides input?
- **Success criteria:** How will the client judge success?
- **Assumptions and dependencies:** What must the client provide (content, access, approvals)?

## SOW structure

```
Statement of Work (illustrative)
1. Background and objectives
2. Scope: deliverables with specifications
   - 1 homepage + 6 inner pages, responsive design
   - Copy provided by client; agency edits for SEO (up to 1 round)
   - Integration with existing payment gateway (client provides credentials)
3. Exclusions (explicitly out of scope)
   - Photography and video production
   - Content writing beyond SEO edits
   - Integration with ERP or third-party systems not listed
4. Timeline and milestones (with client dependencies)
5. Review and acceptance process
   - 2 revision rounds per deliverable; feedback consolidated from one client contact within 5 working days
   - Acceptance: deliverable deemed accepted if no written feedback within 10 working days
6. Roles and responsibilities (client and provider)
7. Assumptions and dependencies
8. Fees, payment schedule and expenses
9. Change request process
10. Signatures
```

## Writing good deliverables

Specify quantity, format, standard and acceptance criteria. Compare:

| Vague | Specific |
|---|---|
| "Social media content" | "12 static posts and 4 short videos (up to 30 seconds) per month for Instagram and LinkedIn, in English and Arabic" |
| "Website" | "Responsive website of 7 pages on the client's CMS, meeting agreed accessibility standard, tested on current Chrome, Safari and Edge" |
| "Unlimited support" | "Up to 5 hours of support per month, response within 1 working day" |

## Exclusions are as important as inclusions

Listing what is **not** included prevents the most common disputes. Anticipate likely assumptions: content, photography, hosting, licences, translations, training, ongoing maintenance, third-party costs.

## Client responsibilities and dependencies

Many delays come from the client side: late content, slow approvals, missing access. State these dependencies and what happens if they slip (timeline shifts, possible additional costs). This is fair, not adversarial; it helps both sides plan.

## Acceptance process

Define how deliverables are reviewed and accepted: number of revision rounds, consolidated feedback from one decision-maker, timeframes and deemed acceptance. This prevents endless loops of feedback from multiple stakeholders.

## Worked example

*Illustrative.* A branding agency in Riyadh previously used one-paragraph proposals. A client expected brand guidelines, stationery, social templates and signage designs, all "part of branding". The agency lost money on the project. It introduced a structured SOW with deliverables, exclusions and a two-round revision process. On the next project, when the client asked for signage designs, the agency pointed to the exclusions and offered a priced change request, which the client accepted without friction.

## Hands-on: scope questions to ask before writing the SOW

```text
Outcome:      What must be true at the end for this to be a success? How will we measure it?
Deliverables: What exactly will you receive? Formats, quantities, languages, platforms?
Boundaries:   What is explicitly NOT included? (ad spend, copywriting, photography, legal review...)
Inputs:       What will you provide, and by when? Who approves? How many reviewers?
Constraints:  Deadlines, budget, brand rules, compliance (health/finance claims), accessibility?
Change:       How should we handle new ideas mid-project?
AI:           Any restrictions on AI tools or client data?
Acceptance:   How will we confirm each deliverable is done?
```

## Hands-on: deliverable specification table

| Deliverable | Specification | Quantity | Acceptance criteria | Due |
|---|---|---|---|---|
| Landing pages | Responsive, English + Arabic, CMS-editable | 3 | Pass QA checklist; client approval or 5 working days' silence | Week 4 |
| Blog articles | 1,200 words, SEO brief, 2 images each | 4 | Brief met; 1 revision round within 3 days | Weeks 3-6 |
| Analytics setup | GA4 events for form and call clicks | 1 | Test events visible in reports | Week 2 |

## Using AI to draft an SOW (carefully)

An assistant can turn call notes into a first-draft SOW and suggest exclusions you may have missed. Then you check every line: AI may invent deliverables you never discussed, or copy generic clauses that don't match your jurisdiction. Prompt example:

```text
From these anonymised notes, draft an SOW with: objective, deliverables (with specification,
quantity and acceptance criteria), exclusions, assumptions, client responsibilities,
timeline, revision policy and change process. List anything ambiguous as a question for me.
Do not add deliverables that are not in the notes.
```

## Common mistakes

- One-line scopes ("design a website").
- No exclusions.
- Undefined revision rounds.
- Ignoring client dependencies.
- Starting work before the SOW is signed.

## Quick self-check

Take your most recent project. Could a neutral third party read the scope and agree on exactly what was included and excluded? If not, rewrite it using the SOW structure.

## Using templates and AI carefully

Build a reusable SOW template for your most common services so scoping is faster and more consistent. AI writing assistants can help draft scope descriptions and exclusions from your notes, but review every line carefully: the SOW becomes a commitment, and generic or inaccurate text can create obligations you did not intend. Never paste confidential client information into tools your organisation has not approved.

## Getting the client to engage with the scope

Walk the client through the SOW in a short call rather than just emailing it. Explaining the exclusions and acceptance process in person surfaces misunderstandings early and signals that you take clarity seriously.

## Quick self-check

Ask yourself: if a new team member read this SOW, could they deliver the project correctly without asking you what was meant? If not, add detail.

## Video lecture: Scoping work and writing a statement of work

Lecture coming soon · 13 chapters · about 9 minutes. Read the full transcript below.

1. Scoping and the statement of work
2. Why it matters
3. The tailor analogy
4. Scope discovery
5. SOW structure
6. Worked example 1: Grace in York (illustrative)
7. Exclusions
8. Worked example 2: Layla in Dubai (illustrative)
9. Watch me: AI-drafted SOW
10. Acceptance in practice
11. Getting engagement
12. Common mistakes
13. Recap and try this now

## Lecture transcript

### Scoping and the statement of work

Most client disputes aren't about quality. They're about expectations that were never written down. The client thought a website included the copy. You thought they'd write it. The client thought two revision rounds meant two rounds per page. You meant two rounds in total. In this lecture, you'll learn to scope work so these arguments never start: the discovery conversation, the structure of a statement of work, how to write deliverables, why exclusions matter as much as inclusions, client responsibilities, the acceptance process, and how to use AI to draft an SOW without letting it invent promises.

### Why it matters

Why does this matter? Because a clear scope is the foundation for everything else in this course: your price, your timeline, your change requests and your contract. If scope is vague, every later negotiation is harder, and every extra request becomes an argument about what was meant. Here's the key idea. Scope is a negotiation too. Agreeing precisely what's in, what's out and what counts as done is one of the most valuable conversations you'll have with a client.

### The tailor analogy

Here's an analogy. Think of ordering a custom suit. A good tailor doesn't just say, one suit, coming up. They agree the fabric, the cut, the number of fittings, the lining, the buttons, the delivery date, and what happens if you want changes after the second fitting. They also tell you what's not included, like shirts and alterations after collection. Because it's all agreed, you both know exactly what done looks like. A statement of work is your tailor's order form.

### Scope discovery

Let's start with discovery for scope. Ask about the outcome: what must be true at the end for this to be a success, and how will we measure it? Then deliverables: formats, quantities, languages and platforms. Boundaries: what's explicitly not included? Inputs: what will the client provide, by when, and who approves? Constraints: deadlines, budget, brand rules and compliance, such as health or financial claims. How should new ideas be handled mid-project? Any restrictions on AI tools or client data? And acceptance: how will we confirm each deliverable is done? The full question list is in the lesson.

### SOW structure

Now the SOW structure. An objective in one sentence. Deliverables, each with a specification, a quantity, acceptance criteria and a due date. Exclusions, explicitly. Assumptions, like the client supplying copy by week two. Client responsibilities, such as approvals within three working days and a maximum number of reviewers. A timeline, with the rule that late inputs move dates. A revision policy that defines what a revision is. A change process. And acceptance: how deliverables are approved, and deemed acceptance if there's no response within, say, five working days. Write deliverables so a stranger could check whether they were met.

### Worked example 1: Grace in York (illustrative)

A simple worked example, illustrative. Grace, a web designer in York, agrees to build a site for a small hotel. Her old scope said: website design and build. Her new SOW says: a responsive seven-page site on the hotel's chosen content system, with a booking widget integration using the hotel's existing booking provider. Excluded: copywriting, photography and paid ads. Assumptions: the hotel supplies text and photos by week two. Two revision rounds per page template, defined as changes within the approved design. Acceptance: approval by email, or deemed accepted after five working days. The hotel owner says it's the first time a supplier has been this clear.

### Exclusions

Let's focus on exclusions, because they're as important as inclusions. Clients fill gaps with assumptions, usually generous ones. So write down the things they might expect but you're not providing. Copywriting. Photography. Ad spend. Hosting fees. Legal or medical review of claims. Translation. Ongoing maintenance after launch. Training for their team. Each exclusion you write now is an argument you won't have later. And it's not negative. You can phrase it helpfully: not included, but available as an add-on at this price.

### Worked example 2: Layla in Dubai (illustrative)

Now the realistic scenario, illustrative. An agency in Dubai, run by Layla, scopes a bilingual campaign for a skincare brand. In discovery, she learns that product claims must follow health advertising rules, that three people on the client side will review everything, and that the client doesn't want customer data in AI tools. Her SOW specifies: twelve social posts and three short videos in Arabic and English, a maximum of two consolidated feedback rounds from one named approver, claims supplied or approved by the client's regulatory lead, and no customer data processed with AI tools. Exclusions include paid media and influencer fees. The campaign runs on time, because every risky assumption was surfaced and written down.

### Watch me: AI-drafted SOW

Watch me draft an SOW with AI, safely. I paste my anonymised call notes into an assistant on a business plan, with the prompt from the lesson: draft an SOW with objective, deliverables with specification, quantity and acceptance criteria, exclusions, assumptions, client responsibilities, timeline, revision policy and change process. List anything ambiguous as a question. Don't add deliverables that aren't in the notes. It produces a solid draft, and flags that I haven't specified languages for the videos. Useful. But it also suggests a monthly analytics report I never discussed. I delete it. Then I check every clause against my notes and my contract template.

### Acceptance in practice

Let's go deeper on acceptance, because it's the clause that makes projects actually finish. For each deliverable, define objective acceptance criteria: passes the QA checklist, matches the approved design, works on the listed browsers, events visible in analytics. Then define the process. You submit the deliverable. The client has a set number of working days to approve it or list specific defects against the criteria. You fix genuine defects. And if the client doesn't respond in time, the deliverable is deemed accepted. That last part isn't a trick. It protects both sides from projects that drift for months because nobody signs anything off, and it's what lets you invoice the next milestone with confidence.

### Getting engagement

How do you get the client to actually engage with the scope, rather than skim and sign? Walk through it together on a short call, section by section. Ask them to confirm the exclusions out loud: so just to check, you'll handle photography and we'll use your existing images? Ask who else needs to see it. Make the deliverables table the centrepiece. And frame it positively: this is how we make sure you get exactly what you expect. Clients who have read and discussed the scope are much less likely to dispute it later, because they helped shape it.

### Common mistakes

Let's list the common mistakes. Vague deliverables like website or social media management. No exclusions. No client responsibilities, so delays become your problem. Undefined revisions. No acceptance process, so projects never officially finish. Copying templates without adapting them. Letting AI add deliverables you never agreed. And sending the SOW without walking the client through it.

### Recap and try this now

Let's recap. Scope is a negotiation, and a clear SOW prevents most disputes. Use discovery questions to surface outcomes, deliverables, boundaries, inputs, constraints and restrictions, including on AI. Write deliverables a stranger could check, list exclusions, set client responsibilities, define revisions and include acceptance with deemed acceptance. Use AI to draft, never to invent. Walk the client through it. Your try this now: rewrite your last project's scope as an SOW with a deliverables table, five exclusions and an acceptance clause. Next, we'll handle change requests and scope creep.

## Key takeaways

- A clear statement of work aligns expectations and prevents most disputes.
- Specify deliverables with quantity, format, standard and acceptance criteria.
- List exclusions and client dependencies explicitly.
- Define a review and acceptance process with limited revision rounds and consolidated feedback.
- Use AI to draft an SOW from your notes, but instruct it not to invent deliverables and check every line against what was agreed.

## Try it

Rewrite the scope for a recent or upcoming project using the SOW structure, including at least five explicit exclusions and a clear acceptance process.

- [Previous: Payment terms and protecting cash flow](https://optimizeall.com/learn/negotiation-and-client-management/payment-terms-and-cash)
- [Next: Change requests and scope creep](https://optimizeall.com/learn/negotiation-and-client-management/change-requests-and-scope-creep)
- [All lessons of Negotiation & Client Management](https://optimizeall.com/learn/negotiation-and-client-management)