Scope of Work Example: One That Survives the Client

The scope of work for the founder video was two sentences long: a 90-second brand film for the homepage, delivered as an MP4. Everyone signed off on it in under a day, which felt at the time like a good sign. It took four rounds of picture-lock notes, two client stakeholders who had never seen each other's comments, and a six-week gap between "final cut delivered" and the invoice actually going out, before it became clear that two sentences had never said what happens after delivery, how many rounds of notes were included, or who was allowed to send them.

None of that was a contract problem. The contract — governing law, payment terms, IP assignment — was fine. The scope of work underneath it was the part nobody had written, and it turned out to be the document actually running the project.

A statement of work does one job that a proposal and a contract don't do on their own: it turns a description of the project into a test. Not "make a great video," which nobody can fail and nobody can pass, but a list of things that either happened or didn't. Delivered as an MP4 at 1920x1080, with two rounds of revision included, reviewed within five business days of each cut. That sentence can be checked. "A great video, per discussion" cannot, and an invoice sitting behind an unchecked sentence is an invoice with no due date, whatever the payment terms say.

What a scope of work is doing that a proposal isn't

Freelancers who write proposals for a living tend to have a fairly settled structure for them, and it is worth borrowing even outside design work. AIGA's model agreement for design services — which, despite the name on it, is one of the few widely circulated freelance templates that spells out its mechanics instead of leaving them implicit — describes a typical proposal as covering an overview of the client's situation, a description of the scope of work and the specific objectives for the project, the recommended process broken out by phase (what's included and what isn't in each one), the deliverables and milestones, the number of creative directions and revision rounds included, the delivery format, the timeframe, a fee and expense breakdown, and the client's own responsibilities (AIGA, Standard Form of Agreement for Design Services, 2022 update, read 19 August 2026). Everything before "deliverables" in that list is sales. Everything from "deliverables" on is the scope of work, whether or not it lives in a separate exhibit.

The proposal's job is to get signed. The scope of work's job is to get referenced — by you, when you decide whether a request is included; by the client, when they decide whether to pay; and, if it ever gets that far, by whoever reads the file after both of you have stopped being reasonable about it. A proposal that reads beautifully and a scope of work that reads vaguely produce the same outcome every time: the vague document is the one an argument gets fought over, because it's the only one either side can quote.

The four pieces that make a scope of work enforceable

Most SOWs describe outputs. Far fewer describe the conditions those outputs have to meet before an invoice is owed. Four sections do that work, and a scope of work missing any one of them is missing the part that actually protects the money.

Deliverables: format, quantity, method, and a standard

"Three social posts" is an output. It is not yet a deliverable, because nothing in it can be checked. A deliverable needs four things attached to it: the format and file type (a 1080x1080 PNG, a ProRes 422 HQ master, a 1,200-word draft in a shared Google Doc), the quantity (three, not "a few" or "several"), the delivery method (uploaded to a named folder, sent via a specific platform, handed off through a portal), and a standard the work has to meet before it counts as finished. That standard is the part clients' own paper is worst at — "to the client's satisfaction" is not a standard, because satisfaction has no ceiling and no test. "Formatted to the brand guidelines provided on [date]" is, because it points at something that already exists and can be compared against.

Silence here is not neutral. A deliverables section that lists three logo concepts and says nothing else is read by most clients as covering revisions, source files, and any format they might need later — not because the SOW says so, but because it doesn't say otherwise. The nine clauses that decide whether you get paid covers the same gap from the contract's side, in the clause usually labelled deliverables schedule; this is the document that clause is pointing at.

Acceptance: the window, and the default it resolves to

This is the piece that decides whether the rest of the scope of work means anything. Three shapes show up in practice. Acceptance on delivery is simplest for you — you send the work, the review period (if any) is a courtesy, not a gate. Acceptance on client sign-off is the common one, and its entire value depends on what happens if nobody signs off. Acceptance on a client's own client's approval hands the trigger to a company you have no agreement with at all, and it belongs nowhere near a freelance SOW.

Write the review period as a number of days, name what starts it (receipt of the deliverable, not "the meeting" or "when they get around to it"), and write the default: if the client does not respond in writing within that window, the deliverable is treated as accepted. AIGA's own template uses five business days from receipt of each deliverable, requires written objections that identify the specific failure against the specifications in the proposal, and states plainly that in the absence of such notice the deliverable is deemed accepted (AIGA, Standard Form of Agreement for Design Services, section 4.4, read 19 August 2026). That single sentence is doing more for your cash flow than almost anything in the payment terms clause, because payment terms only start counting once acceptance has happened — a point covered from the invoicing side in what the invoice clock counts from.

Also write what a rejection has to contain. A client should have to say, in writing, which deliverable failed and against which line in the scope of work. "This doesn't feel right yet" is not a rejection a scope of work should have to honour; it's a request for a change order, which is a different document with a different price.

Assumptions: what has to stay true for the price to hold

A price is a bet on conditions that are outside your control: that the client provides brand assets by a stated date, that feedback comes from one named person rather than a committee, that the content the client is supplying is close to final when it arrives, that a certain platform's current version is what the work is built for. None of that belongs in the deliverables list, because none of it is something you're delivering. It belongs in an assumptions section, stated plainly enough that when one of them turns out to be false, everyone can see it without an argument.

This section is the quietest one in most SOWs and the most expensive to leave out. "The client will provide final copy for the landing page by [date]" sounds like paperwork until the copy arrives three weeks late, the launch date doesn't move, and the design phase gets compressed into the time that was supposed to be used for revisions. With the assumption written down, the compressed timeline is the client's consequence. Without it, it reads as your delay.

Exclusions: what a client will ask for anyway

Whatever isn't listed as included tends to get read generously by whoever is paying — which is another way of saying it gets read as included. An exclusions section closes that gap directly: source files, ongoing hosting, revisions after the acceptance window has closed, translation into other languages, print production, anything outside the platform or format named in the deliverables section. None of it needs to be dramatic. "Excludes: source files in editable formats; social crops beyond the three sizes listed above; any revision requested after written acceptance" is a complete exclusion for a lot of small design jobs, and it is the sentence that turns "can you just also send me the layered file" into a billable request instead of an assumed freebie.

A short scope of work, annotated

Here is roughly what the founder-video job's scope of work should have said, next to what it actually said.

Four of those five rows didn't exist in the version that got signed. The deliverable line was the only one written with any specificity, which is common — deliverables get attention because they're the part a client is picturing when they say yes. The other four rows are the part that decides whether picturing the video and paying for the video turn out to be the same event.

Where the scope of work sits in the stack of paper

On a lot of freelance jobs the scope of work is not its own document at all — it's a section of the proposal, or an exhibit labelled "Statement of Work" or "Schedule A" attached to a short master agreement. Either placement works. What matters is that the paper says which document controls when two of them disagree, because at some point one will. A change order that isn't cross-referenced against the original scope of work, or a verbal "yes, that's fine" layered on top of a written exclusion, creates exactly the kind of conflict the nine clauses that decide whether you get paid covers under order of precedence and entire-agreement language — the contract clause that says which paper wins.

A scope of work that has never been updated to reflect what actually happened on a job is a liability in its own right, incidentally. If a client emailed three change requests over four months, agreed a price for each over email, and none of it was ever folded into the SOW, you are left trying to reconstruct the deal from a thread instead of pointing at one current document. It's worth an hour every few weeks, on any job running longer than a month, to fold agreed changes back into the SOW itself rather than letting the email thread become the real one.

The line between "extra" and "included"

The exclusions section does most of the work of catching scope creep before it starts, but requests still arrive that weren't anticipated by name. The test that decides whether something is billable is simple to state and harder to hold to in the moment: does it match a deliverable, at the quantity and standard already specified, within the acceptance window already agreed? If yes, it's included, however annoying it is to redo. If no — a new platform, an extra format, a fourth round of notes after two were priced — it's outside the scope of work as written, and the response is a document, not a favour.

AIGA's framing of that document is useful precisely because it keeps the size proportionate: a change order is treated as a short, self-contained record that names the additional time or cost, references the original proposal, and states that the same terms and conditions apply, invoiced as the added work is completed — while anything approaching a substantial revision to the scope or value of the job is treated as needing a fresh, separately signed proposal rather than a quick addendum (AIGA, Standard Form of Agreement for Design Services, read 19 August 2026). A one-line email confirming an extra deliverable and its price, replied to by the client, meets that bar for small requests. What doesn't meet it is doing the work first and hoping the invoice explains itself later.

What the acceptance line does to your invoice

Net terms only start once there's something for them to count from, and for most freelance work that something is acceptance, not delivery. A scope of work with no acceptance clause leaves the payment terms with nothing to attach to — thirty days from an event that was never defined is not a deadline, it's an argument waiting to happen, which is the exact mechanism walked through in what the invoice clock counts from. Writing the acceptance window into the scope of work, with a default that resolves in your favour when nobody responds, is the cheapest fix available to that problem, and it costs nothing to negotiate because on the client's side it reads as routine process rather than a concession.

If a job stalls anyway — acceptance never comes, notes never consolidate, an invoice sits with no formal rejection and no payment either — that's no longer a scope of work question. It's the point where the collections ladder starts, and the paper trail a well-written scope of work leaves behind (dated deliveries, a defined review window, a record of silence) is exactly what makes the first rungs of that ladder short instead of long.

A scope of work this specific can feel like overkill on a two-week job, and for some two-week jobs it probably is. It stops feeling like overkill the first time a client asks, three months in, what was actually agreed — and the honest answer is a document, not a memory of the call where it came up.