It is week six of a fixed-fee pricing project. On Thursday afternoon the client's sponsor emails: "Could you also cover the stores in Spain? I assumed they were part of the review." You open the signed statement of work, adapted months ago from a generic statement of work template. It says "pricing analysis for the retail business," lists three workshops and a final report, and stops there. No list of countries, no acceptance criteria, nothing on what happens when someone asks for work nobody priced.
So you choose between two weeks of unpaid work and an argument about a sentence nobody wrote with care. Below is a free consulting statement of work template that closes those gaps (three A4 pages in PDF, every section also written out to copy), then how to keep the signed SOW working once the project starts.
What a consulting statement of work must settle
A 1998 article in PMI's PM Network defines the statement of work as the narrative description of what will be supplied under the contract, including what the provider needs from the client to deliver it, and gives it one job: an objective measure of when the work is complete and when payment is justified [1].
In PMI's 2021 Pulse of the Profession, respondents reported scope creep on 34% of the projects their organizations completed in the previous 12 months, and avoiding it was a top-three driver of project success in every industry the survey analyzed [2].
Most free templates I reviewed give you headings. They rarely give you wording for the three places where consulting projects lose money: acceptance criteria someone can test, client dependencies with dates, and what happens when someone asks for more.
The SOW covers one project: what, when and for how much. Liability, ownership of the work and confidentiality belong in the consulting agreement the SOW sits under, signed once per client, so each new project needs only a three-page SOW.
The consulting statement of work template (free download)
Download the template (PDF, 3 pages). Print it or copy the wording below; placeholders are in [square brackets].
This template is a starting point, not legal advice. A signed SOW is part of your contract with the client, so have it reviewed by a lawyer in your jurisdiction before you use it.
01 Parties and precedence
Header fields: both legal names, addresses and company numbers, the client sponsor and engagement lead, the project period, the version and the SOW reference. Then:
This Statement of Work (SOW) describes the services, deliverables, schedule and fees for [Project name]. It is issued under the [Consulting Agreement] dated [date] between the parties (the Agreement), whose terms apply to it. If this SOW and the Agreement conflict, the Agreement prevails unless this SOW names the clause it changes.
02 and 03 Objectives and scope
Write the background in the client's words, one objective (for example, approved list prices for the 2027 range) and the success measure both sides will check. Then:
- In scope: [interviews with up to 8 sales and finance managers]; [analysis of 24 months of transaction data provided by the Client]; [two workshops with the steering committee].
- Out of scope: [implementing the new prices in the ERP system]; [countries or business units not named above]; [training sales teams].
Anything not listed as in scope is out of scope and needs an approved change request (section 09).
04 Deliverables and acceptance criteria
| ID | Deliverable and format | Acceptance criteria | Due |
|---|---|---|---|
| D1 | Current-state assessment, PDF report, up to 20 pages | Covers the 3 business units in scope; findings reviewed with the sponsor in a 60-minute session | [date] |
| D2 | Pricing model, Excel workbook and method note | Reproduces last year's actual revenue within 2%; the client's finance lead can update every input | [date] |
| D3 | Recommendations, slide deck of 15 to 25 slides | Presented to the steering committee; each option has a cost and a revenue estimate | [date] |
The test for each criterion: could someone who did not do the work check it? "Report approved by the client" fails. "Covers the 3 business units in scope" passes.
05 Milestones and payment
| ID | Milestone | Deliverables | Payment |
|---|---|---|---|
| M1 | SOW signed and kick-off held | None | 20% of fees |
| M2 | Current-state assessment accepted | D1 | 30% of fees |
| M3 | Pricing model accepted | D2 | 30% of fees |
| M4 | Final recommendations accepted | D3 | 20% of fees |
Then state the total fees excluding VAT, the fee type (fixed, or time and materials capped at an amount), that each milestone is invoiced when its deliverables are accepted, the payment term ([30] days from receipt of the invoice) and how expenses are handled.
06 and 07 Client dependencies and assumptions
The Client will: name a sponsor with authority to accept deliverables; provide [data, documents and system access] by [date]; make [roles] available for up to [8] interviews of [60] minutes; and answer questions and review drafts within [3] business days. If a dependency is late, every date that depends on it moves by the same number of days. A delay of more than [10] business days is handled as a change request.
Assumptions follow the same pattern and end with: "If an assumption proves wrong, either party may raise a change request."
08 and 09 Acceptance and change control
The Consultant submits each deliverable with a note listing its acceptance criteria. Within [10] business days, the Client accepts it in writing or lists the criteria it does not meet, with reasons. The Consultant corrects those points and resubmits within [5] business days; the Client then reviews only the corrected points. A deliverable is accepted when the Client confirms it, uses it in its business, or does not reply within the review period.
Either party may request a change in writing. Within [5] business days the Consultant replies with its impact on scope, dates and fees. Work on a change starts only after both parties approve it in writing; approved changes become part of this SOW.
A change request form and a change log annex record what was approved and when.
10 to 12 Governance, people and signatures
A weekly status update, a steering committee every [4] weeks, the client's shared workspace, an escalation path, the key people and the signature blocks.
Four rules for filling it in
- Describe results, not hours. US federal acquisition rules ask agencies to describe work by its required results rather than by method or hours, measured against standards [3]. The same discipline helps a fixed-fee consultant: the client buys a model that reproduces last year's revenue within 2%, not "40 hours of analysis".
- Date every dependency. "Timely access to data" protects nobody. "Data by 15 November, dates move day for day if it is late" protects both sides.
- Keep acceptance short and final. Under the EU Late Payment Directive, acceptance or verification should not exceed 30 calendar days from receipt of the services unless expressly agreed and not grossly unfair to the supplier [4]. Ten business days plus deemed acceptance stays well inside that.
- Name the obvious extras. If you can guess the next request (another country, implementation, training), list it as out of scope now. When the email arrives, the change request is half written.
After signature: run the SOW in GoCons
In my own consulting work, the signed SOW used to sit in a shared folder while the plan lived in a spreadsheet. By week four nobody opened the PDF, which is exactly when scope questions start. Building GoCons for our own projects taught me that the SOW has to become the structure the team works in.
In GoCons, the SOW becomes a contract of the matching type, usually a Service Project (fixed fee, billed per milestone or once) or Time and Material, two of the nine contract types, with its dates, fees, payment term and currency.
Each milestone in section 05 becomes a GoCons milestone with its deadline inside the contract dates. It shows Pending, then Approaching in the final seven days, then Overdue if the deadline passes, until you mark it Completed and the completion date is kept.
The activities in section 03 become tasks with an assignee, estimated hours and a deadline. Hours are recorded on the task (there is no built-in timer or timesheet), and each task shows On Time, At Risk or Overdue. The signed SOW goes into the contract's documents.
Payment follows section 05: the billing schedule lists one line per milestone, each Scheduled, Issued, Overdue or Paid. GoCons does not issue invoices or take payments; you attach the invoice your invoicing software issued, and GoCons reminds you before each line is due and alerts you when one is overdue.
Your client sees the same structure: invite the sponsor and they get a free login to follow milestones, tasks, hours and documents instead of emailing "where are we?". The client portal is in every plan (see the client portal software comparison), and Claude can read the same milestones through the GoCons MCP server, as the Claude MCP guide explains.
A spreadsheet can hold the same dates, but it cannot warn you before a deadline, show them to the client, or record who changed a contract date. GoCons writes every status and date change to the contract history, with the user and the time.
Setting it up: the honest answers
- Do I need an implementation project? No. Create the account, add the contract and its milestones, and invite the client. The Free plan needs no credit card.
- Will my client pay or install anything? No. Client users are free and unlimited, and the portal runs in the browser.
- Is it priced per user? No, per consultancy. At the time of writing (October 2026), Free is EUR 0 with 2 team users and 10 active contracts, and Silver is EUR 29 a month excluding VAT with 10 team users and unlimited contracts (current prices).
- What if I leave? An Admin can download all the consultancy's data at any time, on every plan: contracts, clients and team members as Excel files, plus every document.
FAQ
What is the difference between a statement of work and a contract?
The SOW describes one project: scope, deliverables, schedule and fees. The consulting agreement holds the legal terms that apply to every project with that client. Most consultancies sign the agreement once and an SOW for each project.
Who should write the statement of work?
Usually the consultant drafts it and the client reviews it. Involve the people who will deliver the work, not only the person who sold it [1].
How detailed should acceptance criteria be?
Detailed enough that someone outside the project could check them: a format, a page limit, the units covered, a tolerance. One to three criteria per deliverable is usually enough.
Is a statement of work legally binding?
Signed under a contract, it is normally treated as part of that contract, but enforcement depends on your jurisdiction, which is why a lawyer should review the template before you use it.
Start with your next SOW
The next statement of work you sign can be the structure your team and your client work from, not a PDF in a folder. Add the contract, its milestones and your client: create your free GoCons account.
References
- Project Management Institute (M. G. Martin, PM Network, 1998), "Statement of Work: The Foundation for Delivering Successful Service Projects", https://www.pmi.org/learning/library/statement-work-delivering-successful-service-projects-4761 (accessed October 2026).
- Project Management Institute, "Pulse of the Profession 2021: Beyond Agility", https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pmi_pulse_2021.pdf (accessed October 2026).
- Acquisition.gov, "Federal Acquisition Regulation 37.602: Performance work statement", https://www.acquisition.gov/far/37.602 (accessed October 2026).
- EUR-Lex, "Directive 2011/7/EU on combating late payment in commercial transactions", https://eur-lex.europa.eu/eli/dir/2011/7/oj (accessed October 2026).
© 2026 Mourinho Solutions. All rights reserved.
