Scoping work and writing a statement of work

0:00 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.

0:42 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.

1:16 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.

1:51 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.

2:34 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.

3:17 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.

4:04 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.

4:40 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.

5:30 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.

6:16 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.

7:06 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.

7:49 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.

8:13 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.