Website Redesign Scope of Work Template

Outcome Summary

• Define what’s included in the redesign (and what isn’t) before work starts.
• Reduce surprise requirements by documenting assumptions, dependencies, and who provides what.
• Create a clear approval + change-request path so feedback doesn’t turn into endless rework.
• Use a visual redesign demo early to align stakeholders on direction before finalizing deliverables.

What Revamp Actually Does (Truth Block)

✅ Revamp does

• Generate an AI website redesign demo from a website URL.
• Provide a shareable live preview link you can send to stakeholders for review.
• Let you add design preferences to steer the output (style direction, colors, layout cues, inspiration links).
• Offer code export on paid plans for teams who want a faster handoff into implementation.

❌ Revamp does not

• Guarantee SEO, performance, conversion, or revenue outcomes.
• Replace discovery, requirements gathering, or contractual scoping for client projects.
• Reliably capture complex web-app functionality or specialized interactive components from every source site.
• Remove the need for customization and refinement after the initial redesign is generated.

(If you want to use Revamp as part of your scoping workflow, start in the app: Revamp app.)

The Core Problem

Website redesign scope creep usually happens because the “work” is described as a vibe, not a set of deliverables.

Common pain points teams run into:

• Stakeholders assume additional pages, components, or iterations are included by default.
• Hidden requirements show up late (integrations, forms, compliance copy, accessibility expectations).
• Content isn’t ready, so design gets blocked—or the design gets blamed for content gaps.
• Ownership is unclear (who writes copy, who supplies images, who configures analytics, who QA’s).
• Feedback is unstructured, contradictory, or arrives from too many reviewers.

Framework

Use this workflow to create a scope of work (SOW) that’s specific enough to protect both sides, without over-promising.

• Align on outcomes (not features)

  • Write a short “what success looks like” statement.
  • Keep it observable (clarity, consistency, responsiveness, easier updates), not guaranteed metrics.

• Inventory what exists

  • Capture current page types, key navigation paths, and any “must keep” elements.
  • Note constraints (CMS, brand rules, required legal pages, approval stakeholders).

• Define deliverables in plain language

  • List what the client receives (design direction, redesigned page types, components, content migrations, implementation support).
  • For each deliverable, specify the format (demo link, design file, code repository, CMS configuration notes).

• Write “included” and “not included” lists

  • “Included” should describe the work you will do.
  • “Not included” should call out the usual scope-creep items (new features, custom integrations, deep copywriting, photography, complex animations) unless explicitly added.

• Assign responsibilities

  • Clarify who supplies copy, images, brand assets, logins, domain/DNS access, and stakeholder approvals.
  • Document who is responsible for content accuracy and legal review.

• Define your review workflow

  • Specify how feedback is collected (single consolidated doc, comments in a tool, or annotated screenshots).
  • Name who has final approval authority.

• Add a change-request policy

  • State how changes are requested, how they’re evaluated, and what happens when a request exceeds scope.
  • Make it explicit that new deliverables require a written scope update.

• Use a visual checkpoint before implementation

  • Generate a redesign demo in Revamp and share the live preview link for early alignment.
  • Capture what “approved direction” means (layout direction, typography vibe, component style, content density).
  • Link the approved demo inside the SOW as a reference artifact.

• Define acceptance criteria + handoff

  • Acceptance criteria should be testable (responsive behavior, working nav, form submissions routed, required pages present, no placeholder content unless agreed).
  • Define what happens after acceptance (launch support window, post-launch fixes, training, documentation).

Copy/paste: Scope of Work template (fill-in)

You can paste this into your doc tool and adapt.

Project overview

• Client: [Client name]
• Project: Website redesign for [Site / product]
• Goal: [Short goal statement]

Scope (what’s included)

• Design direction artifact: [Revamp redesign demo link] or [Design file link]
• Pages / page types included: [List]
• Components included: [Header, footer, hero, pricing section, testimonials, FAQ, forms…]
• Content handling: [Client provides final copy] / [We migrate provided copy] / [Copy refresh notes]
• Implementation: [Who builds] + [Where it’s built] + [Environments]

Out of scope (not included unless added in writing)

• New product features or custom app functionality
• Custom integrations beyond listed requirements
• Custom illustration/photography beyond provided assets
• Deep SEO remediation beyond on-page basics (unless specified)
• Accessibility compliance level guarantees (unless explicitly scoped)

Assumptions & dependencies

• Client provides: [Brand assets, access, approvals, legal copy]
• Required systems: [CMS, hosting, analytics, email/forms provider]
• Blockers: [Anything that could delay review or implementation]

Roles & responsibilities

• Client owner: [Name + role]
• Agency/contractor owner: [Name + role]
• Approval authority: [Name]
• Feedback method: [Single consolidated document / tool]

Review & approvals

• Review checkpoints: [Define checkpoints]
• What counts as approval: [Definition]

Change requests

• How to request: [Method]
• What happens if out of scope: [Written scope update + reprioritization]

Acceptance & handoff

• Acceptance criteria: [List testable checks]
• Handoff package: [Links to repo/design/demo/CMS notes]
• Post-acceptance support: [What’s included vs separate]

Use Cases

Agency pitching a redesign (pre-sale)

• Scenario: A prospect wants a concrete vision before signing, but keeps asking for “a modern refresh” without specifics.
• Recommended approach: Generate a Revamp redesign demo from the prospect’s current site, share the live preview link, and use the approved direction to write deliverables that match what they reacted to (page types, components, content responsibilities). Then attach the demo link inside the SOW as the visual reference.
• Common mistake: Treating the demo as the final spec—then discovering late that key functional requirements weren’t captured.

In-house marketing hiring a contractor

• Scenario: Marketing owns the site, but product, legal, and sales all have opinions—and the contractor keeps getting conflicting feedback.
• Recommended approach: Put a named approval authority in the SOW, define how feedback is consolidated, and use a single redesign demo link as the “source of truth” for look-and-feel decisions.
• Common mistake: Skipping responsibility mapping—then the redesign stalls because nobody owns copy, assets, or approvals.

Founder-led site rebuild while shipping product

• Scenario: The founder wants a new marketing site but can’t babysit a long process.
• Recommended approach: Keep the SOW lean: define page types, component set, and a clear “content readiness” dependency. Use Revamp to generate a starting direction and lock it early so implementation doesn’t churn.
• Common mistake: Leaving “content TBD” everywhere—then the project becomes endless placeholder iteration.

Decision Checklist

• Can you name an approval authority (the person who can say “ship it”)?
• Do you have a page/type inventory (not just a wishlist of sections)?
• Is content ownership explicit (copy, images, legal text, product claims)?
• Are integrations and forms explicitly listed (where submissions go, what tools are involved)?
• Is the review workflow defined (how feedback is collected and consolidated)?
• Is there a documented change-request path for new requirements?
• Is your acceptance criteria testable (not “looks good”)?
• Do you have a visual reference artifact linked in the SOW (demo link, design file, or both)?

Constraints

• Source-site constraints: If the current site blocks crawling or has unusual structure, AI-based previews (and even manual audits) can miss details.
• Complex functionality: Interactive apps, gated flows, and custom components often require separate functional requirements beyond design scope.
• Content readiness: Redesign quality is limited by the clarity and completeness of copy and assets you can ship.
• Tooling access: CMS, hosting, analytics, forms, and DNS access should be confirmed before implementation begins.
• Stakeholder throughput: Too many reviewers without consolidation slows approvals and increases contradiction risk.

Common Mistakes

• Using a moodboard as a scope: It creates subjective expectations and leads to disputes over what was “promised.”
• Not listing “out of scope” items: Hidden requirements appear late and force rework or uncomfortable renegotiation.
• Unclear content responsibilities: Design gets blocked waiting for copy/assets, or the team ships with placeholders.
• No change-request mechanism: Every new request becomes “just a small tweak,” which quietly expands deliverables.
• No acceptance criteria: Launch readiness becomes a debate instead of a checklist, delaying ship decisions.

FAQ

What’s the difference between a proposal and a scope of work? A proposal explains the approach and why it’s a good fit; the SOW is the operational contract-like document that defines deliverables, responsibilities, and how changes are handled.

Should my SOW list pages or page types? If your site is small and stable, list pages. If the structure may evolve, list page types (and what content each type includes) so you can accommodate changes without silently expanding scope.

How do I prevent “surprise pages” and hidden requirements? Add an explicit inventory step, write an “out of scope” list, and include a change-request policy that requires a written scope update for new deliverables.

Can I use a Revamp demo link inside my SOW? Yes—treat it as a reference artifact for direction (layout style, component vibe), and pair it with explicit functional requirements and responsibilities.

What should be considered out of scope by default? Anything that changes functionality or adds new systems (custom integrations, new app features), plus specialized work like deep copywriting, custom illustration, or compliance guarantees—unless you explicitly include it.

What if the client asks for changes after approval? Point to the change-request section: evaluate whether the request is a refinement of an existing deliverable or a new deliverable, then document the scope update before proceeding.