Contract resource · Updated August 2026
Statement of work template — with a real AI project example
A statement of work is the document a project falls back on when memory and goodwill run out. Here is a complete SOW template you can copy — nine sections, a worked example from an AI engagement, and the clauses that AI and IT projects specifically need but generic templates leave out.
What a statement of work is — and what it is not
A statement of work (SOW) defines one specific project: the deliverables, the schedule, the price, how completion is judged, and who owes what to whom. It usually sits under a master services agreement (MSA), which handles the durable legal relationship — liability, confidentiality, dispute resolution — so each new project only needs a new SOW, not a new contract.
It is not a proposal (which sells the work), not a scope of work (which is one section of it), and not a specification (which can be an appendix). The test of a good SOW is simple: could a neutral third party read it and decide whether the project is done? Most SOWs we see in AI engagements fail that test — usually at the acceptance criteria, and for AI projects that failure is expensive, because a model can be delivered exactly as scoped and still not work.
Both sides need this document to be good. Buyers get protection from scope drift and a completion dispute; independent engineers and boutique consultancies get protection from the “one more revision” spiral and unpaid invoices. We broker AI engagements for a living, and the projects that end badly almost always started with a weak SOW.
The statement of work template
Copy the nine sections below into your document tool and replace every [bracket]. The brackets are where the protection lives — every one you leave vague is a future disagreement. Works for AI, software, and general IT engagements; the AI-specific additions follow in the next section.
Statement of Work — [Project Name] · under MSA dated [date], between [Client] and [Vendor]
1. Background & objective
[Two or three sentences: the business problem, and the single outcome this project exists to produce — e.g. “reduce average support first-response time by handling routine tickets with an AI assistant.” Write the outcome, not the technology.]
2. Scope & deliverables
[Numbered list. Each deliverable is a noun someone can point to: a deployed system, a report, a trained team, source code in the client’s repository. For each: what it is, what form it takes, where it is delivered.]
3. Out of scope
[The adjacent work you are explicitly not doing: other departments, other languages, mobile, ongoing maintenance, data cleanup beyond X hours. This section prevents more disputes than any other.]
4. Timeline & milestones
[Table: milestone, verifiable completion event, target date. Dates are commitments only if Section 7 obligations are met on time — say so here.]
5. Acceptance criteria
[Per deliverable: the measurable test the client will run, who runs it, and the review window — e.g. “Client has [10] business days to test against the criteria; deliverable is accepted when criteria pass or the window lapses without written defect notice. Defects are fixed and resubmitted once per round, [2] rounds included.”]
6. Pricing & payment
[Fixed fee per milestone, or time & materials with rate, cap, and invoicing cadence. Payment due [15/30] days from invoice; late payments pause work. State who pays third-party costs — cloud, model APIs, licenses.]
7. Client obligations
[What the client must provide and by when: data access, system credentials, a named decision-maker, subject-matter-expert hours per week, review turnaround. Missed obligations extend the timeline day-for-day.]
8. Change management
[Any change to scope, timeline, or price requires a written change order signed by both parties, priced at [rate]. No verbal changes. Small wording, large protection — for both sides.]
9. Assumptions, IP & termination
[Key assumptions the price depends on. IP: work product assigned to client on full payment; vendor retains pre-existing tools and general know-how. Termination: either party on [15] days’ written notice; client pays for work completed and accepted through the notice date.]
Get this template as an editable Word doc
All nine sections, the milestone table, and the AI-specific guidance notes — formatted and ready to fill in. Drop your email and it's yours.
The clauses AI projects need that generic templates miss
Evaluation as acceptance.A deployed chatbot is not a result; a chatbot that answers an agreed test set at an agreed accuracy is. Write the evaluation into Section 5: the test set (built or approved by the client), the metric, the threshold, and what happens below it. This is the single biggest difference between an AI SOW and a software SOW — probabilistic systems need a statistical bar for “works,” not a demo. Our project scoping pack includes a worksheet for setting these thresholds before the SOW is drafted.
Data reality in client obligations. Most AI project delays are data delays. Section 7 should name the datasets, the access mechanism, the date, and a data-quality assumption (“vendor assumes exports match the sample reviewed on [date]; material deviations are a change order”). Without this, the vendor eats weeks of cleanup or the client eats a surprise invoice — we have seen both.
Model and API cost ownership. Inference costs money every month, forever. State who pays for model API usage and cloud infrastructure during development, during the acceptance window, and after handover — and require a cost estimate per deliverable so a $400/month prototype doesn’t become a $9,000/month production bill nobody budgeted. Sanity-check the totals against real AI development cost benchmarks.
IP that names AI artifacts. “Work product” is ambiguous when the work includes prompts, fine-tuned model weights, evaluation datasets, and data pipelines. Name them. The default that serves both sides: client owns project-specific prompts, weights, and eval sets; vendor keeps general-purpose tooling and know-how. Ambiguity here is worst for the client — you can lose the ability to switch vendors without rebuilding.
A pilot decision point with kill criteria. Structure AI work in two SOWs, not one: a scoped pilot with explicit success thresholds, then a production SOW signed only if the pilot clears them. MIT’s NANDA research put enterprise GenAI pilot failure around 95% — the SOW should make stopping cheap instead of pretending failure is impossible. Our guide to running an AI proof of concept covers how to set the kill thresholds.
Worked example: an IT statement of work for an AI pilot
The template, filled in for a realistic engagement — a mid-market company piloting an AI support assistant with a contract AI engineer. Details condensed; the structure is what to copy.
Example — SOW #1: Support Assistant Pilot · Acme Insurance Services & [Contractor], under MSA of June 3, 2026
Objective
Determine whether an AI assistant grounded in Acme’s policy documentation can draft accurate first responses to routine support tickets, reducing median first-response time from 9 hours toward a 1-hour target.
Deliverables
(1) Evaluation harness: 150-question test set built from historical tickets, approved by Acme’s support lead. (2) Retrieval-augmented drafting system deployed to Acme’s staging environment, integrated with Zendesk sandbox. (3) Pilot report: accuracy results, per-ticket cost, production recommendation. (4) Source code and prompts in Acme’s GitHub organization.
Out of scope
Production deployment; tickets in Spanish; billing-dispute tickets; Zendesk production configuration; ongoing monitoring (each a future SOW if the pilot clears its thresholds).
Timeline
Week 2: test set approved. Week 4: system answering test set end-to-end in staging. Week 7: threshold evaluation complete. Week 8: pilot report and decision meeting.
Acceptance & kill criteria
Pilot succeeds if ≥85% of test-set drafts are rated “sendable with minor edits” by two Acme reviewers, hallucinated policy citations are ≤2%, and modeled cost is ≤$0.40 per ticket. Below 70% sendable at week 7, the parties meet to continue, re-scope, or stop — stopping owes only work completed to date.
Pricing & obligations
Fixed fee $58,000: $14,500 on signing, $14,500 at each accepted milestone (weeks 2, 4, 8). Acme provides: policy-document export and 12 months of ticket history by day 3, staging Zendesk access by day 5, two reviewer hours per week, 5-business-day review turnaround. Model API costs to Acme’s account (estimated $300–600 for the pilot). Acme owns all prompts, code, and the test set on final payment.
Notice what makes this example work: every milestone is verifiable, the kill criteria make a negative result a clean outcome instead of a dispute, and the client obligations are as specific as the vendor’s. Rates and totals here are typical for senior contract AI work — calibrate against our AI consulting rates guide.
SOW red flags — for whichever side you’re on
| Red flag | Why it burns you | The fix |
|---|---|---|
| Vague acceptance criteria | "Client satisfaction" or "industry standards" as the completion bar | Every deliverable gets a measurable test the client can run |
| No out-of-scope section | Everything not listed becomes an argument later | Name the adjacent work you are explicitly not doing |
| No client obligations | Vendor carries schedule risk for data and approvals it does not control | Data access, reviewer availability, and decision SLAs in writing |
| Payment tied only to the end | One invoice at "completion" invites a completion dispute | Milestone payments tied to accepted deliverables |
| Team bait-and-switch | The people who pitched are not the people who build | Named individuals, with substitution requiring written approval |
| Unlimited revisions | "Until client is satisfied" has bankrupted small consultancies | Fixed revision rounds, then change-order rates |
Buyers: an SOW with three or more of these is telling you how the engagement will end. Our guide to vetting AI consulting firms covers the questions to ask before you get to contract. Engineers and boutiques: the revision and payment rows are where independent practices actually lose money — our freelance AI engineer guide goes deeper on contract terms.
A good SOW needs the right counterparty
The template protects the engagement; it can’t vet the people. If you’re about to sign AI work with a vendor you found cold, brief us first — we’ll match you with two or three pre-vetted engineers or consultancies whose production track record we’ve verified, and whose SOWs already look like the one above.
Frequently asked questions
What is a statement of work?+
A statement of work (SOW) is the document that defines a specific project between a client and a vendor: what will be delivered, by when, for how much, how completion is judged, and what each side is responsible for. It sits under a master services agreement (MSA), which handles the legal relationship — the SOW handles this project. When a project goes wrong, the SOW is the document both sides reach for first.
What is the difference between a statement of work and a scope of work?+
The scope of work is one section inside the statement of work. The statement of work is the full project document — scope, timeline, pricing, acceptance criteria, responsibilities, and change management. In practice many people use the terms interchangeably and abbreviate both to SOW, but if a vendor sends you a document that contains only scope with no acceptance criteria or payment terms, you have a scope of work, not a statement of work — and you are not protected.
Who writes the statement of work — the client or the vendor?+
Usually the vendor drafts it and the client negotiates it, because the vendor knows what delivery actually involves. But the client should never sign a first draft unchanged: the sections that most need client attention — acceptance criteria, client obligations, and IP ownership — are exactly the ones a vendor-drafted SOW writes in the vendor’s favor. Sophisticated buyers bring their own acceptance criteria to the negotiation.
What should a statement of work include for an AI project?+
Everything a standard SOW includes, plus clauses most templates miss: evaluation criteria for probabilistic output (accuracy thresholds on an agreed test set, not "works correctly"), data access obligations with dates, ownership and payment of model/API costs, IP terms covering prompts, fine-tuned weights, and evaluation data, and a defined pilot decision point with kill criteria. An AI system can be delivered exactly as scoped and still be useless — the evaluation clause is what makes "done" mean "works."
Is a statement of work legally binding?+
Yes, when signed it is a contract — typically incorporated under a master services agreement that governs liability, confidentiality, and dispute resolution. That is why the details matter: courts and mediators read the acceptance criteria you actually wrote, not the intentions you had. If there is no MSA, the SOW should include basic terms (confidentiality, IP assignment, limitation of liability, termination) or reference a standalone services agreement.
How detailed should milestones be in an SOW?+
Detailed enough that an outsider could verify each one happened. "Phase 2 complete" is not a milestone; "retrieval pipeline deployed to staging, answering the 50-question test set at the agreed accuracy threshold" is. For AI projects, tie at least one early milestone to a working evaluation harness — it forces the quality conversation into week two instead of week eight, when it is expensive.