SEO Scope of Work vs Proposal: What's the Difference?

See how scope assembly works in Google Docs

No sign-up required · 2 minutes · Real Google Doc

Most agencies use one document that tries to do everything: sell the work, define the boundaries, and serve as a contractual reference. It fails at all three.

The reason is that proposals, scopes of work, and statements of work are three different documents with three different jobs. Using one document for all three creates language that's too salesy for operations, too operational for sales, and too informal for disputes.

This page clarifies the distinction so you can use the right document at the right time.

Try the live demo →


Who this is for

  • SEO agency founders who currently use a single "proposal" for everything
  • Operations leads who need boundary documents that hold up during delivery
  • Sales teams who want proposals that actually close deals
  • Agencies transitioning from 1-person scoping to team-based scoping

Three documents, three jobs

Document Purpose Audience Tone
Proposal Sell the engagement Prospect / decision-maker Persuasive — "here's why you should work with us"
Scope of Work (SOW) Define boundaries Delivery team + client Precise — "here's exactly what's included and excluded"
Statement of Work Contractual reference Both sides (during disputes) Formal — "here's what was agreed and how changes are handled"

The proposal sells

It leads with the client's problem, demonstrates your understanding, presents a plan, and ends with pricing. Its job is to get the prospect to say yes. It's a persuasion document.

The scope of work defines

It lists deliverables with quantities, exclusions, assumptions, roles, and timelines. Its job is to prevent misalignment during delivery. It's a reference document — the one your team opens when someone asks "is this in scope?"

The statement of work governs

It includes everything in the SOW plus contractual terms: liability, termination, IP, payment terms, dispute resolution. Its job is to protect both sides if things go wrong. It's a governance document.


When you need one vs three

One document works when:

  • Deal size is under $3K/month
  • The client is familiar with your agency and process
  • The engagement is short (project-based, 1–3 months)
  • You're the only person scoping

Two documents (proposal + SOW) work when:

  • Deal size is $3K–$15K/month
  • Multiple team members are involved in delivery
  • The engagement is ongoing (retainer)
  • You need sales and operations to reference different documents

Three documents (proposal + SOW + statement of work) work when:

  • Deal size exceeds $15K/month
  • The client has procurement or legal review
  • The engagement involves compliance or regulatory requirements
  • Enterprise or government clients with formal contracting processes

What belongs where

Element Proposal SOW Statement of Work
Problem statement Yes No No
Diagnostic / analysis Yes No No
Recommended approach Yes Brief summary Brief summary
Detailed deliverables Summary Yes (full detail) Yes (full detail)
Exclusions Brief list Yes (comprehensive) Yes (comprehensive)
Pricing Yes Yes Yes
Timeline High-level Detailed with milestones Detailed with milestones
Roles & responsibilities Brief Yes (detailed) Yes (detailed)
Change request process No Yes Yes
Assumptions No Yes Yes
Legal terms No No Yes
Termination / cancellation Mentioned Defined Legally binding
Case studies / credentials Yes No No
Signature block Optional Yes Yes

The transition from one document to two

If you currently use a combined proposal-scope, here's a practical path to separating them:

Step 1: Split the content. Take your existing template and separate it into two sections: everything that sells (problem, diagnostic, approach, credentials) and everything that defines (deliverables, exclusions, assumptions, timeline, roles).

Step 2: The proposal references the SOW. "The detailed scope of work is provided as an appendix / separate document." The proposal covers what and why. The SOW covers what exactly and what not.

Step 3: Different people can own each. A sales lead writes (or assembles) proposals. A delivery lead writes (or assembles) scopes. The founder reviews instead of writing both.

Step 4: System-enable the SOW. Once the scope is separated, it's much easier to automate — because SOWs follow patterns (variables → deliverables → exclusions) while proposals require more customisation per prospect.


How RuleDox helps

The proposal needs to be persuasive and somewhat custom. The SOW needs to be precise and consistent. These are different problems.

RuleDox focuses on the SOW side:

  • Variables drive scope — engagement type, site size, service mix determine deliverables
  • Exclusions auto-populate — what's not selected is explicitly excluded
  • The output is a Google Doc — ready to attach to a proposal or send standalone
  • Delegation becomes possible — juniors assemble SOWs from inputs, seniors review

The proposal remains your sales document. The SOW becomes a system output.

Try the live demo →


FAQ

Can I still use one document for small deals? Yes. For deals under $3K/month with short timelines, a combined proposal-scope works fine. The separation matters most when engagement value increases, team size grows, or delivery complexity requires clear boundaries.

Who should own the SOW? Ideally, the delivery or operations team — not sales. The SOW defines what will be delivered, so the people delivering it should define it. Sales owns the proposal. Delivery owns the scope.

Should the client sign the SOW or the proposal? The SOW (or statement of work, if you use all three). The proposal is a sales document — it presents the opportunity. The SOW defines the commitment. Signature belongs on the document that defines what both sides are agreeing to.

Related links

See how scope assembly works in Google Docs
See how scope assembly works in Google Docs

No sign-up required · 2 minutes · Real Google Doc