Skip to main content

what a scope of work clause should include in freelance contracts

The scope of work clause is the single most important paragraph in your contract, because it defines the boundary that every other clause exists to protect. Its job is to state precisely what you will deliver, and — just as importantly — what you will not, so that any request landing outside that boundary is visibly a new conversation rather than an assumed part of the original deal. Most scope creep is not a client acting in bad faith; it is genuine ambiguity about where 'the project' ends, and ambiguity always resolves in the direction of more unpaid work. A strong scope clause closes that gap with a specific list of deliverables, an explicit list of exclusions, the assumptions the price depends on, and a change-order path that gives out-of-scope requests somewhere to go other than your free time. Written well, it does not make you rigid — it makes the next 'can you just' a quick, friendly reference to the document instead of an argument.

Anatomy of a strong scope-of-work clause

Deliverables list
A specific, countable enumeration of what the client receives — not 'a website' but 'a five-page responsive website comprising home, about, services, blog index, and contact, built in [platform].' Vague deliverables expand to fill whatever the client imagined, so the more concrete and numbered the list, the smaller the space for a request to claim it was always included.
Explicit exclusions
A short list of plausible adjacent work that is specifically not included — content writing, photography, ongoing maintenance, third-party integrations, additional pages. Exclusions feel awkward to write but do more to prevent disputes than the inclusions, because they name the exact 'while you're at it' requests before they arrive and give you a clean line to point at when they do.
Assumptions
The conditions the quoted price depends on — that the client supplies final copy by a date, that there is a single approver, that the brand assets exist. When an assumption fails, the scope and the price are no longer valid, and stating the assumptions makes that consequence visible. Without them, every delay and missing input quietly becomes your problem to absorb at the original fee.
Acceptance criteria
The definition of 'done' for each deliverable — what state it must reach for the client to accept it and the engagement to close. This prevents the project from drifting indefinitely toward an unstated ideal, because completion becomes a checklist the client signs off rather than a feeling of satisfaction that can always recede one more revision into the future.
Change-order path
The mechanism by which out-of-scope requests become paid additions — a brief description of how new work is quoted, approved, and scheduled. Its purpose is to give 'can you also' somewhere to go besides your evenings: a request outside the deliverables list is not refused, it is routed into a change order, which reframes the conversation from whether you'll do it to when and for how much.

Example language

Drop this into your contract and adapt the bracketed placeholders.

Scope of Work. The Contractor will deliver the following: [numbered list of specific deliverables, e.g., a five-page responsive marketing site comprising Home, About, Services, Blog index, and Contact pages]. The following are expressly excluded and available as separately quoted work: copywriting, photography or asset creation, third-party integrations, additional pages, and post-launch maintenance. This scope and fee assume the Client provides final content and brand assets by [date], designates a single approver, and that requirements remain as described in this agreement. A deliverable is accepted when it meets the criteria listed in [Schedule A]. Any work outside this scope will be documented in a written change order, quoted separately, and scheduled by mutual agreement before it begins.

Common mistakes

  • Describing deliverables in broad nouns — 'a website,' 'branding,' 'a campaign' — instead of a countable list. Broad nouns expand silently to whatever the client pictured, and you inherit the gap between your estimate and their imagination.
  • Listing what's included but never what's excluded. The exclusions prevent more disputes than the inclusions, because they pre-empt the specific adjacent requests before anyone has to argue about whether they were implied.
  • Leaving out the assumptions the price depends on. When the client delivers copy three weeks late or routes feedback through a committee, you absorb the cost silently because nothing in the contract said the price assumed otherwise.
  • Having no change-order path, so every out-of-scope request becomes a binary choice between doing it free or saying no. A change-order route turns refusal into rescheduling and pricing, which is a far easier conversation.
  • Defining no acceptance criteria, leaving 'done' as a feeling rather than a checklist. Without a finish line the client can sign, the project drifts toward an ideal that always sits one revision away.
  • Writing the scope once and never updating it as approved change orders accumulate. The original document stops describing the real engagement, and you lose the boundary you spent the contract establishing.
Settled reads your contract and gives you the exact verdict for this situation — try it free →

Frequently asked questions

What is the difference between a scope of work and a deliverables clause?+

They overlap heavily and are sometimes combined, but they answer slightly different questions. A deliverables clause is the precise inventory of the artifacts the client receives — the files, formats, page counts, and assets that change hands. A scope of work clause is broader: it includes that inventory but also frames it with the exclusions, assumptions, acceptance criteria, and change path that define the engagement's boundary as a whole. You can think of the deliverables list as the 'what you get' and the scope clause as the 'what we agreed the project is.' In a short contract you might fold deliverables into the scope clause; in a larger one you'd break the deliverables into their own detailed schedule and let the scope clause reference it. Either way, the function is the same — to make the edge of the project visible enough that stepping over it is obvious to both sides.

How specific should my deliverables list be?+

Specific enough that a request to add something cannot plausibly claim it was always included. The test is whether a neutral third party reading the list could tell, without asking you, whether a given task is inside or outside it. 'A website' fails that test; 'a five-page responsive site comprising Home, About, Services, Blog index, and Contact' passes it, because the sixth page is now visibly extra. Quantify everything you can — page counts, revision rounds, file formats, number of concepts, length of copy — because every unquantified noun is a place where the client's expectation and your estimate can quietly diverge. You do not need to make it exhausting; you need to make it countable. The specificity is not bureaucracy, it is the mechanism that lets you say 'that's a great idea, it's outside the five pages we scoped, here's what it would take' instead of silently eating the work.

Why bother listing exclusions if the deliverables already say what's included?+

Because human beings reason about boundaries from both directions, and the exclusions catch the requests the inclusions don't. A client reading a deliverables list does not mentally compute the complement of that set — they don't think 'this lists five pages, therefore content writing is excluded.' They think 'we're building a site, surely the copy is part of that.' Exclusions name the specific adjacent assumptions — copywriting, photography, maintenance, integrations — that clients most often fold into 'the project' without realizing they're separate. The few minutes it takes to list them saves the far longer conversation when the client expects something you never priced. In practice, exclusions are where experienced freelancers concentrate their attention, because they're the cheapest possible insurance against the most common form of scope creep: the genuinely held but never-stated assumption.

What should I do when a client asks for something outside the scope?+

Route it through the change-order path rather than answering yes or no on the spot. The reframe is the whole point: a request outside the deliverables list is not a favor to grant or refuse, it is new work to be quoted and scheduled, exactly like the original work was. So the reply is not 'no' and it is not 'sure' — it is 'happy to, that's outside the scope we agreed, let me write it up as a change order with a price and a timeline.' This keeps the relationship warm because you're saying yes to the work while saying that it has a cost, and it keeps your margin intact because the additional effort is now compensated. The clients who balk at paying for clearly additional work are signaling something useful about how the rest of the engagement will go, so the change order doubles as a quiet test of whether the relationship is healthy.

How do assumptions in a scope clause actually protect me?+

They make the price conditional, so that when a condition fails, the consequence is contractual rather than something you swallow. Your quote is built on a stack of assumptions you may not even consciously notice — that final copy arrives on a date, that one person approves, that the brand has usable assets, that requirements stay roughly as described. When the client supplies copy three weeks late or routes every decision through a committee of five, your effort balloons, and without stated assumptions you absorb that cost in silence. With them, the clause lets you say 'the timeline and fee assumed final copy by the first; it arrived on the twenty-first, which shifts the schedule and the price.' You're not being difficult — you're pointing at a condition both sides agreed to. Assumptions convert the invisible costs of client-side delay and disorganization into visible, attributable scope changes.

Related reading

Answer scope creep from your actual contract — not a template.

Settled reads your contract and the client's request, gives you a verdict (In Scope / Out of Scope / Ambiguous), and drafts the email grounded in your specific clause.

Try it free →Read the scope creep guide