How do I write a scope of work for a client project?

Start from outcomes, not tasks

A scope of work describes what the client will receive and where the work stops. It is not a list of everything you plan to do. “Research competitors, sketch layouts, write CSS” describes effort. “A designed and built homepage, about page and contact page, live on the client’s existing hosting” describes outcomes the client can check.

Writing in outcomes keeps the scope readable for someone who was not on the sales call, such as a finance contact or a new project lead. It also gives you room to choose your own methods. US federal guidance makes the same point for government buyers: describe required results rather than how the work is done or the number of hours provided.

Gather the facts before you write

Most vague scopes are written too early. Before drafting, confirm the details that change the price. Ask who supplies text and images, which platform the work must run on, what deadline matters and why, and who has the final say. If the client cannot answer yet, record the gap as an assumption rather than guessing.

Write down who approves what. John Park may approve the design while someone in finance approves the cost. Naming both now prevents a later disagreement about whether a reply counted as approval.

Finally, ask what success looks like after launch. A client who expects more enquiries from a contact page may assume search optimization is included. If it is not, the scope should say so now, while the conversation is still friendly and nothing has been built.

Write the scope section by section

Work through the scope in a fixed order so nothing important depends on memory. Keep each line short enough to quote back in an email.

1. Name each deliverable with a count or measurable size.
2. State the assumptions each deliverable depends on.
3. List what the client supplies and when it is due.
4. Set the number of revision rounds included per deliverable.
5. Write exclusions for the requests you expect to hear.
6. Define acceptance: who reviews, what they check and the response time.
7. Describe how out-of-scope requests are priced and approved.

A worked example: Emi Studio’s website refresh

Here is how a short scope could read for a fictional project. Deliverables: “Redesign and build three pages: Home, About and Contact. Includes one contact form connected to the client’s existing email address.” Assumptions: “Acorn Studio supplies final text and photos by the first Monday after kickoff. The site stays on its current hosting.”

Revision rounds: “Two rounds of consolidated feedback per page. A round is one set of comments from Acorn Studio sent within five business days.” Exclusions: “Copywriting, new photography, additional pages, online payments and search advertising are not included.” Acceptance: “John Park reviews each published page version and either accepts it or requests revisions within the included rounds.”

Price and timing sit beside the scope: 12.5 hours at $100, invoiced as #104 for $1,250. With that baseline in writing, a later request for brand voice edits can be estimated as a 1.5-hour, $150 addition rather than argued about. Our guide to preventing scope creep covers how to handle that moment.

Write acceptance criteria the client can use

Acceptance criteria answer the question “How will we both know this deliverable is finished?” Without them, a project can drift through endless small requests because nobody can point to the moment it was done.

Good criteria name the reviewer, what they check and how long they have to respond. For a web page, that might be: “The page matches the approved design, displays correctly on current phone and desktop browsers, and the contact form delivers to the client’s address.” For a document, it might be: “Final copy approved in writing by the named reviewer.”

Add what happens if nobody replies. Rather than treating silence as approval, say that the schedule moves by the length of the delay. That is fair to both sides and keeps the dates honest.

Make exclusions specific

Exclusions are the part of a scope that clients notice least and providers rely on most. A line such as “Anything not listed is excluded” is technically true but rarely helps in a real conversation. Name the requests you expect, based on similar projects: extra pages, copywriting, stock photo licensing, ongoing maintenance, integrations with other tools, or training.

Specific exclusions do two jobs. They make the price easier to understand, because the client sees what the fee does not buy. They also make a later conversation calmer: when an excluded item comes up, you can point to the line and offer a separate quote instead of debating what was implied.

How do you describe scope so it holds up?

Read each sentence and ask whether two reasonable people could disagree about it. “Mobile-friendly” is better as “Pages display correctly on current versions of Safari and Chrome on phones.” “Fast turnaround” is better as a date. “Some revisions” should be a number.

Numbers help, but only where you can keep them. Do not promise a page speed score if you do not control hosting. Do not limit revisions so tightly that normal feedback becomes a dispute. A scope is fair when both sides could predict the answer to most questions without asking you.

Common gaps to check before sending

Read the draft once from the client’s side. Look for a deliverable with no acceptance rule, a review step with no deadline, or a dependency on content that nobody owns. Check that exclusions name real likely requests rather than a vague “anything not listed”.

Then check the boundary with the rest of the agreement. The scope belongs inside a larger document that sets the schedule, price, payment terms and general conditions; in larger engagements that document is a statement of work. If terms like ownership, liability or late fees matter, have them reviewed by someone qualified in your jurisdiction.

How Moolamochi approaches it

In Moolamochi, an estimate holds hourly or fixed services, and accepting a versioned estimate becomes the agreed scope. Service templates help you start, but later template edits affect future work only, and a template is not evidence that a client accepted a scope. Out-of-agreement requests go through a priced proposal decided by the named commercial approver. New access is currently waitlist-only.