How to Write a Scope of Work (Section by Section)

If you want to know how to write a scope of work that holds up, write every line so someone who wasn't on the sales call could tell whether a new request is included. That means numbers on deliverables, a plain "not included" list, revision and hour limits, what you need from the client, dates, and a rule for extras.

This guide goes section by section, then shows how to rewrite the vague lines that cause most arguments. If you just want something to fill in, grab the free scope of work template and use this post to sharpen it.

What is a scope of work?

A scope of work is the part of a client agreement that says exactly what you'll deliver, what you won't, how many revisions and hours the price covers, and what happens when the client asks for more. It's the page you point to when someone asks "wasn't that included?", so it has to answer that question on its own.

PMI's PMBOK Guide (4th edition), as summarised in a PMI conference paper on scope, lists the minimum a scope statement should cover: a description of the product, the deliverables, the boundaries (an explicit statement of what's out of scope), acceptance criteria, constraints such as budget and schedule, and assumptions. The same paper calls scope "fuzzy" and says it's often the biggest source of conflicts in a project, because time and cost are numbers and scope usually isn't.

That's the job of your scope of work: make the fuzzy part as close to a number as you can. When it's vague, you get scope creep: extra work that slips in a "quick" request at a time, with the same fee.

How do you write a scope of work, step by step?

Start with the goal, then list each deliverable with a number and a definition of done. Add what's not included, the revision and hour limits, what the client must provide and by when, the timeline with approval points, and how new requests get quoted. Finish by testing it against a few real past requests.

In order:

1. Write the goal in one or two sentences.

2. List the deliverables, each with a quantity or limit.

3. Say what "done" means for each one.

4. List what's not included, especially the things clients usually assume.

5. Set limits: revision rounds, hours, response times.

6. List client responsibilities and assumptions: content, access, feedback deadlines.

7. Set the timeline and sign-off points.

8. Explain how requests and changes work, and how extras get priced.

9. Test it before you send it (more on that below).

Price and payment terms usually sit in the proposal or contract around the scope. Keep them close, but don't let fee talk crowd out the work description. The rest of this post takes each step in turn.

What goes in each section of a scope of work?

Each section answers one question a client might later argue about: why are we doing this, what exactly do we get, when is it finished, what costs extra, what do you need from us, and how do changes work. Write each one so the answer is a fact you can check, not an opinion.

1. The goal

One or two sentences on what the work is for, written in the client's words. "Get more booked consultations from the website" is a goal. "Website redesign" is a project name.

The goal is short, but it settles a lot. When a client asks for a podcast page halfway through a project meant to drive consultation bookings, you can ask how it serves that goal before anyone argues about price. PMI's Bill Duncan, writing in PM Network, puts it this way: "reduce unit costs by 20 percent within one year" is far more useful than "reduce costs". You don't need a percentage, but you do need something more specific than the project title.

2. The deliverables, with numbers

This is the heart of it. List every output, and put a number or a limit on each: pages, templates, posts, articles, concepts, hours, campaigns, integrations.

• Vague: "Social media content."

• Checkable: "8 Instagram posts a month (static images or carousels), with captions. Reels and paid ads aren't included."

Duncan's article makes the same point with a less glamorous example: "clinical trials" isn't a good enough deliverable, but "three Phase I trials completed according to the approved protocol" is. If a deliverable has no number, the client gets to pick the number later, and it won't be a small one.

For web projects specifically, our web design scope checklist shows how to count pages, templates and features.

3. What "done" means for each deliverable

Acceptance criteria tell both sides when a deliverable is finished. Without them, "done" means "when the client stops asking for changes", which can be never.

Good acceptance criteria are things you can check without an argument:

• "Approved in writing by the named approver."

• "Live on the client's domain, with all 6 pages loading and the contact form sending to the agreed inbox."

• "Final logo files delivered in SVG, PNG and PDF."

The US government's rules for its own contracts lean the same way. FAR 37.602 tells agencies to describe work in terms of the required results, not how it's done or the hours spent, and to make performance measurable. You're not a federal contractor, but the logic carries over: if you can't check it, you can't close it.

4. What's not included

Most scopes skip this, and it's the section that prevents the most "I assumed..." conversations. List the things clients in your field commonly expect for free, and say they're available as a separate quote.

Typical exclusions by service:

• Web: copywriting, stock photos, extra pages, hosting, maintenance after launch.

• SEO: link building, content writing, technical fixes on platforms you don't control.

• Social: community management, ad spend, video production.

• Branding: printing, signage, extra concepts after one is chosen.

• Development: integrations not named, support for old browsers, data migration beyond an agreed amount.

You don't have to build this from scratch. The free project exclusions generator builds a "not included" list from your project type and limits, ready to paste right after the deliverables.

5. Limits: revisions, hours and response times

A limit is what makes the next round or the next hour clearly extra. Write how many revision rounds each deliverable includes, and say what one round is (one consolidated list of changes from one person, for example). If it's a retainer, write the monthly hour cap and whether unused hours carry over.

• Vague: "Revisions included."

• Checkable: "2 revision rounds per deliverable. A round is one combined list of changes sent in writing by the approver. Further rounds are quoted before work starts."

If you need help with the wording, the revision policy template covers it, and our guide on how to charge for extra revisions explains how to price the rounds past the limit.

6. Client responsibilities and assumptions

Most delays and a lot of creep come from things the client was supposed to send. Say what they provide, in what form, and by when: content, logins, brand files, product data, feedback.

Then write your assumptions, the things your price depends on. A PMI article on scope statements describes an assumption as something the team believes is valid but may not be, and says that when one proves invalid, whatever depended on it has to change. Put yours in writing so that when one turns out to be wrong, it's obviously a reason to revisit scope, not your problem to absorb:

• "Client provides final copy for all pages before design starts."

• "The site runs on WordPress with the existing theme."

• "One person on the client side gives feedback and approves each stage."

A feedback deadline belongs here too: "Feedback within 5 business days. Later feedback moves the timeline by the same number of days."

7. Timeline and sign-off points

Dates or turnaround times for each stage, and who approves each one before the next begins. Tie dates to what you need from the client ("first designs 10 business days after we receive all content"), so a late client doesn't make you late.

Name the approver. "The client" isn't a person. "Jane Doe, Marketing Manager" is. When a new stakeholder appears in week six with opinions, the scope says whose sign-off counts.

8. How requests and changes work

The scope will change. That's normal. What you want is for every change to go through the same steps: the client sends it in one place, you check it against the scope, and anything extra gets a written quote that the client approves before you start.

Write that down in plain words, in the scope itself or in a scope creep clause in the contract. Then give clients one route for requests, like a single change request form. For pricing the extras, how to price a change request walks through a simple formula.

How do you fix vague wording in a scope of work?

Find every word that needs someone's opinion to measure, like "as needed", "minor", "etc.", "support" or "ongoing", and replace it with a number, a list or a date. Then add what happens past the limit. A line is fixed when two people reading it separately would reach the same answer about a new request.

This isn't just agency folklore. The US Department of Defense's handbook for preparing statements of work (MIL-HDBK-245D) tells writers not to use "any", "assist", "as required", "as applicable", "as necessary" or "as directed". It says "including but not limited to" creates ambiguity and to "only list known requirements", that "etc." brings in unidentified requirements, and that "support" is ambiguous unless you say what kind.

It also has a story worth remembering. An engineer wanted a damaged roof edge repaired and repainted, but wrote "match existing" and never wrote "repaint". The contractors matched the metal flashing and refused to paint it, and the inspector had to agree with them. Clients can do the same with your words, in either direction.

Here are common vague lines from agency scopes and checkable versions. The numbers are placeholders. Use your own.

A quick way to find your own vague lines is to paste the deliverables into the free scope clarity checker. It highlights words like "unlimited", "minor changes", "as needed" and "etc.", lists what's missing (revision limit, exclusions, timeline and so on) and suggests clearer wording. It runs in your browser, and the page says nothing you paste is sent or stored.

A few wording habits that help, all from the same handbook: use the same word for the same thing every time (don't switch between "page", "screen" and "view"), avoid "and/or" and "either", and repeat the noun instead of writing "it" when it could point at two things.

How detailed should a scope of work be?

Detailed enough that every deliverable has a number and a finish line, and short enough that the client reads it. For most agency work that's one to three pages. Duncan's PMI article says most scope statements "can be done well in a page or two". What matters is whether each line can be checked.

Signs it's too thin:

• A deliverable has no number.

• There's no "not included" list.

• Revisions are mentioned but not counted.

• No dates, or dates that don't depend on what the client sends.

Signs it's too heavy:

• It lists every task your team will do internally. The client needs outputs, not your to-do list.

• It repeats legal terms that already sit in the contract.

• It runs so long that nobody on the client side will read it before signing.

If you can't write a scope that specific yet because the client doesn't know what they want, that's a sign you need a short paid discovery stage first. Our guide on whether to charge for a discovery phase covers how that works.

How is a retainer scope of work different from a project scope?

A project scope describes a finished thing with an end date. A retainer scope describes what one month (or period) includes, so it needs monthly quantities, an hour cap, what happens to unused hours, how requests get prioritised, and what counts as extra within the month. Both need exclusions and a change rule.

The main differences:

For retainers, write the monthly menu as carefully as you'd write a project deliverables list. "Website updates as needed" on a care plan is the retainer version of "all the pages you need". Our guides on what's included in a website maintenance retainer and what to put in a retainer agreement go deeper on both the menu and the contract around it. When extras show up mid-month, handling extra work on a retainer covers the next step.

Example (hypothetical): rewriting a brand identity scope

This is a made-up example with round numbers, not a real client.

A two-person studio quotes $4,000 for a brand identity for a new café. Their first draft of the scope says:

"Logo design and brand identity, including colours, fonts, etc. Revisions included. Deliverables provided in all formats. Timeline: around 4 weeks."

Read it as the client. "Brand identity" could include a menu, signage and social templates. "Etc." could include anything. "Revisions included" sounds unlimited. "All formats" could mean an animated logo. "Around 4 weeks" starts whenever.

The rewritten version:

Goal: a logo and basic brand kit the café can use on its signage, menu and Instagram from opening day.

Deliverables: 1. 3 initial logo concepts, presented on one video call. 2. 2 revision rounds on the chosen concept. A round is one combined list of changes from the owner. 3. A colour palette of up to 5 colours, with HEX and CMYK values. 4. 2 fonts chosen from free or client-licensed families. 5. A one-page brand sheet showing logo use, colours and fonts. 6. Final logo files in SVG, PNG and PDF, in full colour, black and white.

Not included: menu design, signage, packaging, social media templates, photography, printing, font licence fees, and further concepts after one is chosen. All can be quoted separately.

Client provides: a short brief and 3 to 5 reference brands within 3 business days of kickoff, and one combined set of feedback per round within 5 business days.

Timeline: concepts 10 business days after the brief arrives; finals 5 business days after the last approved round. Late feedback moves dates by the same number of days.

Changes: new requests go by email to the studio. Anything outside this list gets a written quote and starts only after the owner approves it.

Now play out two requests. In week three, the owner asks for a menu layout. It's named under "Not included", so the studio sends a quote. Later the owner asks for a third revision round. The scope says two, so that's a quote as well, priced at a flat $300 that the owner can accept or skip. Neither conversation is an argument, because the answer was already on the page.

How do you test a scope of work before you send it?

Take three to five requests from past clients, the awkward ones, and check each against the draft using only what's written. If you can't say "included" or "extra" from the page alone, that line needs work. Then have someone who wasn't on the sales call do the same check.

A short pre-send checklist:

• Every deliverable has a number or a limit.

• Every deliverable has a finish line (who approves it, in what form).

• There's a "not included" list with the things your clients usually assume.

• Revision rounds are counted and defined.

• Client inputs have due dates, and the timeline depends on them.

• There's one approver named on the client side.

• There's a written rule for extras: requested in writing, quoted, approved before work starts.

• No vague words left: "as needed", "minor", "etc.", "support", "ongoing", "unlimited", "including but not limited to".

The "past requests" test matters more than any checklist. It's the same check you'll be doing for real every week once the project starts. If you're doing that check by hand and it keeps slipping, that's the point where a scope creep tool helps; our honest comparison of scope creep tools covers the options, including free ones. In Creepless, for example, the included deliverables, exclusions, revision rounds and hour caps from your scope become per-client rules, and the scope referee marks each request Included, Extra or Needs review and cites the rule it used (how it works).

Common mistakes when writing a scope of work

Most bad scopes fail in the same few ways: deliverables without numbers, no exclusions, uncounted revisions, client tasks with no dates, and no rule for extras. Fix those five and most "I thought that was included" moments go away.

A few that are easy to miss:

• Writing the scope after the price. If you quote first and describe the work later, the scope tends to stretch to fit what the client thinks they paid for. Write the deliverables, then price them.

• Copying the proposal's sales language. "A modern, high-converting website" sells. It doesn't scope anything. Keep the pitch in the proposal and the facts in the scope.

• Hiding the limits in small print. If revision limits only appear in the terms at the back, the client won't remember them. Put them next to the deliverables.

• Never mentioning the scope again. Walk through it at kickoff, especially the "not included" list. A client who heard it out loud argues less later.

• Saying yes before checking. The best scope in the world doesn't help if you agree to a request on a call and look it up afterwards. When you do need to say no, our out-of-scope scripts help with the wording.

If you'd like to know what loose scopes are costing you right now, the scope creep cost calculator turns unbilled hours into a monthly and yearly figure.

FAQ: how to write a scope of work

What are the main parts of a scope of work?

The main parts are the goal, the deliverables with quantities, acceptance criteria, exclusions, limits on revisions and hours, client responsibilities and assumptions, a timeline with sign-off points, and a change process for extras. PMI's minimum list for a scope statement covers deliverables, boundaries, acceptance criteria, constraints and assumptions.

What's the difference between a scope of work and a statement of work?

People use the terms loosely. A statement of work is usually the whole document that governs a piece of work, covering scope, timeline, price, payment and terms. The scope of work is the part that describes the work itself: deliverables, limits and exclusions. For small agency projects, one short document often does both jobs.

Who should write the scope of work, the agency or the client?

Usually the agency or freelancer writes it, because you know what the work involves and what it costs. The client supplies goals, constraints and details, then reviews and signs. Big clients sometimes send their own. If they do, check it line by line for vague wording before you price it.

Can you change a scope of work after it's signed?

Yes, but in writing. Agree the change, any new price and any new dates before work on it starts, usually through a change order. The change order template gives you a simple format. If a client keeps reshaping the project, our guide to a client who keeps changing their mind covers that pattern.

Do you need a scope of work for small jobs?

Yes, even if it's five lines in an email. Small jobs creep too, often faster, because nobody wrote anything down. A short note with the deliverable, the number of revisions, what's not included, the date and the price is enough. The client replying "agreed" is better than a call nobody remembers.

The short version

Write the goal, then every deliverable with a number and a finish line. Say what's not included, count the revisions, put dates on what the client owes you, name one approver, and write how extras get quoted. Swap every vague word for a number, a list or a date. Then test it against real past requests before you send it.

Start from the free scope of work template, run your draft through the scope clarity checker, and add a list from the project exclusions generator.