Website Redesign Statement of Work Template

Outcome Summary

• Use this Statement of Work (SOW) template to define redesign scope, deliverables, acceptance, responsibilities, and change control—before design work starts.
• Reduce “that wasn’t included” surprises by explicitly documenting what’s in scope, what’s out, and how changes are handled.
• If you’re using Revamp, you can attach a redesign demo link as a visual reference for expectations without turning the SOW into a design comp.

What Revamp Actually Does (Truth Block)

✅ does

• Generates an AI website redesign demo from a pasted website URL.
• Produces a shareable live preview link you can send to clients/stakeholders.
• Lets you capture optional design preferences to steer the redesign direction.
• Offers code export on paid plans.

❌ does not

• Guarantee performance, SEO, or conversion outcomes from a redesign.
• Replace discovery, technical auditing, or contractual scoping for complex builds.
• Ensure the output matches specialized app functionality without additional engineering.

The Core Problem

• Redesign projects fail on expectations: “redesign” means different things to different people.
• Deliverables are often implied (design files, CMS setup, copy updates, QA, launch) instead of written.
• Approval and acceptance are vague, which creates endless review cycles.
• Change requests arrive midstream without a process, timeline impact, or budget impact.
• Stakeholders assume integrations, migration, accessibility, or SEO are included “by default.”

Framework

• Align on the purpose (not just the pages).

  • Write the business goal in plain language (who the site is for, what it should help them do).
  • If you have a Revamp demo, link it as a reference for direction.

• Define scope with a hard “in / out.”

  • List what you will produce.
  • List what you explicitly will not produce.

• Write deliverables as artifacts, not activities.

  • “New homepage layout in CMS” is a deliverable.
  • “Work on homepage” is not.

• Make acceptance criteria testable.

  • Use checks someone can verify without reading your mind.
  • Tie acceptance to environments (staging, production) and required client inputs.

• Assign responsibilities by owner.

  • Who provides copy, brand assets, access, approvals, and legal requirements.
  • Who configures hosting, domains, analytics, and email.

• Specify review workflow and feedback format.

  • Where feedback lives (doc, issue tracker, annotated screenshots).
  • What counts as “approved.”

• Plan for technical realities.

  • Content migration, redirects, tracking, forms, third-party scripts, and CMS constraints.
  • Clarify what happens if the current site is blocked, unstable, or heavily custom.

• Lock change control and sign-off.

  • Define how changes are requested, estimated, approved, and scheduled.
  • Define what triggers a new SOW or addendum.

Copy/paste SOW template (website redesign)

# Website Redesign Statement of Work (SOW)

## Parties
Client: [CLIENT LEGAL NAME]
Provider: [PROVIDER LEGAL NAME]
Project Name: [PROJECT NAME]
Effective Date: [EFFECTIVE DATE]

## Background & Goals
- Current website: [CURRENT SITE URL]
- Goals:
  - [GOAL]
  - [GOAL]
- Success indicators (non-guaranteed):
  - [INDICATOR]
  - [INDICATOR]

## Scope
### In scope
- [DELIVERABLE]
- [DELIVERABLE]
- [DELIVERABLE]

### Out of scope
- [EXPLICITLY OUT]
- [EXPLICITLY OUT]
- [EXPLICITLY OUT]

## Deliverables
- Design direction reference (optional): [REVAMP DEMO LINK OR OTHER REFERENCE]
- Page templates:
  - [TEMPLATE]
  - [TEMPLATE]
- Components:
  - [COMPONENT]
  - [COMPONENT]
- CMS implementation (if applicable): [CMS + WHAT IS INCLUDED]
- Content handling: [WHO WRITES / WHO MIGRATES / WHAT FORMAT]

## Milestones & Review
- Kickoff
- Discovery inputs received
- Design direction approved
- Build implementation complete (staging)
- Pre-launch QA complete
- Launch

## Acceptance Criteria
Work is considered accepted when:
- Deliverables listed above are provided.
- Client provides required inputs and approvals.
- Site renders correctly on modern browsers and common device sizes.
- Forms and primary site flows defined in scope function as described.
- Any agreed tracking/analytics events in scope are implemented.

## Client Responsibilities
Client will provide:
- Brand assets (logo files, fonts if licensed, color guidance)
- Copy and legal text (or approve provided drafts)
- Access (CMS, hosting, domain, analytics, tag manager, form tools)
- Timely feedback and a single decision owner

## Provider Responsibilities
Provider will:
- Deliver items defined in scope
- Communicate risks, dependencies, and open questions
- Maintain a changelog of accepted changes

## Assumptions & Dependencies
- Source site content is accessible for reference.
- Third-party tools behave according to their vendors’ limits.
- Delays caused by missing client inputs may shift schedule.

## Change Control
- All scope changes must be submitted in writing.
- Provider will respond with impact to schedule and fees.
- Work begins on the change only after written approval.

## Fees & Payment Terms
- Project fee: [FEE OR PRICING MODEL]
- Payment schedule: [SCHEDULE]
- Expenses (if any): [EXPENSE POLICY]

## Intellectual Property
- Ownership of final deliverables: [TERMS]
- Licensing for fonts, photos, plugins: [TERMS]

## Confidentiality & Data
- Confidential information handling: [TERMS]
- Access credentials: [HOW SHARED / STORED]

## Termination
- Termination terms and work-in-progress handling: [TERMS]

## Sign-off
Client: ______________________  Date: __________
Provider: _____________________ Date: __________

Use Cases

Agency selling a redesign to a client with unclear expectations

• Scenario: The client wants a “modern refresh,” but stakeholders disagree on what that means.
• Recommended approach: Attach a Revamp redesign demo link as a visual north star, and keep the SOW focused on deliverables, acceptance criteria, and change control.
• Common mistake: Treating the demo as a promise of exact final UI, instead of a direction reference that still needs refinement.

In-house marketing team coordinating with engineering

• Scenario: Marketing owns the site, engineering owns deployment and integrations.
• Recommended approach: Put responsibility lines in the SOW for environments, deployment, access, and third-party scripts—so “who does what” is explicit.
• Common mistake: Leaving launch and tracking as implied tasks, then discovering late that nobody owns them.

Freelancer redesigning a site where content is still in flux

• Scenario: The client expects the freelancer to “fix the copy” but hasn’t provided messaging.
• Recommended approach: Define a content responsibility clause: client-provided copy vs copy support vs placeholder content, plus what happens when copy changes late.
• Common mistake: Starting build work without locking content inputs, leading to repeated rework.

Decision Checklist

• Do the deliverables describe artifacts you can hand over (not vague activities)?
• Is there a clear “in scope” list and an explicit “out of scope” list?
• Are acceptance criteria testable (someone can verify them without interpretation)?
• Are responsibilities assigned for copy, assets, access, approvals, and deployment?
• Is the review workflow defined (where feedback lives and what “approved” means)?
• Are integrations, tracking, forms, and redirects explicitly addressed (included or excluded)?
• Is there a written change control process that covers impact and approval?

Practical Example (Illustrative)

Situation: A client asks, “Can you also rebuild our careers page and add an events calendar?”

A clean SOW-driven response (copy/paste-ready):

• “The careers page and events calendar are not included in the current scope. I can add them via a change request.”
• “To estimate accurately, I need: the careers content source (ATS or static), the events tool/vendor (or desired behavior), and any required tracking.”
• “Once confirmed, I’ll send an addendum describing deliverables, acceptance criteria, and the schedule/fee impact for approval before work begins.”

Why this works: It protects the original scope, keeps the relationship collaborative, and makes the new work estimable.

FAQ

What’s the difference between a proposal and a statement of work? A proposal sells the approach and the why; a SOW is the operational contract-like document that defines what will be delivered, how it will be accepted, and how changes are handled.

Should I attach design comps to the SOW? Usually, it’s better to reference design direction (moodboards, a Revamp demo link, or a style guide) and keep the SOW focused on deliverables and acceptance criteria.

How do I define “done” for a redesign? Write acceptance criteria that can be checked: required pages/templates exist, key flows work, responsibilities are fulfilled, and launch prerequisites are met.

What should I do about SEO and redirects? Decide if redirects, metadata, analytics, and sitemap changes are in scope. If they are, define exactly what’s included; if not, explicitly exclude them so there’s no assumption.

How do I handle client delays? Add an assumptions/dependencies section stating that missing inputs or late approvals may shift the schedule, and clarify how rescheduling is handled.

Can Revamp replace discovery and scoping? No. Revamp can help you communicate design direction quickly via a demo link, but you still need a SOW to define deliverables, responsibilities, and change control.