How to write a Shopify scope of work (without rebuilding it)
A good Shopify scope isn’t “more detail.”
It’s clarity on:
- what you’re delivering
- what you’re not delivering
- who owns what
- what “done” means
- what triggers a change request
Most agencies lose time because they treat scoping like writing.
But Shopify scoping is closer to assembly.
The structure is repeatable; the inputs change.
If you capture the right inputs up front, you can assemble a consistent scope in Google Docs quickly—and make it delegable.
Try rules-based scope assembly → https://ruledox.app/live-demo
Step 0: Decide what kind of Shopify project this is
Before you write anything, label the engagement. The deliverables and exclusions are different.
Common Shopify scope types:
- Store build (new storefront)
- Redesign/theme customization (existing store, new UI)
- Migration (platform change + redirects + cutover risk)
- Retainer/ongoing management (continuous work with SLAs)
If you don’t pick a type, you’ll accidentally mix them.
Step 1: Start with a repeatable structure (table of contents)
Your table of contents should be stable across projects.
A simple, effective Shopify scope structure:
- Overview
- Deliverables (in-scope)
- Out of scope (exclusions)
- Assumptions
- Timeline & milestones
- Roles & responsibilities
- QA & acceptance criteria
- Launch plan (if applicable)
- Change request rules
When the structure is stable, you’re not “writing a scope.”
You’re filling in known sections.
Step 2: Capture scope variables (inputs) before you write
These inputs determine 90% of the scope.
If you don’t make them explicit, they’ll show up later as “surprises.”
Shopify scope variables checklist (high leverage)
- Project type (build/redesign/migration)
- Theme approach (off-the-shelf vs custom)
- Template count (how many unique templates/components)
- Catalog size + variant complexity
- Markets (currency/language)
- Integrations (ERP/WMS/3PL, subscriptions, reviews, loyalty)
- B2B/wholesale requirements
- POS requirements
- Content responsibilities (who migrates/creates content)
- Acceptance standard (what must be tested and signed off)
If you want a deeper variable list: https://ruledox.app/content/shopify/scope-variables-checklist
Step 3: Write exclusions like you mean it
Most scope creep is not malicious.
It’s caused by implied exclusions.
If the scope doesn’t explicitly exclude something, many clients will assume it’s included.
How to write exclusions that prevent disputes
- Put exclusions in their own section (not a footnote)
- Use specific nouns (“Custom app development” not “Custom work”)
- Include “not included unless explicitly listed” language
Example exclusions (adjust to your offer):
- copywriting and photography
- SEO strategy and link building
- custom app development
- complex integrations not named in scope
- unlimited design revisions
- tax/legal compliance advice
Step 4: Define responsibilities (client vs agency)
A Shopify project can’t move without:
- access (Shopify admin, domain/DNS, app accounts)
- approvals
- content and product data
If responsibilities aren’t explicit, the agency becomes the default owner.
Common client responsibilities:
- provide product data, imagery, brand assets
- provide domain/DNS access
- pay third-party app fees
- approve deliverables on schedule
Step 5: Define acceptance criteria (what does “done” mean?)
A scope without acceptance criteria never ends.
At minimum, define:
- what templates/pages must be reviewed
- what browsers/devices you test
- what flows must work (add to cart, checkout, refunds if relevant)
- how many feedback rounds are included
Acceptance criteria doesn’t need to be long.
It needs to be testable.
Step 6: Define change request rules (the protection layer)
Change requests are not a negotiation tactic.
They’re a governance mechanism.
Common change triggers:
- new integrations/apps added after sign-off
- new templates/components
- increases in catalog/variant complexity beyond agreed limits
- major design direction change after approval
- additional markets/languages
Write them plainly, then follow them.
Step 7: Stop writing from scratch—assemble from inputs
If your scopes are repeatable, the smart move is to codify the repeatability.
This is the core of a strong agency scoping process:
- intake captures the variables
- variables drive which sections appear
- hours/pricing logic (if used) references those variables
- doc is assembled in Google Docs
When you do this, you can delegate scoping safely because the logic is in the system, not in one person’s head.
It also becomes much easier to standardize proposals (i.e., how to standardize proposals across salespeople), because your proposal always wraps a consistent scope structure.
That is what RuleDox is built for.
Try the live demo → https://ruledox.app/live-demo
FAQ
Should a Shopify scope include pricing and hours?
Only if you want the scope itself to be the reference document for pricing logic. If pricing is separate, still make sure the scope deliverables match what was sold.
How long should a Shopify scope be?
As long as it takes to remove ambiguity. A 2-page scope can be excellent if it clearly defines deliverables, exclusions, responsibilities, and acceptance.
What’s the biggest scoping mistake?
Implied exclusions. If it’s not written, it’s assumed.