Statement of Work (SOW) Template

When to use this

• You are starting a project and need scope clarity.
• You want a change request process that is not awkward.

A Statement of Work (SOW) is the project-level document that turns a handshake into something you can run: what you are delivering, what you are not delivering, how long it takes, how reviews work, and how you handle changes.

The template on this tool page is intentionally short. The goal is not to write a novel. The goal is to remove ambiguity in the few places ambiguity reliably becomes expensive: scope boundaries, acceptance, review cycles, change requests, and payment timing.

Disclaimer: This is a drafting guide, not legal advice. If you want contract-level clause ideas that usually sit next to an SOW, start with Freelance contracts: the clauses that matter.

Quick-fill method (15 to 30 minutes)

When you are in a hurry, fill the SOW in this order. You will produce a usable version fast, then iterate on the high-risk parts.

1. Write the outcome in one sentence (Section 1). If you cannot explain what changes for the client, you are not ready to scope it.
2. List deliverables with a definition of done (Section 2). Keep each deliverable concrete: a thing you can point to and say "that is it."
3. List exclusions (Section 3). If you are thinking "of course that is not included," write it anyway. That is the point of an out-of-scope list.
4. Set the timeline and the review timeboxes (Section 4). Put dates on kickoff and milestones. Put a timebox on reviews so the calendar stays real.
5. Assign client responsibilities (Section 5). Include access and inputs, a review deadline, and a single decision-maker.
6. Draft measurable acceptance criteria (Section 6). Keep it short, testable, and tied to the deliverables.
7. Define the change request trigger (Section 7). Make it explicit that requests outside scope are handled through a change process, not informal "quick favors."
8. Align fees and billing to the timeline (Section 8). Choose a schedule you can actually run: deposit, milestones, or time based invoicing. Add the due date and the work-pause rule you intend to follow.
9. Keep IP and confidentiality high-level (Section 9). If your contract already covers this in detail, keep the SOW aligned and non-contradictory.
10. Fill termination and signatures (Section 10). Termination is about handling "we are stopping" in a clean, documented way. Then put names and dates on it.

If you only have 10 minutes, do Sections 1 through 3 and a rough Section 4. That gives you a clear boundary and a calendar. Then add acceptance, change requests, and payment before you start real work.

What to tighten first (highest leverage edits)

Most SOWs fail in predictable places. Tighten these first, in this order:

1. Definitions of done (Section 2). Replace vague verbs like "help" or "support" with outputs and boundaries.
2. Out-of-scope list (Section 3). Add the items that are likely to be assumed, requested, or discovered late.
3. Acceptance criteria (Section 6). Make it measurable enough to avoid debates, but not so brittle it becomes a trap.
4. Review windows and approval path (Sections 4 and 5). Decide who approves and how long they have. Without this, "almost done" can last weeks.
5. Change request process (Section 7). Make it normal to estimate impact in writing and to wait for approval before starting.
6. Billing schedule and work pause behavior (Section 8). If your process is "I will deal with it later," you will deal with it later, under stress.

A useful mental model: tighten the parts that affect calendar, cashflow, and expectations first. You can polish wording later.

Section-by-section walkthrough

Header (Client, Provider, effective date)

Use legal names if you have them, and put the effective date in YYYY-MM-DD format. If the client has procurement, this often needs to match their vendor paperwork, so confirm the contracting entity early.

1) Summary

The summary is where you earn clarity. Keep it tight and readable:

• Outcome: describe what changes for the client, not what you will do all day.
• Primary deliverables: list the few big outputs. The detailed list comes in Scope.
• Point of contact: name one person who owns approvals and coordination.

If the summary reads like a weekly status report, rewrite it. The summary should make a stranger understand what you are building and why it matters.

2) Scope (what is included)

Scope is where most projects win or lose. Write scope as a list of deliverables with a definition of done for each. "Definition of done" can include acceptance checks, formats, and constraints.

A strong deliverable line usually answers three questions:

• What is the thing being delivered?
• What does "done" mean for this thing?
• What are the key boundaries (platforms, channels, environments)?

Avoid listing internal activities unless the client is explicitly buying time. Clients pay for outcomes and outputs. Your scope should reflect that.

3) Out of scope (explicitly excluded)

Out of scope is not negativity. It is how you keep expectations aligned when people skim. Add exclusions that are easy to assume and hard to do quickly.

Two practical patterns:

• Exclude adjacent work: things that sound close to the deliverables but are a separate project.
• Exclude open-ended support: ongoing maintenance, unlimited revisions, or "as needed" work unless you are pricing for it.

Your out-of-scope list should make change requests easier, not more confrontational. It gives you a shared reference point.

4) Timeline

The timeline section is not only dates. It is a dependency map. A typical structure is:

• Kickoff date
• First draft or a milestone date
• Review windows (for example, a fixed number of business days per review)
• Target completion date

If dates are uncertain, keep the milestones but tie them to inputs. For example: "Milestone happens after access is provided and requirements are confirmed." The more your timeline depends on client inputs, the more explicit Section 5 needs to be.

5) Client responsibilities

This section prevents the most common delay pattern: you are waiting, but the plan does not say what you are waiting for. Keep the list short and concrete:

• Provide access and inputs by a specific date.
• Review and approve within a timebox.
• Assign a single decision-maker.

If you want a deeper system for onboarding and predictable delivery, read Onboarding, delivery, retention. It pairs well with an SOW because it turns responsibilities and review windows into a repeatable workflow.

6) Acceptance criteria

Acceptance criteria is where "done" becomes a shared standard. Keep it measurable and tied to deliverables. You are aiming for criteria that reduces debate, not criteria that forces perfection.

7) Change requests (when reality changes)

Scope changes. The mistake is handling scope changes informally. The template uses three simple rules:

• Any request outside Scope is a change request.
• You estimate the time and cost impact in writing (so everyone sees the tradeoff).
• Work starts after written approval.

8) Fees and payment terms

This section keeps cashflow aligned with delivery. The template calls out four details:

• Fee amount and currency
• Billing schedule (deposit, milestones, or net terms)
• Due date (for example, Net 7)
• Work pause behavior for overdue invoices

The key is consistency. Only include a work-pause rule you are willing to follow, and make sure your milestone dates and review windows reflect the reality that unpaid work may pause.

9) IP and confidentiality (high-level)

Keep this section aligned with your main agreement. The template stays high level: what the client receives, what you retain (pre-existing materials, templates, general know-how), and a reasonable confidentiality obligation. If you need more detailed language, handle it in the contract and keep the SOW consistent.

10) Termination

Termination language is about a clean stop. The template keeps it simple: either party may terminate with notice, and the client pays for work completed to date. If your main agreement has more detail, align this section with it.

Signatures

Signatures turn the SOW into something you can point to later. Keep names, titles, and dates legible. If the client uses a specific signing process, follow it and keep a copy with the final version you executed.

Acceptance criteria that do not backfire

Acceptance criteria is easy to get wrong in two opposite directions:

• Too vague: "Looks good" becomes the standard, which changes depending on who is reviewing.
• Too brittle: criteria turns into a long checklist of edge cases that are hard to verify and easy to debate.

Use this structure for each deliverable:

1. Objective check: something you can test or verify.
2. Format check: where it lives and in what form the client receives it.
3. Scope boundary: what is explicitly not included for acceptance.

Illustrative examples (adjust to your project): "Delivered in a shared folder and accessible to the point of contact," "Meets the agreed requirements list," "Includes one revision cycle after the first draft," or "Runs in the agreed environment without errors that block normal use."

If a client asks for acceptance criteria you cannot control (for example, third-party approvals), move it into a responsibility or a dependency instead of promising it as acceptance.

Review cycles and approval windows

A review cycle is a bounded loop: you deliver a milestone, the client reviews within the timebox, you respond, and the client approves or escalates the decision. The SOW template supports this in two places:

• Timeline review windows (Section 4): the number of business days per review.
• Client responsibilities (Section 5): a single decision-maker and an approval deadline.

Use review windows to prevent two common failure modes: feedback that arrives too late (and shifts the timeline), and feedback that arrives in fragments (and creates rework).

A simple review rule that works in most projects: one consolidated feedback doc per review window, owned by the decision-maker. If multiple stakeholders comment, the client consolidates and prioritizes. Your job is to respond to the consolidated set, not to chase individual threads.

Change requests (a calm process for scope drift)

The fastest way to create resentment is to treat scope drift as a moral problem. Treat it as a process problem instead. A change request process does three things:

• It names what changed.
• It shows the impact (time, cost, timeline).
• It creates a clear approval moment before you start.

When a new request shows up, ask for three inputs (in writing): what the client wants, why it matters, and when they need it. Then respond with options: add it (with an estimate), swap it (trade one deliverable for another), or park it (later phase).

If you want the change request paperwork ready-made, the Change Request Addendum Pack is designed to match the SOW rule: estimate first, then start after approval.

Payment and work-pause alignment

Payment terms only work when they match how you actually deliver. The SOW template includes a due date and a work-pause rule. Think of that as an operational decision, not a paragraph you hope you never use.

Three alignment rules keep this simple:

1. Invoice on the same cadence you deliver value. If you deliver in milestones, bill by milestones. If you deliver continuously over time, bill on a regular schedule.
2. Put review windows on the calendar before you invoice. If the client review determines whether you can move forward, the review timebox is part of the delivery system.
3. If work pauses, the timeline shifts. The point is not punishment. The point is to avoid silently financing the project.

For a deeper system that reduces late payment risk, read Getting paid on time. If you want a ready-to-send invoice and follow-up scripts, use Invoice Template + Late Payment Sequence.

Practical tip: include the client email for billing and accounts payable, not only the project point of contact. Many late payments are process failures, not intent.

FAQ

Is an SOW the same as a contract?

An SOW is often one part of an agreement. It is the project plan: deliverables, timeline, acceptance, and change handling. Many freelancers pair an SOW with a separate contract that covers broader terms.

How detailed should my scope be?

Detailed enough that someone can tell what you will deliver and what you will not deliver. If your scope can be interpreted in multiple ways, it is too vague. If your scope lists dozens of micro-tasks that are really internal workflow, it is probably too detailed. Aim for deliverables, definitions of done, and boundaries.

What if I cannot define acceptance up front?

You can still define acceptance for the parts you control: what you will deliver, where it will be delivered, and what "complete" means for that deliverable. If the project depends on unknowns, write them as assumptions or dependencies and build review windows into the timeline. The goal is not perfect prediction. The goal is predictable decisions.

What if the client misses review deadlines?

That is exactly why review windows belong in the SOW. If a deadline is missed, do not silently compress the schedule. Reconfirm the new dates in writing and keep the timeline consistent with reality.

How do I say "that is a change request" without drama?

Use the SOW as the neutral reference point. Point to the Scope and Out of scope sections, then offer the process: "I can add that. I will send an estimate and updated timeline for approval." When you have the paperwork ready, it feels routine.

What billing schedule should I choose?

Choose a schedule you can execute consistently. Deposits reduce risk at kickoff. Milestone billing ties payment to tangible progress. Regular invoicing works well for time-based engagements. Whatever you pick, keep it aligned with your timeline and review windows, and make sure the due date is unambiguous.

Should I include a work-pause rule?

Include it if you plan to use it. A work-pause rule is an operational boundary: if invoices are overdue, work may pause until the account is current. If you include a rule like this, align it with your invoicing process and your follow-up cadence.

What is the minimum viable SOW?

Minimum viable means: outcome, scope with definitions of done, explicit exclusions, timeline with review windows, acceptance criteria, change request process, and payment timing. If those are clear, the project has a spine. You can always add detail later, but you cannot recover time lost to ambiguity.

How to customize

1. Replace deliverables with the exact outputs you will ship.
2. Add assumptions and exclusions based on what clients usually misunderstand.
3. Define acceptance criteria and review cycles.

Related Codex pages