What is a statement of work (SOW)?
A statement of work (SOW) is the project document that says what you will deliver, by when, how it will be accepted and on what terms you will be paid.
What a statement of work does
A statement of work, usually shortened to SOW, describes one specific project: the work, the deliverables, the schedule, how finished work will be accepted and how it will be paid for. It turns a conversation about goals into a document both sides can check later.
For a freelancer or small studio, the SOW is the answer to a simple question that comes up halfway through every project: what exactly did we agree to? If the answer depends on someone’s memory of a call, the SOW is missing or too vague.
Example: Emi Studio agrees to refresh Acorn Studio’s website. The SOW names three pages, two review rounds, a launch date and a fixed price of $1,250 at an hourly basis of 12.5 hours at $100. John Park at Acorn Studio is named as the person who approves deliverables.
Is an SOW the same as a contract?
Not always. Many service relationships use two layers. A master services agreement, sometimes called an MSA, sets the general terms: confidentiality, ownership of work, liability, payment timing and how disputes are handled. Each project then gets its own SOW that describes the work and refers back to those terms.
A small engagement may combine both into one signed document, such as an accepted estimate with project terms attached. Whether a particular SOW is binding, and which document wins if they conflict, depends on its wording and the law that applies. If the stakes are high or the terms are unusual, have a lawyer review the agreement. A good habit is to include an order-of-precedence line, such as “If this SOW conflicts with the master agreement, the master agreement controls,” so readers do not have to guess.
What is included in a statement of work?
Most SOW formats cover the same core sections, even when the headings differ. Use this order as an outline and leave out anything that does not apply to the project.
- Purpose and background: why the project exists and what problem it solves.
- Deliverables: each item you will hand over, with enough detail to recognize it as finished.
- Exclusions and assumptions: what is not included and what the client must supply.
- Schedule: milestones, review periods and the expected completion date.
- Acceptance criteria: who reviews, what counts as accepted and how revision requests work.
- Price and payment terms: fixed fee or rate, deposits, invoice timing and due dates.
- Change process: how new requests are priced and approved before work begins.
Who prepares a statement of work?
Either side can write the first draft. In large organizations, the buyer often prepares the SOW and asks suppliers to respond. US federal agencies, for example, are told to describe work in terms of required results rather than how it is done or how many hours it takes, so offers can be compared on outcomes.
With freelancers and small studios, the provider usually drafts it because they know what the work involves. That is an advantage: you can write deliverables in terms you can actually deliver. Send the draft to the client for comments, settle open questions, and only then ask for signature or acceptance.
Whoever drafts it, both parties should read it as if they were the other side. A client asks “Is everything I expect here?” A provider asks “Could this sentence be read as including work I have not priced?”
Can you show a short statement of work example?
Here is how the core of a short SOW could read for the fictional Emi Studio project. Purpose: “Refresh Acorn Studio’s website so new clients can understand its services and get in touch.” Deliverables: “Design and build Home, About and Contact pages on the existing hosting, with one contact form.”
Schedule: “Kickoff on the first Monday. First designs within ten business days. Launch within four weeks, provided feedback arrives within five business days of each review.” Acceptance: “John Park reviews each published page version and accepts it or requests changes within two included revision rounds.”
Price and payment: “Fixed fee of $1,250, based on 12.5 hours at $100, invoiced as #104 and due 30 days after issue.” Change process: “New requests are quoted in writing and started only after John Park approves the price and timing.” Each line is short, testable and easy to quote back when a question comes up. A longer project would add milestones, more deliverables and references to a master agreement, but the shape stays the same.
Statement of work vs scope of work
The two terms are often used interchangeably, but they are useful to separate. The scope of work is the description of the work itself: deliverables, boundaries, assumptions and revision rounds. The statement of work is the wider project document that contains the scope along with the schedule, acceptance, price and change terms.
In practice, a strong scope section does most of the work of a good SOW. If you want a step-by-step method for writing that section, with a worked example, read our guide to writing a scope of work. Keep the vocabulary consistent: if the SOW says “Deliverables”, do not call the same items “Outputs” in the invoice.
Common SOW mistakes
Most SOW problems are small wording choices that become expensive later. A deliverable called “website design” could mean one homepage mockup or a full design system. “Unlimited revisions” sounds generous but removes any shared sense of when work is done. A schedule without client review deadlines leaves the provider responsible for delays they cannot control.
Another common gap is the change process. If the SOW does not say how requests outside the agreement are handled, every new idea becomes a negotiation under deadline pressure. A single sentence helps: “Requests outside this SOW will be quoted separately and started only after written approval.” Finally, do not reuse an old SOW without reading it. A template is a starting point, not evidence that this client agreed to this scope.
How Moolamochi approaches it
Moolamochi treats the accepted estimate as the agreed scope. You accept a versioned estimate, complete required signatures and prepare the linked invoice, then deliberately generate the approved service work. A changed brief becomes a client request and a reviewed commercial proposal, so the original version stays visible. Moolamochi does not replace legal review of your terms. New access is currently waitlist-only.
Primary-source references
External providers maintain their own requirements; consult the linked documentation for their current details.
