Shopify SOW vs Proposal: what to write, and where it goes

Shopify SOW vs proposal (for agencies)

Agencies use "proposal" and "scope of work" interchangeably, but they're not the same.

A proposal is the sales document: context, approach, credibility, price.
A scope/SOW is the delivery contract: deliverables, exclusions, responsibilities, acceptance.

The mistake: writing a vague proposal and hoping it behaves like a scope.

Agencies conflating proposals and scopes. If your proposal is also your scope, neither document does its job properly. The proposal under-sells because it reads like a contract, and the scope under-specifies because it reads like a pitch.
Teams where the proposal IS the scope (and it causes problems). When a single document tries to win the deal and define the delivery, ambiguity creeps in. Clients sign off on the vision without agreeing to the boundaries.

Overview + outcomes — Set the context for the project and describe the results the client can expect, without over-promising on specifics.
Approach and phases — Explain how your team works and how the project will be structured, so the client understands the process.
Case studies / proof — Include relevant examples that demonstrate your team's experience with similar Shopify projects.
Pricing options — Present pricing at a level that supports a buying decision, without locking in granular deliverables.
Timeline estimate — Give the client a realistic window for delivery, accounting for their dependencies and your capacity.

Deliverables in plain language — List exactly what will be built, configured, or delivered, written so a non-technical stakeholder can understand it.
In-scope vs out-of-scope — Draw a clear line between what is included and what is not, so there is no ambiguity after sign-off.
Assumptions + client responsibilities — State what you are assuming to be true and what the client needs to provide, so both sides know their obligations.
Acceptance criteria — Define how the client will review and approve each deliverable, including the number of revision rounds included.
Change request rules — Specify what triggers additional scope and how changes are handled once the project is underway.

Scope assembly is automated. RuleDox assembles the scope — hours, pricing logic, conditional sections — inside Google Docs from your defined rules. The structured part of the document builds itself.
Proposals stay in your hands. RuleDox does not write your sales narrative, case studies, or positioning. That is your voice and your strategy. RuleDox handles the part that should be consistent and rules-based.
Both documents improve. When the scope is assembled separately and accurately, the proposal can focus on selling without doubling as a delivery contract. Each document does what it is designed to do.

The proposal stays yours. The scope assembles itself.