How to write a scope of work clients can't misread.

A scope of work is the part of your agreement that says exactly what you'll deliver, what sits outside the fee, and how both sides will know when something is finished. Writing one takes seven sections: a short background, the deliverables with an acceptance condition on each, a timeline with the client's own obligations attached, priced exclusions, a revision limit, the change path, and the payment schedule. Laying out those sections takes about twenty minutes. Everything after that goes into making each line specific enough that two people reading it in month three reach the same answer, which is the only part that decides whether the document was worth writing.

Almost every guide on this subject stops at the section list. You get nine steps, a paragraph telling you to be specific and detailed, and an example built around a parking lot or a municipal sidewalk project where nobody is paying you and no fee is at risk. What none of them show you is the sentence itself: the difference between the line an agency actually types at eleven at night and the line that survives a client saying they assumed the mobile version was included. That gap is where the money goes, so this walks through the seven sections with both versions written out and real dollars attached.

The running example is a nine week brand and website project at a fixed fee of twenty eight thousand dollars, with a blended rate of $150 an hour. Every figure below is example arithmetic on that project rather than an industry statistic, so you can swap your own numbers in and the logic still works.

When do you actually need a scope of work?

You need a real one on any engagement where the fee is fixed and the work is open to interpretation, which describes nearly everything an agency sells. Hourly work needs it less, because an ambiguity that costs you fourteen hours simply appears on the next invoice as fourteen hours. On a fixed fee, that same ambiguity comes straight out of your margin. Three unpriced additions of roughly fourteen hours each on our example project add up to 42 hours, or $6,300 at the blended rate, against a margin of $8,400 if you priced the job at a thirty percent margin. You can lose three quarters of the profit on a project to three conversations that each felt too small to charge for.

The short version of the definition is that a scope of work describes the work itself: what gets built, what gets handed over, and where your responsibility ends. If you want that unpacked properly, including where it sits relative to a contract and what it decides when a client asks for something it never named, what a scope of work actually is covers it separately, and the rest of this page assumes you already know.

What goes into a scope of work?

Seven sections cover an agency project properly, and the order matters because each one narrows the one before it. Background and objectives come first, in two short paragraphs that explain what the client is trying to achieve, so that anyone reading it later understands why a deliverable exists. Then the deliverables themselves, each countable and each carrying a done-when condition. Then the timeline, written so that every date depends visibly on something the client owes you. Then exclusions, with a price and a lead time next to each. Then the revision limit, then the change path, then the fee and payment schedule.

Larger engagements with several stakeholders also benefit from a short roles section naming who approves what, because the person with opinions and the person with authority are frequently not the same human being. Beyond that, most of what fills up longer templates is padding. Work breakdown structures, assumption registers and reporting cadences all have their place inside a big organization running a program of work, and almost none of it helps a six person agency get paid for an extra page template.

How do you write deliverables a client can't reinterpret?

Make every deliverable countable and testable. Countable means a number appears in the line, so that "five pages" replaces "a website" and "ten migrated posts" replaces "content migration". Testable means the line ends with a condition somebody could check without a conversation, which is the piece almost every template describes in the abstract and never demonstrates. Acceptance criteria get a whole section in the guides that currently rank for this term, and not one of them writes a single acceptance criterion out in full.

The second version is longer and it's still one sentence per deliverable, so a full scope with eight deliverables runs about a page. What it buys you is that "clean, modern look" no longer has to be negotiated in week seven, because nothing in the line depends on a taste judgment that only one party can make. A done-when condition also gives you the moment where a deliverable stops being your problem, which matters enormously on a fixed fee, since without it a page can be revisited indefinitely and every revisit is unpaid.

Write the condition so it can be verified by someone who wasn't in the room. "Approved by the client" is weaker than it looks, because approval by whom and in what form immediately becomes the argument. Naming the approver and the form fixes it, and that same named approver is what makes an approval trail hold up later when a junior coordinator signs off on something the founder never saw.

A deliverable nobody can test is a deliverable nobody can finish.

What should the exclusions section actually say?

It should name the things clients most often assume are included, and it should put a price and a lead time on each one rather than simply refusing them. Every competing article treats exclusions as a list of nos, which is both worse for the relationship and worse for your revenue. A priced exclusion is a menu. It tells the client the work is available, tells them what it costs before they've emotionally committed to getting it for free, and converts the awkward week-six conversation into a purchase they were already prepared for.

Notice that two of those lines carry a delivery impact as well as a price, because the date is often the thing the client cares about more than the money. An extra page that costs $1,600 sounds cheap to somebody who hasn't been told it moves the launch by three business days. Attaching both numbers to the exclusion means you never have to break that news mid-project, and it's the same discipline that keeps the small requests that arrive on every project from quietly becoming free work.

How many revision rounds should the scope include?

Two rounds per deliverable is the common structure on agency work, with a defined rate for anything past that. What matters more than the number is defining what a round is, because a round that isn't defined becomes a stream of individual comments arriving over eleven days. Write it as consolidated feedback delivered in one document within a stated window, and state that comments arriving after that window belong to the next round.

Put the overage rate in the exclusions block rather than burying it in a paragraph, so the client sees the cost of a third pass before they ask for one. On the example project a third round of homepage revisions typically runs about six hours, which is $900 at the blended rate. That's a number worth showing, because a client comparing $900 against "one more small tweak" almost always tightens their feedback instead, and you've avoided the work rather than merely billed for it.

Be honest with yourself about where extra rounds come from. Some of them are genuine client indecision and belong on an invoice. Plenty of others come from an agency showing work too early, or from a scope line vague enough that the client's expectation was never wrong in the first place. Those ones you absorb, and then you fix the wording for the next project.

What protects you when the client misses their own deadline?

A dependency clause does, and it's the section almost nobody includes. Your timeline assumes the client returns feedback, assets, copy and access on schedule, and when they don't, the delivery date silently becomes your problem instead of theirs. Writing the dependency into the scope moves that risk back where it belongs without a single confrontational conversation, because you agreed the mechanism months before you needed it.

That last sentence is the one that does the heavy lifting, and it's also the one clients push back on. It's worth keeping, because a three week silence genuinely does cost more than three weeks: the team gets assigned elsewhere and getting them back is a scheduling problem rather than a switch you flip. Saying so plainly in the scope is far easier than explaining it for the first time while the client is annoyed about a launch date.

What happens when someone asks for work the scope doesn't cover?

The scope should answer that question itself, in one short clause that names the process and the person who can approve it. Without that clause every out-of-scope request becomes an individual negotiation conducted by whoever happens to receive the message, which is usually a designer with no authority to quote anything and every incentive to say yes.

Four sentences of setup at kickoff make that clause feel normal rather than legalistic, and the conversation is short enough to have in the first meeting. Explaining early that changes are welcome and simply get priced does more for you than any wording in the document, which is why the kickoff conversation matters more than the wording itself. Once the client expects a quote, the quote stops feeling like a complaint. If you want the request captured in a consistent shape rather than as scattered emails, a change request form gives you one place where the ask, the price and the date impact all get written down together.

Is a scope of work legally binding?

On its own, generally not, because it describes work rather than creating obligations between named parties. It becomes meaningful once a signed agreement references or attaches it, and that agreement is what identifies who is contracting, what the fee is, and which terms govern the relationship rather than the project. You will see it asserted plainly that these documents are legally binding on their own, and that assertion is worth ignoring.

We build software rather than practice law, so treat all of this as background and ask a lawyer in your own jurisdiction before relying on it. What we can say from watching a lot of these disputes is that they rarely reach anyone's lawyer at all. They get settled by whoever produces a clearer record of what was agreed, which means the practical value of your scope has more to do with how specifically it's written than with its legal status.

The four lines that do most of the work

If you only tighten four things in your next scope, tighten these. Put a number in every deliverable so it can be counted. End every deliverable with a done-when condition somebody outside the project could verify. Give every likely exclusion a price and, where relevant, a lead time. Name one approver and state that work starts on their written yes and nobody else's.

Those four changes take an afternoon to apply across your standard document and they remove most of the ambiguity that turns into unpaid work later. Everything else in a scope of work is useful, and none of it is load-bearing in the same way. If you'd rather start from something already filled in, a complete project scope with the numbers in place saves you the blank page, and handling the requests that arrive anyway is the other half of the job, because no document written in week one anticipates everything week seven produces.

Frequently asked questions