Statement of Work Template for Agencies: What to Include (and What to Leave Out)
Most agency scope disputes are not about what was in the contract. They are about what the contract did not mention. The out-of-scope section is the most skipped and most important part of any statement of work.
01. What a Statement of Work Actually Is (and What It Isn't)
A statement of work (SOW) is a document that defines what will be delivered, by when, for how much, and under what conditions, and crucially, what will not be delivered. It sits apart from the legal contract it's often attached to, and it is distinct from a project plan or a client brief. The SOW answers the question the client and the agency both need answered at the start of any engagement: 'What exactly are we agreeing to?' A good SOW means that when a client asks in month three 'I thought you were going to handle social media,' the answer points back to the document that both parties signed. Most SOW failures are failures of omission. The deliverables list is too vague. The timeline has no milestones. The payment terms are undefined. And most commonly: there is no out-of-scope section at all.
"Most SOW failures are failures of omission. The deliverables list is too vague, the timeline has no milestones, and there is no out-of-scope section at all."
02. Section 1: Project Scope Description
Two to three paragraphs that describe what this engagement is about at a high level: what problem is being solved, what phase of work this SOW covers, and what the relationship between this work and any adjacent work looks like. The scope description sets the context that the deliverables list gets read against. 'This engagement covers the design and development of a new e-commerce website for Folio Studio's retail line, including product catalog, checkout flow, and integration with their existing inventory system. It does not include content creation, photography, or ongoing maintenance post-launch.' That last sentence, 'It does not include...' in the scope description, is a preview of the out-of-scope section and signals to the client upfront that the document will be explicit about boundaries.
03. Section 2: Deliverables List (Explicit and Specific)
This is the list of things the agency will produce and deliver. Not 'website design' but 'five page designs (homepage, product listing, product detail, cart, checkout) delivered as Figma files with design specifications included.' Not 'social media strategy' but 'a 12-week social media content calendar for Instagram and LinkedIn, including post copy and creative direction notes for each post.' Vague deliverables create vague expectations. The client reads 'website design' and imagines the complete finished website. The agency means the Figma mockups. Both parties sign the document with different things in mind. The dispute happens in week six when the client asks why development is not included. For each deliverable, specify: what it is, what format it will be delivered in, how many revision rounds are included, and what the definition of 'done' looks like.
Flat-fee · No seat tax
Done paying per seat? Melororium covers tasks, time tracking, and client CRM for teams of 4–25 — one flat monthly price.
04. Section 3: Out-of-Scope List (the Section Most Agencies Skip)
This is the most important section in the SOW and the one most agencies omit entirely. The out-of-scope list explicitly names the things that are not included in this engagement, not because they are unimportant, but because they are not part of what was agreed. Why this matters: clients read deliverables lists and fill in the gaps with assumptions. If the deliverables list includes 'landing page design,' the client might assume that copywriting, photography, and email template design are also included. If the SOW does not explicitly say they are not included, you have no clean reference point when the client brings up email templates in month two. The out-of-scope list should include: adjacent work the client might reasonably expect but you did not price for, work that might be needed later (a phase two), and common expansions of the deliverables that are excluded (more revision rounds, additional platforms, maintenance, hosting). A well-written out-of-scope section protects the client relationship instead of putting up walls. When the client wants email templates and the SOW says clearly 'email templates are out of scope for this engagement,' the conversation is 'great, let's talk about a change order' rather than 'I thought that was included' followed by days of back-and-forth.
05. Section 4: Timeline With Milestones
A project timeline in a SOW should have three elements: milestone dates (when specific deliverables or phases will be complete), client dependencies (what the agency needs from the client and by when for the timeline to hold), and a timeline-slippage clause. The timeline-slippage clause is the sentence that protects you when the client takes three weeks to give feedback on a deliverable that was supposed to be reviewed in five days. Something like: 'This timeline assumes client feedback is received within five business days of each deliverable submission. Delays in client feedback will extend the timeline by an equivalent period.' Without this clause, a client who takes three weeks to approve mockups will still expect the final delivery on the original date. With it, the conversation about extended timelines has a reference point that was agreed at the start.
06. Section 5: Payment Terms
Payment terms in a SOW should specify: the total fee, how it is structured (upfront deposit, milestone payments, monthly retainer), when each payment is due, and what happens if a payment is late (interest, work suspension, or both). The most common payment structure for project work: 50% at signing, before work begins, and 50% at final delivery. This protects the agency from doing all the work and then losing the client, and it aligns client incentives, since the client needs to pay the second half before receiving the final files. For ongoing retainer work: payment due on the first of the month, net 15. Define what happens if the client cancels the retainer mid-month, whether hours worked are billed pro-rata or whether a cancellation fee applies.
07. Section 6: Change-Order Process
This section defines how scope changes are handled after the SOW is signed, since changes are normal and both sides need to know what to expect. A minimal change-order process: any work outside the defined scope requires a written change order before work begins. The change order specifies the additional work, the cost, and any timeline impact. Work on the changed scope begins only after the client approves the change order in writing. The key phrase: 'before work begins.' Most scope disputes happen because the agency started work on a change without getting formal approval, either because the client seemed enthusiastic or because the work felt small. If the habit is 'write it down before starting,' a verbal 'sounds good' from the client is not a green light.
08. The SOW as a Living Document, Not a Filing Artifact
Most SOWs are signed once and never looked at again until a dispute makes them necessary. That is a waste of the clarity the document provides. A SOW that is actively referenced during the project does two things: it keeps both sides aligned on what was agreed, and it makes scope expansion conversations easier because there is a shared baseline to negotiate from. 'The SOW covers two revision rounds, so this would be the third and we would need to add a change order' is a much easier conversation when both parties have access to the document and have been referencing it throughout. Pinning the SOW inside the project workspace, as a note, a linked document, or a Canvas area, keeps it visible. Melororium's Canvas feature lets you pin reference documents directly inside a project, so the SOW is one click away from the task board rather than buried in an email thread from two months ago.
09. A Copyable SOW Structure
Copy this structure and adapt it to your engagement. **1. Scope Description** [2-3 sentences describing what this engagement covers at a high level, and what it explicitly does not cover] **2. Deliverables** [List each deliverable with: format, quantity, revision rounds included, definition of done] **3. Out of Scope** [Explicit list of adjacent work not included in this engagement] **4. Timeline** [Milestone dates] | [Client dependencies and their deadlines] | [Timeline slippage clause] **5. Payment** [Total fee] | [Payment schedule] | [Late payment terms] **6. Change Orders** [Any work outside this SOW requires a written change order before work begins. The change order specifies work, cost, and timeline impact.]
10. Frequently Asked Questions
**What is the difference between a statement of work and a contract?** A contract defines the legal relationship between two parties: terms of service, liability limits, IP ownership, dispute resolution. A statement of work defines the specific deliverables, timeline, and scope for one particular engagement. The SOW is usually attached to or referenced by the contract. The contract governs the overall relationship; the SOW governs what gets done in a specific engagement. You need both, but they do different jobs. **How specific should the deliverables list be?** Specific enough that a new team member could read the list and know exactly what they need to produce. If the deliverables list includes 'website design,' that is too vague. 'Five page designs (homepage, product list, product detail, cart, checkout) delivered as Figma files with annotated specifications' is specific enough. When in doubt, add more detail. You can always do more than the SOW specifies. You cannot do less without a conversation. **What should go in the out-of-scope section of a SOW?** Everything the client might plausibly think is included but isn't. Common examples: copywriting when you are designing but not writing, photography or video when you are designing around existing assets, additional pages beyond what is listed, ongoing maintenance or hosting, future phases, revision rounds beyond the included number, and any adjacent service the client mentioned informally. If it came up in any conversation before signing and you are not including it, put it in the out-of-scope section. **Who should sign the statement of work on the client side?** The person who controls the budget for this engagement, not only the day-to-day contact you have been talking to. A SOW approved by a marketing manager who cannot authorize spend is one of the most common sources of payment disputes, because the person who eventually approves the invoice never agreed to the scope. Ask directly who signs and who pays, and get both on the document. **How long should an agency statement of work be?** Two to four pages for most project work. The document has to be short enough that both sides actually reread it during the project, because a SOW that never gets opened after signing provides none of the alignment it was written for. Depth belongs in the deliverables and out-of-scope sections; everything else stays brief.
Keep the SOW where the work happens.
Pin the signed SOW inside the project with Melororium Canvas, one click from the task board and visible to the whole team.
