Scope of Work for a Website Redesign

The scope of work for a website redesign is the document that determines whether a project succeeds or spirals into disputes.

It defines what the agency will deliver, what the client must provide, and what happens when either party fails to meet their obligations.

Most project problems are scope problems in disguise. Missed deadlines, unexpected costs, and disagreements all trace back to a scope document that was vague, incomplete, or never agreed before work began.

Key Takeaways

• The SOW is the binding deliverables document: It defines what will be built, who is responsible for what, and the standards each deliverable must meet.
• Exclusions protect both parties: A SOW that lists only inclusions is incomplete; explicit exclusions prevent "I assumed that was included" disputes.
• Client responsibilities must be documented: Content delivery, asset provision, feedback timelines, and approval authority are client deliverables and belong in the scope.
• SOW and proposal are different documents: A proposal describes what could be done; a SOW is the signed commitment of what will be done.
• Changes require a formal process: Any scope addition after sign-off requires a written change order with documented cost and timeline impact.

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

Let's talk

Scoping Before Writing the SOW

How to scope the project first is the process that produces the raw material the SOW formalizes. A SOW written before scoping is complete is based on assumptions rather than agreed requirements.

The scoping process is not the same as writing the SOW. It is the research and alignment work that happens before anyone writes anything.

The SOW captures the output of that process in a form both parties can sign.

Discovery Produces the SOW's Raw Material

Requirements, page inventory, technical constraints, and integration lists produced during discovery are the inputs to the scope document.

• Requirements workshops: Structured sessions that identify every functional requirement, content type, and technical integration the new site must support.
• Page inventory: A documented count of current pages, proposed new pages, and any pages to be consolidated or removed.
• Technical constraints: Platform requirements, existing system integrations, and hosting infrastructure that affect what can be built and how.

Scope Must Be Agreed Before the SOW Is Written

Both client and agency must agree on what is included before the SOW documents it. A SOW that one party signs without fully understanding its contents is a dispute waiting to happen.

Scoping Is an Iterative Process

Initial scope estimates are refined through requirements workshops and technical assessment. The SOW captures the final agreed scope, not the first estimate.

Treating the first estimate as the final scope is the most common cause of change order friction.

What a Website Redesign SOW Must Include

Items to include in the SOW cover every component necessary to define the project completely. A SOW that omits any of these sections is an incomplete document with gaps that will become disputes.

Review every SOW against this list before signing. Any missing section is a risk that should be resolved before work begins.

Project Description and Objectives

A brief description of the project and the specific business goals it must achieve ensures both parties understand the purpose of the work, not just the task list.

A SOW with no objectives section has no basis for evaluating whether deliverables were successful.

Deliverables by Phase

A complete, itemized list of what will be delivered in each phase.

• Discovery deliverables: Project brief, sitemap, audience profiles, and technical requirements document with sign-off requirements for each.
• Design deliverables: Design system, component library, high-fidelity mockups for each agreed template, and responsive specifications.
• Development deliverables: Built site to approved designs, configured CMS, all integrations tested, QA report, and redirect implementation.
• Launch and post-launch deliverables: Analytics verification, redirect testing, training documentation, and 30-day monitoring report.

Acceptance Criteria for Each Deliverable

"Wireframes for 6 page templates, reviewed and approved by the client after one consolidated round of feedback" is an acceptance criterion. "Wireframes done" is not.

Client Responsibilities in the SOW

The client responsibilities section is the most commonly missing or vague section in agency SOWs. It is also the section responsible for the most post-launch disputes about delays and costs.

Requirements that inform the SOW include client-side obligations that are just as binding as agency-side deliverables. Leaving client responsibilities vague shifts all project risk to the agency.

Content Delivery Timeline and Format

Specify when copy will be delivered by phase and date, in what format, and who is responsible for each content type.

• Copy delivery dates: Tied to the project timeline and phrased as prerequisites for subsequent phases, not as aspirational targets.
• Delivery format: Whether content arrives in Word, Google Docs, or direct CMS entry determines how much additional work the agency must do to make it usable.
• Responsibility assignment: Named individuals or roles, not "the client team," are accountable for each content type.

Asset Provision Requirements

List every brand asset the client must provide: logo files in vector format, brand guidelines, photography, video, and icons.

Include delivery date, format specifications, and quality requirements. Late assets shift the timeline; the SOW documents the consequence.

Feedback Turnaround Windows

Document the agreed response time for each review type: wireframe review (3 business days), design review (5 business days), staging review (3 business days).

Exceeded windows trigger a timeline extension. This must be explicit in the SOW, not assumed.

Exclusions and Out-of-Scope Items

What is not in the SOW is as commercially significant as what is. A well-written exclusions section is the most reliable protection against scope creep and the disputes that accompany it.

The scope of work and project plan are complementary documents. The SOW defines what is in and out of scope; the project plan defines how the in-scope work will be executed and scheduled.

Why Exclusions Are as Important as Inclusions

Common exclusions to document explicitly include ongoing maintenance, additional pages beyond the agreed count, new features not in the brief, third-party tool procurement, and content writing beyond the agreed scope.

How to Write Clear Exclusion Statements

Exclusions should be specific. "This SOW does not include design or development of a member portal or login functionality" is an enforceable exclusion. "Custom features not covered" is a phrase that invites interpretation and dispute.

• Feature exclusions: Name specific features that are explicitly out of scope, particularly those that might reasonably be assumed to be included.
• Page count limits: "Up to 15 page templates; additional templates billed at £X per template" defines both the inclusion and the pricing for scope additions.
• Third-party tools: "This SOW does not include procurement, licensing, or account setup for any third-party software" prevents disputes about who pays for tools.

What to Do With Items That Are Probably Out of Scope

If both parties are unsure whether something is in or out of scope, it belongs on a clarification list. Resolve ambiguous items before signing, not after.

Every ambiguity left in a SOW will be interpreted in the direction that favors the party who feels disadvantaged at the time the question arises.

SOW and Estimation

Estimating from the SOW is how a specific, detailed scope document produces an accurate cost estimate rather than an assumption-based one.

A vague SOW produces a vague estimate with contingency built in to cover the ambiguity. A specific SOW allows the agency to price against defined deliverables, which is almost always better value for both parties.

How the SOW Drives the Agency's Estimate

The agency's hours and cost estimate is calculated directly from the SOW's deliverables list.

Each deliverable, its acceptance criteria, and its review requirements translate directly into hours. A deliverable that is ambiguously defined cannot be accurately estimated.

Fixed-Price vs Time-and-Materials Pricing

A fixed-price SOW provides cost certainty but requires precise scope definition before pricing is agreed. A time-and-materials SOW provides flexibility for evolving requirements but requires the client to actively manage scope to prevent budget overrun.

What Happens When the SOW Scope Changes

Every change to the SOW requires a change order: a written document specifying the addition, the cost, the timeline impact, and the client's signature.

Verbal scope additions are not billable and are not enforceable. Documented ones are both.

From SOW to Quote

Quoting from the scope of work produces a defensible, transparent commercial proposal. A quote that arrives before the scope is defined is a price in search of a justification.

Research shows that approximately 70% of scope disputes in web projects involve items that were never explicitly listed as in-scope or out-of-scope in the original agreement.

A complete SOW eliminates the majority of that dispute surface.

The Quote Is Built From the SOW, Not the Other Way Around

A properly structured engagement produces the SOW first, then derives the quote from it. A proposal leading with price and following with scope is justifying cost rather than deriving it from the work.

Clients who receive price-first proposals have no reliable way to evaluate whether the price is accurate.

What Should Be Itemised in the Quote

The quote should reflect SOW phases: discovery, UX, design, development, QA, launch, and post-launch. Line-item pricing against deliverables produces a proposal that is both more transparent and easier to scope-change against.

Signing the SOW Before Work Begins

The SOW must be signed before any billable work is conducted. Work that starts before signing has no contractual protection for either party.

An unsigned SOW is an unenforceable agreement, regardless of how much both parties trust each other at the time the project starts.

Conclusion

A complete scope of work covers deliverables, acceptance criteria, client responsibilities, exclusions, and change management in a signed document that precedes any work.

Every section that is missing is a risk to be resolved before the project begins.

Review any redesign SOW you are currently holding against the sections covered in this article.

Gaps in exclusions, client responsibilities, or acceptance criteria are the specific risks to address before signing, not after the first disagreement.

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

Let's talk

LOW/CODE Agency Produces a Complete SOW Before Any Work Begins

Projects that start without a proper scope document rarely end well.

LOW/CODE Agency is a strategic product team, not a dev shop, and every engagement we undertake begins with a structured scoping process and a signed SOW before any billable work is conducted.

Our scoping process includes a requirements workshop, agreed deliverables list, documented client responsibilities, explicit exclusions, and a change management process that protects both parties throughout the project.

• Requirements workshop: Structured discovery session that produces the raw material for the SOW before any estimate is provided.
• Deliverables list by phase: Every output across discovery, UX, design, development, QA, launch, and post-launch itemized with acceptance criteria.
• Client responsibility documentation: Content delivery dates, asset provision requirements, and feedback turnaround windows documented in the SOW.
• Explicit exclusions section: Specific out-of-scope items named and agreed before signing, not discovered during the project.
• Fixed-price with change order process: Cost certainty against a defined scope, with a transparent process for scope additions.
• Sign-off requirements at each phase: Formal client approval of each phase's deliverables before subsequent phase work begins.
• Post-launch support scope: Defined post-launch monitoring period, support responsibilities, and transition documentation included as standard.

Our properly scoped redesign engagement process has been applied across 450+ products for clients including Coca-Cola, American Express, Sotheby's, Medtronic, Zapier, and Dataiku. Start with a scoping call