How to write a statement of work for an AI project
A statement of work for an AI project is a one-page document with five parts: one paragraph naming the outcome, a bulleted list of exactly what is included, a bulleted list of what is explicitly excluded, a single-line timeline, and a payment-terms line. You send it before any work starts and get it signed back before you write a single prompt. That one discipline saves more revenue than any rate increase, because it stops scope creep before it begins instead of arguing about it after.
The SOW does not need to be a twenty-page legal contract. For AI builds under $15K it is one page, plain language, sent as a document the client can read in two minutes and sign in one. Its job is not to win a lawsuit - it is to make sure you and the client are holding the exact same picture of what is being delivered before either of you commits time or money. This is the CCC One-Page-SOW method: the shortest document that still closes cleanly and protects your margin.
The five parts of a one-page SOW
Every part earns its place. Cut any one of them and you reopen a gap the client will walk through later. Here is what each part does and why it is there.
The five parts of an AI-project statement of work
| Part | What it says | Why it is there |
|---|---|---|
| Outcome | One paragraph naming the finished thing and the result it produces | Anchors the whole document to a deliverable, not to your hours |
| Included | A bulleted list of exactly what you will build and hand over | Turns a vague idea into a countable set of deliverables |
| Excluded | A bulleted list of what is explicitly NOT in scope | Kills the assumptions that cause every scope-creep fight |
| Timeline | A single line: start, delivery, and any review windows | Sets a shared expectation so "when is it done" is already answered |
| Payment terms | 50% on signing, 50% on delivery, and what triggers each | Gets money moving and defines what "delivered" means for the final payment |
Notice what is not on the list: your methodology, your tools, or how many hours you expect it to take. The client is buying an outcome, not your process. Lead every line with the result the client gets. The mechanism - that you built it with Claude Code in a weekend - belongs in your head, not on the SOW.
The outcome paragraph: sell the result, not the build
The outcome paragraph is the one part a non-technical client actually reads closely, so make it about them. Name the finished thing and the result it produces in their words. "A booking system on your site that lets clients pick an open time and book themselves, so your front desk stops playing phone tag" beats "a full-stack web application with a calendar component and a database." Same build, completely different document.
If a client later asks what they are really paying for, the honest answer should already be the first sentence of the SOW. Lead with the outcome on every line and the price stops feeling like an hourly rate and starts feeling like the cost of a solved problem. That reframe is worth more than any discount.
The excluded list does the heavy lifting
Most people write the included list and stop. That is the mistake. The excluded list is the load-bearing part of the entire document, because most scope creep does not come from a client trying to get free work - it comes from an honest mismatch. The client genuinely thought a feature was included; you genuinely thought it was not. The excluded list is where you resolve that before it becomes a fight over unpaid work.
- Name the obvious adjacent features you are NOT building. If you are building a booking system, exclude the payment integration, the SMS reminders, and the customer login unless they are in the included list. The client may have assumed all three.
- Put a price on the things you are excluding, not just a no. "SMS reminders are not included in this scope; they can be added for a fixed $600." This turns a future argument into a future upsell the client already expects to pay for.
- Exclude open-ended support. If maintenance is not in the SOW, every "quick fix" after launch is unpaid work eating your next project. Either bundle a defined support window ("30 days of bug fixes included") or quote a separate retainer.
- Exclude revision counts you have not agreed to. "Two rounds of revisions on the design are included; further rounds are billed at a fixed rate per round." Unlimited revisions is how a fixed-price project becomes an hourly project you forgot to bill for.
Payment terms that get money moving
For AI builds under $15K, the payment terms that work almost everywhere are 50% on signing and 50% on delivery. The deposit is not optional - it is the line that separates a real project from a client who is still shopping. A client who will not put down a deposit will not respect the scope either. The deposit filters for commitment before you spend a single hour building.
Define what "delivery" means in the same line, because that word triggers your final payment. Delivery is the deployed, working thing doing what the outcome paragraph promised - not "the client is fully satisfied," which is an open-ended standard that never triggers. Tie the final payment to an objective event: the system is live and passes the acceptance checks listed in the SOW. For larger builds, add a milestone payment in the middle so you are never carrying more than a third of the project unpaid.
Send it so it closes instead of stalls
A one-page SOW is a closing tool, so send it like one. Do not attach it to an email with "let me know your thoughts" - that invites edits and delay. Send it as the natural next step after the client has already said yes: "Great - here is the one-page scope so we are both looking at the same thing. Sign at the bottom and I will get started this week." The SOW confirms a decision that has already been made; it does not reopen it.
Keep it to one page on purpose. A twenty-page contract makes a small client nervous and invites their lawyer into a $3,000 deal. One page, plain language, five parts, signed same-day. If a client needs a heavier legal agreement, that is a separate document layered on top - the SOW is what gets the work started this week. Pair it with the [what to put in an AI project contract](/blog/what-to-put-in-an-ai-project-contract) guide when a project is large enough to need both.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
What is a statement of work for an AI project?
A statement of work (SOW) for an AI project is a one-page document that names the outcome in a paragraph, lists exactly what is included, lists what is explicitly excluded, sets a timeline, and states payment terms. It is sent and signed before any work starts, and its job is to make sure you and the client share the same picture of what is being delivered before either of you commits time or money.
What should a statement of work include for an AI build?
Five parts: one paragraph naming the outcome and the result it produces, a bulleted list of exactly what is included, a bulleted list of what is explicitly excluded, a single-line timeline with start and delivery dates, and a payment-terms line (50% on signing, 50% on delivery is the default for builds under $15K). Leave out your methodology and hours - the client is buying an outcome, not your process.
Why is the excluded list the most important part of a SOW?
Because most scope creep is an honest mismatch, not a client trying to get free work. The client thought a feature was included; you thought it was not. The excluded list resolves that before it becomes an argument over unpaid work. Name the most expensive thing a client could reasonably assume is included, and put a fixed price on it so a future dispute becomes a future upsell.
What payment terms should I use in an AI project SOW?
For builds under $15K, 50% on signing and 50% on delivery works almost everywhere. The deposit filters for a client who is committed rather than still shopping. Define delivery as the deployed, working system passing the acceptance checks in the SOW - not "the client is satisfied," which never triggers. For larger builds, add a milestone payment in the middle so you never carry more than a third unpaid.
How is a statement of work different from a contract?
A SOW defines the specific deliverable, scope, timeline, and payment for one project, on one page, in plain language. A contract is the broader legal agreement covering liability, ownership, and terms across the relationship. For most AI projects under $15K a one-page SOW is enough to start work. When a project is large enough to need heavier legal protection, layer a contract on top - do not replace the SOW with it.
Last reviewed by Duncan Rogoff on September 15, 2026
