How to write a statement of work for client projects
What a statement of work contains, how it differs from a proposal and a contract, and why acceptance criteria end most disputes.
On this page
A statement of work (SOW) lists exactly what you will deliver, by when, for how much and under what conditions the client accepts it. A proposal sells the job and a contract sets the legal frame. The SOW is the part that decides whether a project is finished, which is why most scope fights come down to its absence.
Most service businesses have the first two documents and skip the third. The SOW is where the loose language of a proposal ("a modern, responsive website") becomes a numbered list of deliverables, milestones and the exact conditions of acceptance. This guide covers how it differs from the other documents, the sections a small business SOW needs, and why two of those sections do most of the work.
SOW versus proposal versus contract
These three documents get mixed up constantly, and the mix-up causes real problems. Each does a different job.
A proposal is a sales document. It wins the work, so it is persuasive and often optimistic, and it does not need to cover edge cases because its job is to get a yes.
A contract is the legal frame. It establishes that an agreement exists at all. Under standard contract law a valid agreement needs a handful of elements, including offer, acceptance and consideration, the thing of value each side exchanges (Thomson Reuters). The contract covers payment terms, intellectual property, liability and termination, and it is usually reusable across projects.
The SOW is the specific work. It changes from project to project even when the contract stays the same. The Project Management Institute defines the building blocks it relies on: a deliverable is any unique and verifiable product, result or capability, and acceptance criteria are the conditions that must be met before deliverables are accepted (PMI). The SOW is where you apply those definitions to your actual job.
In practice the SOW and contract often live in one signed document, with the contract supplying the legal terms and the SOW supplying the scope. That is fine. What matters is that the scope detail sits somewhere you both signed, not in an email thread.
Why writing scope down protects you
Writing scope down is sound practice, and in some places it is the law. New York City's Freelance Isn't Free Act requires that contracts for freelance work of 800 dollars or more include, in writing, "a scope of work and schedule of services to be provided by the freelancer, the payment rate and method of compensation" and "the date upon which payment is due" (Freelancers Union). Lawmakers reached for scope first because that is where unpaid contractors get hurt most often.
General business guidance agrees. The US Chamber of Commerce, describing what an independent contractor agreement should contain, leads with the specific services the contractor will provide, then quality standards and milestone dates (US Chamber of Commerce). Scope is the spine of the agreement.
A signed SOW does not need ink and paper. The US federal E-SIGN Act says a contract or signature cannot be denied legal effect solely because it is in electronic form, so a document signed in a browser carries the same weight as one signed at a desk. Rules differ by country and document type, so check anything high-value with a lawyer.
The sections an SOW needs
A complete SOW is short but specific. These sections earn their place.
Scope and deliverables come first. State the purpose of the project, then list each deliverable as a concrete, countable item. Not "branding" but "one primary logo, two secondary lockups and a one-page colour and type guide." MBO Partners frames this as the specific tasks, activities and deliverables to be performed. Quantities matter more than adjectives.
Exclusions come second. Name what is not included. This is the section most people skip, and it prevents the most disputes. PMI notes that stating exclusions helps manage expectations and can reduce scope creep. If you were hired to design but not to write copy, say so. If launch support ends after one round of fixes, say that too.
Milestones and timeline come third. Break the project into checkpoints tied to deliverables, with dates. Milestones turn an opaque stretch of work into visible progress and give both sides a rhythm for review.
Acceptance criteria are fourth. For each major deliverable, state the conditions under which the client agrees it is done. For example: "Accepted when the five pages render correctly on desktop and mobile and pass one round of revisions." Without this, "done" is an opinion, and the client's opinion can keep moving.
The payment schedule is fifth. Tie payments to milestones or dates and record the rate, the method and the due date. The Freelance Isn't Free Act makes the payment date a required written term for a reason: vagueness here is how people end up chasing money for months.
Assumptions are sixth. State what you are taking for granted, such as the client delivering final copy by a given date, or a third-party plugin working as documented. Assumptions protect you when reality diverges from the plan through no fault of yours.
The change-request process is last. Describe how new work gets added: how a request is submitted, how you price it and how it is approved before you start. MBO Partners lists this as a core SOW component. A documented change process lets you say yes to extra work without giving it away. Our guide to billing for mid-project scope changes shows how to word it.
Why acceptance criteria and exclusions do the heavy lifting
Of all those sections, two prevent the disputes that actually end relationships. They answer the only two questions that cause real fights: is this done, and was this part of the deal?
Exclusions handle the second question before anyone asks it. Most scope disputes are not bad faith. Two people remember the conversation differently, and the client honestly believed the thing was included. A written exclusion removes the ambiguity, and there is nothing left to misremember.
Acceptance criteria handle the first question. The most common way a competent project still goes bad is that the work is finished by any reasonable standard, but the client keeps finding reasons it is not quite right. Without agreed criteria you cannot say "this meets what we agreed" and make it stick. With them, completion is a checklist, not a mood. The project ends when the conditions are met, and everyone signed those conditions at the start.
Good criteria are objective and checkable. "The client is happy" is not a criterion, because happiness moves. "Renders correctly on desktop and mobile and passes one round of revisions" is, because it either happened or it did not.
These two sections also change how a project feels day to day. When the boundaries are written down, you stop bracing for the awkward talk about whether something counts as extra. The document already had it for you. You point to the SOW, follow the change process and price the new request as new work, calmly, because that is what you both agreed would happen.
An SOW does not stand alone. It builds on the project brief that set out what the work was for, and it pairs with kill fee and cancellation clauses that decide what happens to your money if the project stops early. Together they cover the two things you need in writing: what you are building, and what you are paid if it ends.
How Delivvo turns scope into a signed, tracked agreement
Delivvo keeps scope, signature, delivery and acceptance on one project, so the SOW is not a document that gets lost after it is signed.
- Build the scope in proposals. The quote is made of your packages and add-ons, so each deliverable is a line the client chooses, with a price. Put exclusions and assumptions in the package description.
- Attach the SOW to a contract and send one link. The client signs in the portal, typed or drawn, and Delivvo stores a signing record with a SHA-256 hash, IP address, device and an archived PDF. On Business and up you can upload your own contract PDF and place signature boxes yourself.
- Tie money to milestones with a payment schedule of up to 12 payments, so each deliverable lines up with an invoice.
- Deliver each piece through the client portal. Files are versioned, and the client signs in with a one-time code.
- Ask for sign-off in client approvals. The approval is recorded against the project, so "accepted" is an event with a date, matched to the criteria you both signed.
- Change requests become new line items on a new quote, using the same flow, and the paper trail stays on the same project.
The client pays through your own gateway, and Delivvo takes 0%. Because every contract and invoice carries a verification code, a client or their accountant can check a document on the verify page and see who issued it and its status.
The templates are a starting point, not legal advice, so check the wording of your SOW with a lawyer where the stakes are high.
For the wider picture, see contracts and e-signatures and the CRM for service businesses.
FAQ
Do I need a separate SOW if I already have a contract?
Not necessarily separate, but you need the scope detail somewhere you both signed. Many people fold the SOW into the contract as a scope section or attached schedule. What matters is that deliverables, exclusions and acceptance criteria are written into the signed agreement, not left in emails.
What is the difference between a deliverable and a milestone?
A deliverable is a thing you hand over, such as a design file or a deployed feature. A milestone is a checkpoint in the timeline, often the point where a deliverable is due or a payment is triggered. Milestones organise the schedule, and deliverables are the output the schedule produces.
Are electronic signatures on an SOW valid?
In the United States the federal E-SIGN Act says a contract or signature cannot be denied legal effect solely because it is electronic. Other countries have their own rules, so confirm yours with a lawyer for important documents.
What makes acceptance criteria effective?
They are objective and checkable. Tie each major deliverable to conditions a third party could verify, and completion stops being a matter of opinion.
Delivvo runs the whole client cycle for service businesses, from the first inquiry to the quote, contract, deposit, invoice and delivery, so the scope you write at the start is the scope you are paid for at the end. Clients pay you directly through your own gateway, and Delivvo takes 0%. Start free