Most automation disputes aren't about code. They're about a sentence like "we'll set up AI to handle enquiries," which the client reads as "all enquiries, forever, perfectly." This AI automation SOW template for freelancers turns that sentence into numbered deliverables, tests the client signs off, and a clause for the thing that makes AI work different: the model's output isn't fully predictable and the provider can change it.
Copy the template below, fill the bracketed variables, and read the notes under each section. This is not legal advice. It's a structure to help you think through scope, and a lawyer should review your final version once.
If you haven't done the scoping call yet, start with the sheet in the agency pricing and scoping post. If you want a model to attack a draft for ambiguity, the SOW checker prompt does that, and I won't repeat it here.
What does the proposal cover versus the SOW?
Keep them separate in your head, even if they sit in one document.
- Proposal: persuades. The client's problem, your approach, price, timeline, why you.
- SOW: binds. Exactly what is delivered, what is excluded, how it's accepted, how it's changed.
Send the proposal first. When the client says yes, the SOW is the version both sides sign. Below is the SOW.
The SOW template
STATEMENT OF WORK
Between: [YOUR NAME / BUSINESS] ("Provider") and [CLIENT COMPANY] ("Client")
SOW number: [SOW-001] Date: [YYYY-MM-DD]
1. OBJECTIVE
[One sentence: the outcome the Client wants.]
2. DELIVERABLES
D1. Workflow "[NAME]"
Trigger: [form submission / incoming email / schedule]
Input: [what arrives and in what format]
Processing: [steps, including any language model step and its purpose]
Output: [what is produced and where it is delivered]
Volume covered: up to [N] runs per [day/month]
D2. Alert workflow that notifies [NAME] at [CONTACT] when any D1 run fails.
D3. Handover runbook (architecture, credentials register, backup plan).
D4. [N] hours of training for [NAMES], delivered by [DATE].
3. OUT OF SCOPE (not included unless added by change request)
- [Workflows other than those listed in section 2]
- [Languages other than ___]
- [Integrations with ___]
- [Cleaning or migrating existing historical data]
- [Ongoing monitoring or support after the warranty period]
4. CLIENT RESPONSIBILITIES
- Provide access to [SYSTEMS] within [N] working days of signing.
- Provide [N] real sample inputs for testing by [DATE].
- Name one decision-maker, [NAME], who gives approvals.
- Pay for third-party services (hosting, APIs, model usage) directly.
- Provide feedback within [N] working days of each request.
If feedback is late, dates move by the same number of days.
5. TIMELINE
Milestone 1: Design sign-off by [DATE]
Milestone 2: Test build ready for review by [DATE]
Milestone 3: Go-live by [DATE]
Dates depend on Client responsibilities in section 4.
6. PRICE AND PAYMENT
Fixed price: [AMOUNT] [currency], excluding any taxes that apply.
Schedule: [X]% on signing, [Y]% on Milestone 2, [Z]% on acceptance.
Invoices due within [N] days.
Third-party costs (hosting, APIs, model usage) are paid by the Client directly.
[Tax treatment to be confirmed by each party's own adviser.]
7. ACCEPTANCE
See "Acceptance criteria" below. Acceptance is given in writing by the named
decision-maker. If the Client gives no written response within [N] working
days of the Provider's acceptance request, the deliverable is treated as
accepted, unless the Client has reported a failed criterion in writing.
8. CHANGE REQUESTS
See "Change request clause" below.
9. AI-SPECIFIC TERMS
See "AI clauses" below.
10. OWNERSHIP AND ACCESS
- The Client owns the accounts the workflows run in. The Provider holds
access only during the project and any support plan.
- Ownership of the delivered workflow files, and any rights the Provider
keeps in general know-how or reusable components: [ASK A LAWYER; state it].
- Confidential information: [reference to NDA or short clause].
11. WARRANTY AND SUPPORT
Warranty: the Provider will fix failures of the acceptance criteria that are
reported within [N] days of go-live, at no extra charge. After that, support
is available under [SUPPORT PLAN or hourly rate].
12. LIABILITY AND TERMINATION
[Have a lawyer draft or review this section. Do not copy from a blog.]
Signed: ____________ (Provider) ____________ (Client) Date: ________
A few notes on the choices.
Deliverables are numbered and countable. "Up to [N] runs per day" gives you a boundary. Without it, a client who triples their traffic believes the price should cover it.
Out of scope has to be written. The things clients assume are included are rarely the ones you thought to list, so ask the client what they expect and write down the items that aren't in. Three entries is a minimum.
Client responsibilities have consequences. The sentence "dates move by the same number of days" is what stops a stalled approval turning into your delay.
Third-party costs go to the client directly. Otherwise your fixed price silently absorbs usage costs that scale with their business.
How do you write acceptance criteria for an AI workflow?
For ordinary software, acceptance can be binary. For a workflow with a language model inside, outputs vary, so agree a test, not a promise. Use this structure.
ACCEPTANCE CRITERIA (Workflow D1)
A. Test set
The Client supplies [N] sample inputs (target 30 or more, including at least
[5] hard or unusual cases). The Provider and Client agree the expected
output for each before testing begins. Test set version: [DATE].
B. Pass mark
D1 is accepted when, on the agreed test set:
- at least [X] of [N] outputs match the expected output, AND
- every output that does not match is either flagged as uncertain and
routed to [NAME] for review, or is explicitly listed as a known limit, AND
- zero [critical failure, e.g. messages sent to the wrong recipient].
C. Failure paths
The Provider demonstrates: (i) a failed API call, (ii) an unreadable input,
(iii) a missing field. In each case, no customer-facing message is sent and
an alert reaches [NAME] within [N] minutes.
D. Judge
[NAME], on the Client side, decides whether an output is correct.
Disputed items are resolved by [process].
E. Records
Test results are recorded in a shared sheet and attached to the acceptance
email.
Why this works: the pass mark is on a set both sides saw, so neither can claim later that the test was unfair. The "zero critical failures" line lets you separate "the workflow made a typo" from "the workflow did something harmful." And the failure paths test the thing clients forget: what happens when it breaks.
Choose [X] honestly. I can't give you a standard pass mark, because it depends on the task, the cost of an error and whether a human reviews outputs. If a human approves every output before it goes out, a lower pass mark can be reasonable. If the workflow acts on its own, set it higher or add a review step. Your scoping notes and the cost of a wrong answer should decide, not a number from a blog.
What should a change request clause say?
Make the process cheap to follow and impossible to skip.
CHANGE REQUESTS
1. A change is any addition or alteration to the deliverables, volumes,
systems or acceptance criteria in this SOW. Fixing a failure of an
agreed acceptance criterion is not a change.
2. Either party may request a change in writing (email is fine).
3. The Provider will respond within [N] working days with the effect on
price and timeline.
4. Work on the change starts only after the Client approves the quote in writing.
5. Changes are priced at [RATE] per hour, or a fixed quote if the Provider
offers one.
6. Verbal requests and chat messages do not change this SOW.
Point 1 is the key. It draws a line between "your workflow is broken" and "I'd like it to do something new." A client who says "just add one more field" now gets a written quote, not a favour. Pair it with a revision allowance for the design stage if you like, such as two rounds of consolidated feedback, so early feedback doesn't count as a pile of change requests.
What AI clauses should an automation SOW include?
These are example clauses for the parts of AI work that standard freelance templates miss. Adapt them, and have a lawyer check the final wording.
AI-SPECIFIC TERMS
A. Nature of model output
D1 uses a third-party language model. Outputs can be incorrect, incomplete or
vary between runs. The Provider does not warrant that outputs will be
error-free. The Provider warrants only that D1 meets the acceptance criteria
on the agreed test set at the time of acceptance.
B. Review points
The parties have agreed that [outputs of type X] require human review by
[NAME] before use. The Client is responsible for the review it elects not to
perform, and for decisions made on unreviewed outputs.
C. Model and provider changes
Model providers may update, replace or retire models, and may change
pricing and terms. The current model is [MODEL NAME] from [PROVIDER].
After the warranty period, re-testing or re-prompting due to such changes
is covered by [SUPPORT PLAN] or charged at [RATE].
If the Provider is notified of a retirement affecting D1, it will tell the
Client within [N] working days.
D. Error-rate monitoring
For [N] days after go-live, the parties will review [N] sampled outputs
per week. If the review shows a failure of the acceptance criteria, the
Provider will correct it under the warranty.
E. Data handling
Input data may be sent to [PROVIDER] for processing. The Client confirms it
has the right to send this data. The Provider will not use the Client's
data for other clients or for training any model it controls. Data
retention period for logs and executions: [N] days.
F. No professional advice
D1 does not provide legal, medical, financial or tax advice. Outputs are
not to be presented as such.
G. Costs that scale
Model and API usage costs depend on volume and are paid by the Client. The
Provider has given an estimate of [AMOUNT] per month at [N] runs, which is an
estimate, not a cap. A usage alert is set at [AMOUNT].
Why each clause exists:
- A stops "AI should be perfect" before it starts, without hiding behind it.
- B puts the human in the loop on paper, so the loop is real.
- C matters because the thing you tested can change under you. I haven't cited a specific provider's deprecation policy here, and you should read the current one for the model you use rather than assume.
- D turns "error rate" into a process, instead of a number you can't guarantee.
- E needs facts about your actual stack. Check each provider's current data terms yourself, as they differ and change.
- G is the clause that saves you from a surprise bill landing on your side.
A worked example (illustrative)
This is an invented scenario to show the clauses working together, not a real client.
A small clinic wants enquiry emails sorted into "appointment request," "billing" and "other," with appointment requests logged in a sheet. The deliverable D1 handles up to 40 emails a day. The test set is 30 emails supplied by the clinic, including 5 hard ones such as mixed-language messages. The pass mark is 27 of 30 correct, every miss routed to the receptionist, and zero emails sent to patients automatically. On day 12 the clinic asks: "Can it also reply to patients?" That's a customer-facing action outside D1, so it triggers the change request clause, a new quote and a new acceptance test, plus a review step, because replying to patients is exactly where wrong output costs most. The clinic hasn't been told "no." It's been told "yes, here's what it costs and how we test it."
(The numbers 40, 30 and 27 are invented to show the structure.)
What do you send with the SOW?
Attach three things so the SOW isn't the only thing the client reads:
- A one-page diagram or list of the workflow (what happens, in order).
- The out-of-scope list in plain words, in the covering email.
- The handover runbook outline, so the client sees what they'll receive at the end.
Then ask for a reply that says "I've read section 3 and agree it's out of scope." Clients read the price. Make them read the exclusions too.
Before you use it
Read the template once as a hostile, literal-minded client. Look for every vague word: "support," "minor," "quickly," "as needed." Replace each with a number, a date or a named person. Then have a lawyer review the whole template once, particularly sections 6, 10, 11 and 12, which I've left as skeletons with placeholders rather than finished clauses. For tax, GST and foreign payment questions, ask a chartered accountant. I haven't verified any rule on those topics for this post, so none is stated.
I wrote this template by hand and haven't tested it against a real dispute. Treat it as a checklist of things worth agreeing in writing, then adapt it to your project.
