Statement of work template
Most project disputes are scope disputes. goHeather writes a statement of work with deliverables, acceptance criteria, milestones and a change-control process, so both sides know what finished looks like before anyone starts.
Any country or jurisdiction you tell it- Deliverables and acceptance criteria, in writing
- Milestones tied to payment
- Change control that stops scope creep
Recognized by
What is a Statement of Work?
One project, described precisely enough to finish it
A statement of work is the document that says what is actually being done. It names the deliverables, the schedule, the price, who does what, and — the part most SOWs skip — how everyone will know the work is complete and acceptable.It usually sits underneath a master service agreement, which carries the legal terms. That split is deliberate: the MSA is negotiated once by lawyers, and each SOW is written by the people running the project. A SOW can also stand alone for a one-off engagement, in which case it needs the key legal terms folded into it.The reason SOWs matter more than their length suggests is that almost every services dispute is a scope dispute. Not a liability argument, not an IP argument — a disagreement about whether something was in scope. A SOW with real acceptance criteria is the cheapest insurance available against that.
What often goes wrong in a SOW
Patterns that come up again and again, and how goHeather handles them.
A SOW written in a hurry
- Deliverables described as activities, so nobody can say when the work is finished
- Acceptance "to the client's satisfaction", which means whatever the unhappier party wants it to mean
- No out-of-scope list, so every question becomes a negotiation
- Changes agreed verbally and invoiced later
- The whole fee payable up front, or on a single milestone at the very end
Building it with goHeather
- Deliverables are itemised as things, each with a testable acceptance standard
- An explicit out-of-scope list sits next to the scope
- Change control requires a signed change order stating the new scope, price and date
- Payment is tied to milestones, so money tracks progress
- Assumptions and client dependencies are written down before the estimate is relied on
From blank page to signed SOW
goHeather is not a template download. It is a contract builder that walks you through the document, powered by the latest AI models.
- Start
Start from scratch or from a template
Describe the deal in your own words, or pick a Statement of Work template and work from there. Either way goHeather builds the document with you rather than handing you a file to fill in.
- Answer
Answer questions as it drafts
goHeather asks who the parties are, what the deal covers and where you operate, and writes each clause around your answers as you go.
- Review
See every clause explained
Each clause comes with a plain-English summary of what it does, so you know what the document says before you send it.
- Negotiate
Check what comes back
Upload the other side’s edits and goHeather shows each change against the version you sent, flagged by risk.
- Sign
Send it for signature
Collect e-signatures and keep the executed copy, the key dates and the renewal terms in one place.
20,000+
SMBs and small law firms trust goHeather
$1,419
Average saving vs. a lawyer per deal
10,500+
Lawyer-made templates to draft from
25+
Enterprise-grade security controls
Who needs a Statement of Work
Where this document usually shows up, and what else goHeather covers there.
- Professional services
Agencies and consultancies
Your SOW is the document that decides whether a project is profitable. Get the scope, the assumptions and the change control right.
See contract AI for professional services
- Procurement
Buying project work
Put every engagement under a negotiated master agreement and keep the SOW to scope, price and acceptance.
See contract AI for procurement - Framework
The MSA it sits under
A SOW works best with a master service agreement above it carrying the liability, IP and confidentiality terms.
See the MSA template - Compare
Check a revised SOW
When a supplier returns a marked-up scope, compare it with what you sent and see exactly what moved.
Compare two versions of a document
Your contracts stay yours
A Statement of Work carries names, numbers and terms you would not want shared. goHeather protects every document you draft or upload with enterprise-grade controls, end-to-end encryption and trusted AI providers.
Learn more about security
Contracts encrypted with gold-standard protection- Database provider meets bank-grade security
- Your documents and data will never be sold
- We do not use your data to train our models
Statements of work and where scope disputes start
goHeather is a technology company, not a law firm, and this page is not legal advice. It describes what our software does. Nothing here states the law or tells you what your contract needs — for that, talk to an attorney licensed where you operate.
Nearly every dispute between a client and a services provider is an argument about scope, and almost all of them were avoidable at the drafting stage. The sections below cover the three things a statement of work has to nail — what is being delivered, how acceptance is judged, and what happens when the scope moves — plus the pricing structures and what each one puts at risk. None of this is legal advice.
What goHeather covers in a Statement of Work
These are the parts of a Statement of Work goHeather asks you about while it builds one, and the parts it looks at when you upload one somebody else sent. It is a description of what the product does — not a checklist for your document, and not a view on what yours needs.
- Scope and objectives. A plain description of what the project is for and what it covers, with an explicit list of what it does not. goHeather flags: An out-of-scope list is the most useful paragraph in a SOW and the one most often left out.
- Deliverables. The specific, itemised things that will be handed over — documents, code, designs, environments, training. goHeather flags: Deliverables described as activities ("provide consulting support") give nobody anything to point at when the project ends.
- Acceptance criteria and process. The objective standard each deliverable must meet, who reviews it, how long they have, and what happens if they reject it. goHeather flags: "To the client's satisfaction" is unmeasurable; a three-day deemed-acceptance window is too short to test anything real.
- Timeline and milestones. The schedule, the dependency on client inputs, and the dated checkpoints that payment attaches to. goHeather flags: A schedule with no client-dependency clause makes the provider liable for delays caused by the client's own review cycles.
- Fees and payment schedule. Fixed price, time and materials or capped time and materials, and when each portion falls due. goHeather flags: Time and materials with no not-to-exceed figure is an open check; fixed price with a vague scope is a dispute waiting to happen.
- Change control. The written process for changing scope, price or schedule once work has started. goHeather flags: If changes can be agreed by email or in a stand-up, the scope will move and nobody will agree afterwards about when.
- Key personnel and responsibilities. Who is doing the work, who the client's decision-maker is, and what the client has to provide for the project to run. goHeather flags: Naming senior people who then never appear on the project is a familiar agency tactic; a key-personnel clause with substitution consent addresses it.
- Assumptions and dependencies. The facts the estimate relies on — available environments, data quality, client sign-off times, third-party cooperation. goHeather flags: Unstated assumptions become the provider's risk by default, and the price was not built for that.
- Relationship to the master agreement. Confirms the SOW is governed by the MSA and which document prevails on what. goHeather flags: A standalone SOW with no MSA behind it and no legal terms of its own leaves liability, IP and confidentiality undefined.
Why deliverables are usually described as things, not activities
The single most useful discipline in writing a SOW is to list deliverables as nouns. "A migrated production environment", "a set of twelve page designs in Figma", "a written data model". Not "provide migration support" or "assist with design work".
Activities cannot be completed, only stopped. If a deliverable is an activity, there is no moment at which the provider has finished and no moment at which the client can reasonably refuse to pay. Every open-ended engagement that quietly consumed three times its budget started with a scope written as verbs.
Pair the scope with an explicit out-of-scope list. It feels negative and it is the most valuable paragraph in the document. Naming the five things people will most likely assume are included — data cleansing, training, third-party license costs, post-launch support, integration with the legacy system — settles five future arguments for free.
- List each deliverable as a thing that can be handed over
- Say what format it arrives in and who it goes to
- Add an explicit out-of-scope list next to the scope
- Write down the assumptions the estimate depends on
What makes acceptance criteria workable
Acceptance criteria answer one question: how do we know this is done? The answer needs to be something a reasonable third party could check. Performance thresholds, test cases that pass, a checklist of required features, conformance to a specification attached as an exhibit.
"To the client's satisfaction" fails that test and hands the client an effective veto. Providers often refuse it. Equally, clients often push back on a deemed-acceptance window so short that nobody could realistically test the deliverable — three business days for a platform migration is not a review period, it is a formality.
Set out the loop as well as the standard: how long the client has to review, what a rejection notice must say, how long the provider has to fix it, and how many cycles happen before the parties escalate. Without that, a rejected deliverable has nowhere to go.
Fixed price, time and materials, or a cap
Fixed price moves the risk of an overrun to the provider, which is comfortable for the client and only safe for the provider if the scope is genuinely tight. A fixed price attached to a loose scope is the worst combination available — the provider absorbs every ambiguity, and eventually stops cooperating.
Time and materials moves the risk to the client. It suits work where the shape genuinely is not known at the outset, such as a discovery phase. What it needs is a not-to-exceed figure, so the client has a ceiling and a trigger to review.
Capped time and materials is the common compromise: billed by effort, capped at a number, with the cap adjustable only through change control. Whichever you pick, tie payment to milestones rather than to the calendar. Money that tracks progress keeps both sides honest, and it is the only real leverage a client has if delivery stalls.
How change control is usually handled
Scope creep is rarely one big decision. It is twenty small ones, each agreed informally by somebody who was not thinking about the contract, and the cumulative effect only becomes visible when the project is late and over budget.
A common approach is a change-control clause that requires a written change order, signed by a named person on each side, stating the revised scope, the revised price and the revised date — before the work starts. The point is not bureaucracy for its own sake. It is to make each small change visible as a decision with a cost attached.
Name the people who can sign one. A change-control process that anybody can trigger is the same as not having one, and a project manager agreeing to extra work in a stand-up is how most overruns begin.
Why goHeather asks what sits above the SOW
A statement of work usually inherits its legal terms from a master agreement above it, so the first thing goHeather asks is whether there is one. If there is, it keeps the SOW to scope, deliverables, acceptance, schedule and price, and checks that nothing in it contradicts the framework it sits under. If there is not, it prompts you for the terms the document would otherwise be missing entirely — liability, ownership of the work, confidentiality and governing law — because a SOW written to sit under an MSA and then used on its own leaves all of that undefined. It also asks whether goods are involved alongside the services, and whether the work is publicly funded, since both change what the document needs. For the terms themselves, a commercial attorney is the right reviewer.
Before you go. goHeather is a technology company, not a law firm. We do not provide legal advice, legal opinions, or any view on whether a contract or a clause will hold up. Everything above describes what our software does when you build or upload a document. Rules differ from state to state and change over time, and what is right for your business depends on facts we do not have. Have an attorney licensed where you operate review anything that matters.
Other contracts goHeather builds
goHeather drafts any business contract. These are the ones that usually travel with this one.
- Framework
Master Service Agreement template
Negotiate the legal terms once, then run every project under a short statement of work.
See the MSA template - Freelance
Independent Contractor Agreement template
Engage a freelancer or agency on clear terms: scope, pay and who owns what gets made.
See the contractor agreement template - Construction
Subcontractor Agreement template
Pass work down the chain without passing down more risk than you meant to: scope, flow-down and payment.
See the subcontractor agreement template
Need a different contract?
goHeather drafts any business contract, not just the ones listed here. Browse every template or start from a blank brief.
SOW template questions
What people ask before they build a Statement of Work.
Still have questions?
Build a SOW and see what goHeather produces, or book a short demo and we will go through one of your own documents with you.
Trusted by 20,000+ SMBs and small law firms
Scope your next project properly
Build a statement of work with real acceptance criteria and change control, or upload the one you were sent and see what goHeather flags.
Free to try