# How to Write a Statement of Work for Shopify Projects

> How to write a statement of work for Shopify projects: the sections that prevent disputes, a statement of work example for agencies, and common mistakes.

_Published: 2026-10-28 · CommerceCopilot_

## The document that decides every later argument

Most Shopify project disputes are not really about the work. They are about what each side believed the work was, and by the time the disagreement surfaces, the only evidence is a proposal written to win the deal and a Slack history written to keep it moving. Learning how to write a statement of work is learning to settle those arguments months before they happen, in a document both sides read and signed when nobody was upset yet.

A statement of work (SOW) is the baseline that every later conversation sorts against: whether a request is new scope or a clarification, whether a deliverable is done or still owed, whether an invoice matches what was agreed. Agencies that skip it, or scatter the equivalent detail across a proposal PDF and an email thread, are not saving time. They are deferring the cost of ambiguity to the worst possible moment, usually week six, usually with money on the table.

## What a statement of work is, and what it is not

Formally, a [statement of work](https://en.wikipedia.org/wiki/Statement_of_work) is a narrative description of a project's work requirements: what will be delivered, by when, under what standards, and for what price. For agency work it usually sits alongside, not instead of, two other documents, and confusing the three is where a lot of SOW advice goes wrong.

- **The proposal** is a sales document. It argues why your agency should win the work. It is persuasive by design, and persuasive documents make bad baselines.
- **The master services agreement (MSA)** covers the relationship: payment terms, intellectual property, confidentiality, liability, termination. It is written once per client and carries across projects.
- **The statement of work** covers one project: the deliverables, the timeline, the acceptance process, the price, and the exclusions. A repeat client might sign one MSA and five SOWs.

For a first engagement without an MSA, the SOW carries more weight and often absorbs some contractual terms. That is workable, but the core of the document stays the same: it describes the work specifically enough that a disagreement can be resolved by reading it.

One boundary matters before any of the sections below: an SOW is written from a settled scope, it does not create one. If discovery has not resolved the platform, the pages and flows in scope, the integrations, and the client's definition of done, you are not ready to write this document, no matter how much the client wants a signature. The same information gap that makes [a quote unreliable](/blog/shopify-project-scoping) makes an SOW unenforceable in practice, because every vague line becomes a line the client reads in their favor.

## How to write a statement of work, section by section

The sections below are the ones that earn their place on agency-sized Shopify projects. Each exists because its absence causes a specific, predictable dispute.

### Project overview and objectives

Two or three sentences on what the project is and why the client is doing it: the business goal, not the feature list. This section does quiet work later. When a mid-project judgment call comes up, "which option serves the stated objective" is a better tiebreaker than whoever argues loudest.

### Deliverables, named one by one

The core of the document, and the place where specificity pays. "Redesign the product page" is a proposal line. An SOW line is "a redesigned product page template covering the default product layout, a variant with a size guide drawer, and mobile breakpoints, delivered as sections in the client's existing Online Store 2.0 theme." List each deliverable so that a stranger could check whether it exists. If a deliverable has pieces, name the pieces.

### Exclusions: what is explicitly out

The section most agencies skip and the one that prevents the most disputes. Anything a client could plausibly assume is included, and is not, belongs here: content entry, product data migration, copywriting, app subscription costs, post-launch support beyond a named window, changes to checkout. Exclusions feel awkward to write, but they read as professionalism, and every line is one future "we assumed that was included" conversation that never happens.

### Assumptions and dependencies

Every scope rests on assumptions, and the honest move is to name them: the client's theme is Online Store 2.0, the ERP integration has a documented API, the client provides final copy by a named date. Writing an assumption down converts it from a hidden risk into a flagged one. If it fails, the SOW already says what happens: the affected work is re-estimated rather than silently absorbed. This is the same confirmed-versus-assumed discipline that makes [scoping estimates hold](/blog/shopify-project-scoping), carried into the contract.

### Timeline and milestones

Dates for the milestones that matter: kickoff, staging review, content freeze, launch window. Tie client-side obligations to the same timeline, because a Shopify build waits on the client more often than clients expect: approvals, copy, product data, app account access. A timeline that only binds the agency is a timeline the agency will miss for reasons it does not control.

### Acceptance criteria and review process

Define what "done" means and who says so: what gets reviewed (a staging link, a walkthrough call), who on the client side approves it, and how long they have before approval is assumed. Without a named approver and a review window, projects end in a loop where "the team is still looking at it" delays the final invoice indefinitely. The same thinking that makes [acceptance criteria work on tickets](/blog/writing-acceptance-criteria-shopify-tickets) works at the deliverable level: observable outcomes, not vibes.

### Pricing, payment schedule, and model

The price, when it is invoiced, and what pricing model governs it. The model belongs in the SOW because it changes what the rest of the document means: on [fixed price, the deliverables list is a hard boundary; on time and materials](/blog/fixed-price-vs-time-and-materials-shopify), it is a plan with a budget ceiling and a reporting cadence. Either way, the drivers behind the number are the same ones that determine [what a Shopify build costs](/blog/how-much-does-a-shopify-build-cost), and the SOW is where that number gets attached to a scope specific enough to defend it.

### Change process

Scope will move, and the SOW should say what happens when it does: how a new request gets captured, who prices it, who on the client side can approve the spend, and how approved changes move the budget and timeline. Pre-wiring this at signature is the difference between change control reading as professionalism and reading as defensiveness, and the [change request process](/blog/how-to-handle-change-requests-shopify-projects) only works if the baseline it sorts against, this document, is specific.

## A statement of work example for an agency project

Here is what the skeleton looks like for a typical mid-size Shopify engagement, a product page redesign with a review app integration:

- **Overview:** Redesign the product page template to improve mobile conversion ahead of the Q2 campaign.
- **Deliverables:** Product page template (default layout, size-guide variant, mobile breakpoints); integration of the client's existing review app into the new template; QA pass across the client's five best-selling products.
- **Exclusions:** Checkout changes; copywriting; changes to collection or cart pages; migration to a new review app; app subscription fees.
- **Assumptions:** Theme is Online Store 2.0; the review app exposes its widget as a documented section block; client provides final imagery by March 6.
- **Timeline:** Kickoff March 2, staging review March 20, client approval window of five business days, launch targeted March 31.
- **Acceptance:** Client's ecommerce manager (named) reviews the staging link against the deliverables list; items pass when each listed outcome is observable on staging.
- **Pricing:** Fixed price, invoiced 50 percent at kickoff and 50 percent at launch; change requests priced separately under the process below.
- **Changes:** New requests are captured in writing, priced within two business days, and proceed only on written approval from the named approver.

Thin as it is, this skeleton already answers the questions that end projects badly: what exactly is being built, what is not, who approves it, and what happens when someone asks for more.

## Where SOWs go wrong

**Written from the proposal instead of from discovery.** The proposal was scoped to win; the SOW must be scoped to deliver. Copying proposal language into a contract carries every sales-stage ambiguity into the baseline.

**Deliverables described as outcomes.** "Improve site speed" cannot be accepted or rejected, only argued about. Every deliverable should be checkable by looking at the store.

**No exclusions section.** If the document only says what is in, everything else is a negotiation.

**No named approver.** "The client approves" is not a process. A person, a window, and a default if the window lapses is a process.

**Signed, then ignored.** An SOW only works if the team sorts incoming requests against it. If the baseline lives in a drawer, the real baseline is whatever was last said in Slack.

## Writing the SOW from what discovery actually found

Everything above assumes you have the raw material: a settled list of what is confirmed, what is assumed, and what the client actually said yes to. On most projects that material is scattered across discovery calls, Slack threads, and email by the time someone sits down to write the document, and the SOW inherits whatever was misremembered.

CommerceCopilot's Business Analyst agent is built to keep that material in one place as it accumulates. It runs discovery continuously across connected calls, Slack channels, and documents, maintains a living record of confirmed versus assumed scope, and flags gaps while they are still cheap to resolve. When it is time to write the statement of work, the deliverables, assumptions, and exclusions are already separated and sourced instead of reconstructed from memory. The [discovery project guide](/docs/your-first-discovery-project) shows how that record gets built before anything is quoted or signed.

## FAQ

### Is a statement of work legally binding?

When signed by both parties it generally functions as a contract or as part of one, especially when it sits under an MSA that supplies the legal framework. Treat the wording accordingly: anything vague will be read against you. For specific legal questions, ask a lawyer, not a blog post.

### How long should a statement of work be?

As long as the deliverables list requires and no longer. For a typical agency-sized Shopify project, two to five pages covers every section above. Length is not the goal; checkability is. A one-page SOW with named deliverables and exclusions beats a ten-page one padded with boilerplate.

### What is the difference between a statement of work and a scope of work?

In agency practice the terms overlap heavily. The scope of work is the description of the work itself, deliverables and boundaries, and it usually lives as the central section of the statement of work, which adds timeline, pricing, acceptance, and change terms around it.

---
Canonical page: https://www.commercecopilot.ai/blog/how-to-write-a-statement-of-work-shopify-projects