# Statement of work template, with a filled-in example > A free statement of work template in Word and Google Docs, with a filled-in example and a checklist of the 10 sections every SOW needs. Source: https://plexiidesk.com/blog/statement-of-work-template Topic: Work by task (https://plexiidesk.com/blog/c/work-by-task) Author: The Plexii team Published: 2026-11-08 Updated: 2026-11-09 A statement of work (SOW) is the document that says exactly what a supplier will deliver, by when, to what standard and for how much. A good one stops arguments before they start. This page gives you a statement of work template to copy, the 10 sections every SOW needs, and a filled-in example for an Australian agency project. ## Copy the SOW template Copy the outline below into Word or Google Docs. Each heading is one section, and the prompts tell you what to write. ``` STATEMENT OF WORK Project: [name] Client: [legal name, ABN] Supplier: [legal name, ABN] SOW reference: [number] Version: [x.x] Date: [dd/mm/yyyy] Governing agreement: [MSA or contract name and date, if any] 1. Purpose and background – why the project exists, in 2–3 sentences 2. Scope – the work included, in plain terms 3. Deliverables – each output, its format and quantity 4. Schedule and milestones – dates or durations for each milestone 5. Acceptance criteria – how each deliverable is tested and approved 6. Assumptions and dependencies – what must be true, and what the client supplies 7. Out of scope – what is explicitly not included 8. Roles and responsibilities – named contacts and decision-makers on both sides 9. Pricing and payment – fee basis, amounts, GST, invoicing and payment terms 10. Change control – how changes are requested, priced and approved Signatures: [client name, role, date] [supplier name, role, date] ``` Word, Google Docs and PDF versions are coming to this page. To keep the SOW beside the rest of the engagement, [download Plexii free](https://plexiidesk.com/download) and give the engagement its own desk. ## The 10 sections every SOW needs 1. **Purpose and background.** Why the work is happening and what the client wants to achieve. Keep it short. It's context for everything else. 2. **Scope.** The boundary of the work in plain language: what the supplier will do, for which audience or system, and at what scale. 3. **Deliverables.** Every output, named and described, for example "a 12-page responsive website on the client's WordPress hosting", not "a website". A [work breakdown structure template](https://plexiidesk.com/blog/work-breakdown-structure-template) is a quick way to make sure nothing is missing. 4. **Schedule and milestones.** Key dates, or durations from a start date, and which milestones trigger reviews or payments. 5. **Acceptance criteria.** How each deliverable will be checked, by whom and within how many business days. This section does the most to prevent disputes. 6. **Assumptions and dependencies.** What the plan relies on: content supplied by a date, access to systems, a single round of consolidated feedback. 7. **Out of scope.** Name the things a reasonable client might assume are included but aren't. 8. **Roles and responsibilities.** Named contacts on both sides, who approves what, and how often you'll meet. 9. **Pricing and payment.** Fixed price, time and materials, or a mix; whether amounts include GST; the invoicing schedule and payment terms. 10. **Change control.** How a change is requested, assessed, quoted and approved in writing before work starts. NSW Government's ICT agreement guidance describes a SOW in much the same way: it sets out the supplier's activities, deliverables, specifications and roles, and may cover milestones, acceptance testing, pricing, assumptions and dependencies. ## A filled-in SOW example: agency website project This example is fictional: a Melbourne agency rebuilding a website for a Brisbane physiotherapy clinic group. | Section | Example content | |---|---| | Purpose | Replace the clinic group's outdated website with a faster, mobile-friendly site that makes online booking easier to find. | | Scope | Discovery, design, build and launch of a new marketing website for three clinic locations on the client's existing WordPress hosting. | | Deliverables | Sitemap and wireframes (PDF); visual design for home, location, service and contact templates (Figma); 15-page website on staging; redirect map; 60-minute editor training session (recorded). | | Schedule | Kick-off 2 Feb; wireframes 20 Feb; designs 13 Mar; staging site 17 Apr; launch 1 May. | | Acceptance | Client reviews each deliverable within 5 business days. A deliverable is accepted when it meets the listed criteria or no written feedback arrives within the review window. The site passes the agreed browser and device list and the redirect test. | | Assumptions | Client supplies final copy and photos by 6 Mar. One consolidated round of feedback per deliverable. Booking stays on the clinic's existing booking platform, linked from the site. | | Out of scope | Copywriting, photography, booking system changes, ongoing hosting and maintenance, paid advertising. | | Roles | Client: practice manager (day-to-day), director (final approval). Agency: account manager (single point of contact), designer, developer. Fortnightly 30-minute check-in. | | Pricing | Fixed fee of $24,000 plus GST: 30% on signing, 40% on design approval, 30% on launch. Invoices payable within 14 days. | | Change control | Changes requested in writing; agency replies within 3 business days with cost and schedule impact; work starts only after written approval. | Notice how the out-of-scope list names copywriting and booking changes. Those are the two things a clinic is most likely to assume come with a "new website". ## SOW vs scope of work vs contract vs MSA - **Statement of work:** the full description of one engagement, covering scope plus deliverables, schedule, acceptance, roles and price. See the [statement of work glossary entry](https://plexiidesk.com/glossary/statement-of-work). - **Scope of work:** often just the scope section of a SOW, although people use the two terms loosely. If someone asks for a "scope of work template", this template covers it. - **Contract:** the legally binding agreement. A SOW can be the contract on its own for small jobs, or a schedule attached to one. - **Master services agreement (MSA):** the standing legal terms (liability, IP, confidentiality, payment) for an ongoing relationship. Each new project then gets its own short SOW under the MSA. Where an MSA exists, keep legal terms there and project detail in the SOW, and don't repeat the same terms in both. For anything with real legal or financial exposure, have the contract terms reviewed by a lawyer. ## Acceptance criteria that prevent scope creep [Scope creep](https://plexiidesk.com/glossary/scope-creep) usually starts with a deliverable nobody defined precisely. Good acceptance criteria are: - **Testable.** "Loads on the latest versions of Chrome, Safari, Edge and Firefox, and on iOS and Android phones" rather than "works on all devices". - **Tied to a deliverable.** One set of criteria per deliverable, not a general promise of quality. - **Time-boxed.** A review window and a rule for what happens when it passes. - **Limited in rounds.** State how many rounds of revisions are included and what a further round costs. - **Owned.** Name the person who can accept on the client's behalf. When a request falls outside the criteria, that's a change, and section 10 tells everyone what happens next. ## Checklist before you send it - Both parties' legal names and ABNs are correct. - Every deliverable has acceptance criteria and a date. - Out of scope names the most likely assumptions. - Client dependencies have dates, with what happens if they slip. - Prices state whether GST is included. - Payment milestones match deliverable milestones. - Change control explains how to request, price and approve a change. - The approver on each side is named. - It doesn't contradict the MSA or contract it sits under. - Someone who wasn't in the sales conversation has read it and understood it. ## How to fill in the template in five steps 1. **Start from the brief.** Copy the goal and constraints from the client's brief or your proposal into the purpose and scope sections, then cut anything that's sales language. 2. **List the deliverables before the dates.** Break the work into outputs first, with a WBS if it's more than a few deliverables, and only then put milestones against them. 3. **Write acceptance criteria next to each deliverable.** If you can't say how it will be checked, the deliverable isn't defined well enough yet. 4. **Write out of scope and assumptions together.** Every assumption ("client supplies copy") usually has a matching exclusion ("copywriting"). 5. **Price last.** Once the work, schedule and risks are clear, choose fixed price or time and materials, and line payments up with the milestones. ## Common SOW mistakes - **Vague deliverables.** "Marketing support" can't be accepted or rejected. "Four blog posts of 1,000–1,500 words per month" can. - **No review window.** Without one, a deliverable can sit unapproved for weeks while the next stage waits. - **Unlimited revisions by omission.** If the SOW doesn't say how many rounds, the client will reasonably assume it's as many as they need. - **Dependencies with no consequences.** Say what happens to the schedule and price when client inputs arrive late. - **Copying legal terms into every SOW.** Keep them in the MSA, so the two documents can't contradict each other. ## How PlexiiDesk relates In Plexii, every task gets its own desk, and an engagement makes a natural desk. Keep the signed SOW, the [work breakdown structure](https://plexiidesk.com/glossary/work-breakdown-structure), the [project brief](https://plexiidesk.com/glossary/project-brief) and a [decision log](https://plexiidesk.com/glossary/decision-log) side by side, with client emails and files beside them. When a change request arrives, the original scope is one glance away. Agencies can see how this works on the [agency and client service page](https://plexiidesk.com/for/agency-client-service), and consultants can start from the [consulting report desk template](https://plexiidesk.com/templates/consulting-report). The free tier is free forever for personal use, Pro is US$12 a month or US$120 a year, and teams get a 14-day free trial. ## Common questions ### What should a statement of work include? At minimum: purpose, scope, deliverables, schedule and milestones, acceptance criteria, assumptions and dependencies, out of scope, roles, pricing and payment, and change control. ### Is a statement of work legally binding? It can be. A signed SOW that sets out the work and price may form a contract on its own, or it may be a schedule under a broader agreement. How binding it is depends on its wording and the agreement it sits under, so get legal advice for significant engagements. ### Who writes the statement of work? Either side can draft it. Suppliers often write it because they know how the work is done, and buyers, including government agencies, often supply their own template. Both parties should review and sign it. ### What's the difference between a SOW and a proposal? A proposal is a pitch that tries to win the work. A SOW is the agreed definition of the work once you're going ahead, and it should be specific enough to test delivery against. ### Is there an Australian government SOW template? Yes. NSW Government publishes a statement of works template for ICT consulting on info.buy.nsw, and its ICT Agreement includes a SOW template schedule. ## Sources - NSW Government, [ICT Services Scheme: buying ICT consulting](https://www.info.buy.nsw.gov.au/schemes/ict-services-scheme), including the statement of works template. - NSW Government, [MICTA/ICTA user guide](https://info.buy.nsw.gov.au/resources/micta-icta-user-guide), Schedule 3: Statement of Work template. - Project Management Institute, [A Guide to the Project Management Body of Knowledge (PMBOK Guide)](https://www.pmi.org/standards/pmbok).