How to write an agency statement of work, with a change-request process that stops scope creep

The short answer

A statement of work (SOW) says exactly what your agency will deliver on one piece of work, how the client will know each part is done, what it costs, and what happens when the client wants something different. It sits under a master services agreement, which holds the legal terms, and it follows a proposal, which sold the work. A good agency SOW has twelve sections, an acceptance criterion for every deliverable, written assumptions and exclusions, and a change-request process that prices each change in hours, money and days before anyone starts on it.

This guide gives you a section-by-section checklist, acceptance criteria you can adapt, and a change request worked through with the arithmetic. It covers structure and practice, not legal wording. It is general information, not legal advice: have a lawyer review your contract terms.

What an SOW is, and what it isn't

Agencies use four documents that are easy to mix up. Each answers a different question.

The split keeps the legal terms stable: with liability, intellectual property and payment terms in the MSA, each SOW stays short, and nobody reopens the liability clause to add a landing page. Without an MSA, the SOW has to carry those terms too, which is one more reason to have a lawyer draft or review it. Ask them to set which document wins if two disagree.

The twelve sections, with a worked example

The examples follow one fictional project: a website rebuild for a group of 12 physiotherapy clinics, with eight page templates, an online booking widget and a fixed fee. All amounts are in one currency; the method works in any.

Before you send it

• Every deliverable has at least one acceptance criterion that someone who wasn't in the meetings could check.
• Every assumption that affects the price or a date is written down, with what happens if it's wrong.
• The out-of-scope list covers the things this client is most likely to assume are included.
• Every client input has a date and a named person.
• Revision rounds are counted, and "a round" is defined.
• You know the estimated hours behind the price, by role, even if the client doesn't see them.
• No payment depends only on a client approval that could stall. If one does, add a fallback date.
• It names the MSA it sits under, and who can approve a change on the client's side.
• A colleague who wasn't in the sales conversation can read it and tell you what's in and what's out.

Our free SOW outline and change request template is built on these sections and the change-request form below.

Writing acceptance criteria

An acceptance criterion is a condition a deliverable must meet before the client accepts it. Good ones turn "Is it done?" from an opinion into a check, and separate a defect from a change: if the work fails a written criterion, fixing it is on you; if it meets every criterion and the client wants something else, that's a change request.

• Make it testable: someone who wasn't in the meetings could check it and reach the same answer.
• Say how and where it's checked: which devices and browsers, which data, which environment.
• Use numbers where they exist: sizes, counts, times, formats.
• Only promise what you control. "Ranks first for 'physio near me'" depends on search engines and competitors. "Each of the 12 clinic pages has its own title and description" doesn't.
• For creative work, cap it rather than test it. Taste can't be measured, so the number of concepts and revision rounds becomes the criterion.
• Set the review window and what ends it. Some agencies add deemed acceptance: if the client neither accepts nor lists failures within the window, the deliverable counts as accepted. How that is worded is a question for your lawyer.

Assumptions and exclusions

They do different jobs. An exclusion says something is not part of the work. An assumption is something you believe is true and priced on; if it's false, the price or the date changes. Both feed change control: a request for an excluded item, or a wrong assumption, triggers a change request.

Assumptions, each tied to a consequence

Exclusions: write down what the client will assume

Name the things a reasonable client might expect. For the website rebuild:

• Copywriting and editing: the agency loads the copy the client supplies.
• Translation and a second language.
• Photography and stock image licences.
• Hosting, domain and third-party subscription fees.
• Support after a 30-day warranty period. Offer it as a retainer instead.
• Changes to third-party systems, such as the booking provider's.

The change-request process

A change request is a short written record of a change: what was asked for, what it does to the hours, price and dates, and who approved it. The rule that makes it work: no work on a change until it's approved in writing.

What triggers one

• The client asks for something excluded, or not listed as a deliverable.
• An assumption turns out to be wrong.
• The client wants another revision round.
• A client input is late enough to move a milestone.

Fixing a deliverable that fails its acceptance criteria is not a change request. Neither is fixing your own mistakes.

The form

1. Reference number, date raised, and who asked.
2. What's asked for, in the client's words, and why.
3. What it affects in the SOW: deliverables, assumptions, milestones.
4. The estimate: hours by role and task, rates, and contingency.
5. The price, and when it's billed.
6. The effect on dates: which milestones move, and by how much.
7. Options: do it now, do it later, or swap it for something of similar size.
8. The date the quote expires.
9. Approval: the decision-maker's name and the date, in writing.

The steps

1. Log it the day it's raised, however small.
2. Estimate it within two working days, with the same task breakdown you used for the original estimate.
3. Send it with options. Don't start the work.
4. Get written approval from the person the SOW names.
5. Update the plan, the budget and the log, and tell the team.
6. Bill it as the SOW says.

Small changes are where scope creeps in unnoticed. One way to handle them: changes under 2 hours each go on the log and are absorbed, up to 8 hours in total; after that, they're grouped into a change request. Show the client the log at every check-in.

Worked example: adding a second language

On Wednesday 20 January 2027, during the website rebuild, the client asks for the home page, the 12 clinic pages and the booking page (14 pages) in Simplified Chinese as well as English, for patients at two clinics. Translation and a second language are excluded in the SOW, so this is a change request. The client will supply the translated copy.

Step 1: estimate the hours and the price

With CR-01 already approved (see the log below), the fee stands at $67,200 + $1,440 = $68,640 for 420 + 9 = 429 hours. CR-03 takes it to $68,640 + $8,970 = $77,610 and 429 + 57.5 = 486.5 hours. Doing it for free would mean 57.5 ÷ 429 = 13.4% more work for the same fee.

Step 2: work out the effect on dates

Find the person the change waits on. Here it is the developer, who has 32 hours a week for this project and no spare time before launch. Their 28 hours plus 15% contingency is 28 × 1.15 = 32.2 hours, so 32.2 ÷ 32 = 1.0 week. The design, testing and project management hours fit around it in the existing plan. The launch moves one week, from Tuesday 2 March to Tuesday 9 March 2027, provided the translated copy arrives by Monday 15 February 2027. If the copy is later, the launch moves day for day.

If you're not sure how much of someone's week is really free, start with available hours: our capacity planning guide works them out from contracted hours, leave and public holidays.

Step 3: send it with options

• Option A, add it now: $8,970, and the launch moves to Tuesday 9 March 2027.
• Option B, add it after launch: launch in English on Tuesday 2 March as planned, and add Chinese under a separate SOW once the team is free.
• Option C, swap scope: drop something of similar size, such as two of the eight templates, to keep the fee and the date. Estimate the swap before agreeing to it: two templates won't necessarily add up to 57.5 hours.

Billing: 50% on approval ($4,485) and 50% with the launch payment ($4,485). The quote is valid until Wednesday 27 January 2027, because the developer's time can't be held open for longer.

Step 4: record it in the log

CR-01 is priced at the blended $160 an hour (9 × $160 = $1,440) and CR-02 at the designer's $150 (5 × $150 = $750). Once the change is approved, track the new budget the same way as the original. Our free project budget tracker shows hours used, monthly burn and the forecast at completion.

Estimating, and checking estimates against actuals

An SOW price is only as good as the estimate behind it. Build it the same way each time:

1. Break each deliverable into tasks.
2. Estimate hours for each task, by role.
3. Add a contingency set from your past projects, not a round number you picked.
4. Price the hours at your rates. If you're not sure what those should be, our agency rate calculator works out the hourly and day rate your salaries, on-costs and overheads need.
5. Decide which hours count against the budget, such as meetings and account management. Our billable vs non-billable time guide has a decision table for the grey areas.
6. After delivery, compare estimated and actual hours by task and by role. The gaps show which kinds of work you underestimate, and what your next contingency should be.

Where scope creep comes from, and the section that stops it

How retainers differ

A retainer pays for continuing capacity or a monthly set of outputs, not one finished thing. Its SOW, often called a retainer agreement or schedule, describes the arrangement rather than a list of deliverables.

Two habits carry over. Quote big new pieces of work as their own project SOW, or they eat the hours meant for support. And keep the change log: on a retainer it shows the client where the hours went. Our retainers guide covers pricing, rollover and the burn report.

Have it reviewed

This guide is about structure and practice. It is general information, not legal advice: have a lawyer review your contract terms, including the MSA your SOWs sit under, before you use them.

If you or your clients are in Australia, a few points from the Australian Competition and Consumer Commission (ACCC) are worth knowing before that conversation:

• The law protects consumers and small businesses from unfair terms in standard form contracts. Since 9 November 2023, proposing, using or relying on an unfair term in a standard form contract is banned, and penalties apply [1].
• For standard form contracts made, renewed or varied from that date, a small business is covered if it has fewer than 100 employees or less than $10 million in annual turnover. The ACCC suggests businesses using standard form contracts find out whether their customers fall under these thresholds, and says that, if in doubt, it may be safest to assume they do [1].
• A contract is presumed to be a standard form contract, and the party that prepared it must prove it isn't [1]. That matters if you send every client the same template.
• The ACCC's examples of terms that may be unfair include terms that let one party, but not the other, change the terms of the contract [1]. Ask your lawyer how your change-control and price-review wording reads against that.

The UK and the US have their own rules. If you or your client are outside Australia, ask a lawyer where you are.