What to Include in a Statement of Work (SOW) Checklist

What a statement of work is (and why beginners need it)

A Statement of Work (SOW) is the document (often part of your proposal or contract) that clearly explains what you’ll do, what you’ll deliver, when it will happen, and what happens if something changes.

If you’re new to freelancing, the SOW matters because it turns “we’ll figure it out later” into clear expectations. That helps you and the client avoid:

• scope creep (extra work that wasn’t agreed to)
• disagreements about quality
• delays caused by missing client reviews
• late payments or payment disputes (if the work wasn’t defined well)

Think of the SOW as your “single source of truth” for the project.

SOW essentials vs optional sections (the checklist)

Use this checklist to decide what’s essential (recommended for most freelance projects) vs optional (useful when they add clarity).

Essentials (recommended for most SOWs)

These sections reduce disputes fast:

1. Project overview & objectives
2. Deliverables & acceptance criteria
3. Scope boundaries (what’s explicitly out of scope)
4. Timeline & milestones
5. Roles & responsibilities
6. Client inputs & dependencies
7. Change management (revisions vs changes)
8. Communication cadence
9. Assumptions & risks
10. Quality standards

Optional (use when they add clarity)

These can help for larger projects or teams:

• Payment terms (only insofar as they connect to the work)
• Tooling, access, and files
• Reporting and documentation

Essential sections (include these to reduce disputes)

Below are the sections you should include in your SOW, plus what “good” looks like.

1) Project overview & objectives

Write a short summary of:

• what the project is
• the main goal (what success looks like)
• the target audience or outcome (as relevant)

Mini-example (simple):

• Objective: Deliver a logo and brand kit that the client can use across web and print.

2) Deliverables & acceptance criteria

This is the heart of the SOW.

For each deliverable, include:

• format (e.g., PNG/SVG, Figma file, DOCX)
• size/version (e.g., 3 logo variations)
• due date or milestone
• acceptance criteria (how the client will approve it)

Good acceptance criteria are not just “looks good.” They describe what must be true.

Mini-examples of acceptance language:

• “Client approves when colors match the provided hex codes and files pass export checks.”
• “Client accepts when the landing page loads correctly in Chrome/Firefox and all form fields submit successfully.”

3) Scope boundaries (what’s explicitly out of scope)

List what you’re not doing. This prevents “I thought you included that.”

Include things like:

• extra pages/features not listed in deliverables
• copywriting vs editing boundaries
• additional rounds beyond the agreed revision policy
• research, strategy, or compliance work (if not in deliverables)

Tip: Write a short “Out of Scope” section for readability.

4) Timeline & milestones

A timeline should connect to the work and client feedback.

Include:

• start date or “upon contract signature”
• milestone dates
• review windows for client approvals
• buffer time for revisions (based on your change policy)

Avoid “we’ll start soon and finish later.” Instead, use milestone checkpoints:

• Milestone 1: Draft delivered
• Milestone 2: Revisions delivered
• Milestone 3: Final files delivered

5) Roles & responsibilities

Clarify who does what.

At minimum:

• What you do (your responsibilities)
• What the client does (their responsibilities)
• Any third parties (if relevant)

Examples of responsibility items:

• Client provides brand guidelines and assets
• Freelancer conducts design drafts and produces final deliverables

6) Client inputs & dependencies

This is where many projects break down. List what you need from the client and when.

Common dependencies:

• access to tools (Figma, CMS, Google Analytics)
• written content and images
• login credentials (or a safe way to grant access)
• approvals from stakeholders

If the client can’t provide something on time, state what happens (e.g., timeline shifts).

7) Change management (revisions vs changes)

This section protects your time.

Define:

• Revisions: adjustments included in the price (often a limited number of rounds)
• Changes: new scope beyond what’s agreed (priced separately)

Include details such as:

• how many revision rounds are included per deliverable
• what counts as a revision vs a change
• how requests are submitted (e.g., a single email thread with bullet points)
• how approval delays affect deadlines

Plain-language example:

• “Two revision rounds are included for each major deliverable. Any additional rounds or new features require a change request and updated timeline.”

8) Communication cadence

Define how often you’ll communicate and what channels you’ll use.

Include:

• meeting frequency (if any)
• async updates (weekly email or project comments)
• response time expectations (e.g., “client responds within 2 business days”)
• where feedback is collected

Even a simple cadence helps:

• “Weekly status update every Friday.”
• “Feedback collected through the shared doc within 3 business days of delivery.”

9) Assumptions & risks

List assumptions you’re making so problems aren’t a surprise.

Examples:

• Client will provide final copy by a certain date
• The freelancer won’t do legal/compliance review
• The project depends on client stakeholder approval

Risks can be simple and practical:

• “If client feedback is delayed beyond the review window, milestones move accordingly.”

10) Quality standards

This sets the bar and gives you a fair way to say “that’s not what we agreed to.”

Include standards such as:

• design guidelines (brand alignment, readability)
• technical checks (responsive layout, browser support)
• writing standards (tone, grammar level, formatting)
• marketing standards (tracking setup, deliverable requirements)

Avoid vague standards like “high quality.” Use measurable checks when possible.

Optional sections (use when they add clarity)

Not every SOW needs these, but they can prevent confusion.

Payment terms (only insofar as they connect to the work)

You usually handle full payment terms in the main contract. Still, your SOW should reflect payment tied to milestones.

Common approach:

• deposit to start
• payments after drafts or after acceptance

Example:

• “50% upon kickoff; 50% upon delivery of final approved files.”

If the SOW includes payment language, keep it linked to deliverables and approvals.

Tooling, access, and files

If your work depends on specific tools or assets, define it.

Include:

• which software you’ll use (and what file types you’ll deliver)
• client access needs (accounts, hosting, admin permissions)
• how you’ll share files (shared drive, Figma, GitHub)
• where the “source of truth” lives

Reporting and documentation

If reporting is part of the job, say what you’ll report and how often.

Examples:

• “Monthly performance report with KPIs and brief recommendations.”
• “A handoff document listing installed plugins, settings, and next steps.”

A sample SOW structure you can copy (outline, not a full template)

Here’s a practical outline you can follow when writing your SOW. Don’t worry about perfect wording—just keep the structure.

1. Project overview & objectives
2. Deliverables (with due dates)
3. Acceptance criteria (for each deliverable)
4. In scope / Out of scope
5. Timeline & milestones (with review windows)
6. Roles & responsibilities
7. Client inputs & dependencies
8. Change management (revisions vs changes)
9. Communication cadence
10. Assumptions & risks
11. Quality standards
12. Optional: payment tied to milestones
13. Optional: tooling/access/files
14. Optional: reporting/documentation

Not sure where your freelance business stands? The Freelance Business Check is a quick way to spot weak spots before they turn into late nights or lost income.

Mini-examples: how deliverables & acceptance criteria differ by freelancer type

Here are quick examples that show how the deliverables and acceptance criteria change depending on your work.

1) Design SOW example (logo + brand kit)

Deliverables (in scope):

• Logo concept directions (2–3 options)
• Final logo package with required formats (SVG, PNG)
• Basic brand kit: color palette, typography pairings, spacing guidance

Acceptance criteria:

• Client approves when the final logo exports correctly in the specified formats
• Brand kit colors match provided hex codes and typography matches selected fonts
• Files are delivered in an organized folder with usage notes

Out of scope (example):

• full website design
• unrelated brand strategy workshops
• packaging design or mockups beyond the agreed set

2) Development SOW example (landing page build)

Deliverables (in scope):

• Responsive landing page implementation
• Integration of provided copy/images
• Basic SEO settings and tracking setup (only if agreed)

Acceptance criteria:

• Page loads and renders correctly on mobile and desktop
• Forms submit successfully (and lead data is visible where agreed)
• Client approves after testing in agreed browsers/devices

Out of scope (example):

• additional pages beyond the landing page
• full analytics audit
• server maintenance or security patching after launch

3) Writing SOW example (blog series / web pages)

Deliverables (in scope):

• Blog post drafts (e.g., 4 posts)
• Optional: SEO-friendly outline per post
• Final revisions after feedback

Acceptance criteria:

• Client approves when the draft meets the required word count range, formatting rules, and tone guidance
• Grammar and formatting are correct per the agreed style guide
• Required sections (e.g., headings, CTA, FAQ) are included

Out of scope (example):

• rewriting client’s entire site taxonomy
• sourcing external quotes or legal claims beyond what the client provides

4) Marketing SOW example (email campaign + reporting)

Deliverables (in scope):

• Email copywriting (or editing, if copy is provided)
• Design/templating in the agreed tool
• Launch scheduling support (if agreed)
• Performance report after send

Acceptance criteria:

• Client approves when emails pass template checks (links work, images load)
• Timing matches agreed schedule
• Report includes the agreed KPIs and basic insights

Out of scope (example):

• ongoing optimization for additional months
• ad spend management
• building new automation flows not listed in deliverables

Related reading: What to Include in a Freelance Contract (Checklist) · Proposal Software for Freelancers: How to Choose

Common SOW mistakes beginners make (and how to fix them)

Mistake 1: Writing deliverables as vague tasks

Fix: List what you will deliver, in what format, and by when.

• Instead of “work on logo,” write “deliver 3 logo concept options and final logo package (SVG/PNG).”

Mistake 2: No acceptance criteria (or only subjective criteria)

Fix: Use clear, testable checks.

• Instead of “client approves when they like it,” use “approves when files match provided specs and exports correctly.”

Mistake 3: Forgetting to define out-of-scope

Fix: Add an Out of Scope section.

• “Not included: website design, packaging, or additional mockups beyond the agreed set.”

Mistake 4: Treating revisions and changes as the same thing

Fix: Separate them.

• Revisions = included adjustments.
• Changes = new scope that needs a change request.

Mistake 5: Timeline not tied to client review and dependencies

Fix: Include review windows and what happens if the client delays.

• “Client will review within 3 business days; otherwise milestone dates shift.”

Mistake 6: Communication rules are missing

Fix: Define cadence and where feedback goes.

• “Weekly update every Friday; feedback via shared doc; response within 2 business days.”

Mistake 7: Payment terms live in the contract but aren’t mirrored in the SOW

Fix: Tie payment to milestones or acceptance.

• Even a short “payment tied to deliverables” line helps.## Quick self-check: before you sign, verify nothing critical is missing Use this checklist to confirm your SOW is complete:
• Project overview & objectives: Can someone understand the goal in 1–2 minutes?
• Deliverables: Are all deliverables listed clearly with formats and due dates?
• Acceptance criteria: Could you and the client test “done” without arguing?
• Out of scope: Is there a clear list of what you won’t do?
• Timeline & milestones: Do milestones include review windows?
• Roles & responsibilities: Who does what?
• Client inputs & dependencies: What do you need, and when?
• Change management: Are revisions included and changes handled with a process?
• Communication cadence: How often will updates happen, and where does feedback go?
• Assumptions & risks: What could impact the schedule or outcome?
• Quality standards: Are there clear expectations for quality?
• Payment connection: Is payment tied to milestones/acceptance (even if detailed terms are elsewhere)?

Closing thought: start with a clear SOW, then scale your freelance process

A strong SOW doesn’t just protect you—it helps the client move faster too. When your expectations are clear from day one, you spend less time debating and more time delivering.