2026-02-26·7 min read·By Luis Salcedo

Web design scope of work template

A web design project can look defined while still hiding major risk. Website redesign is not scope. A usable scope of work names exactly what will be designed, what inputs are required, what is excluded, and what happens when requests change after approval.

Web design scope of work with in-scope deliverables, out-of-scope exclusions, and required fixed-price inputs

Why this happens

Web design scope drift usually starts with vague nouns: homepage refresh, modern look, improve UX. Without explicit boundaries, every stakeholder interprets those phrases differently. The project appears aligned until review cycles reveal hidden assumptions.

Agency operations data repeatedly shows budget overrun and overservicing patterns linked to unclear scope controls (Teamwork.com State of Agency Operations 2023). Professional agreement frameworks emphasize explicit services, additional services, and authorization logic for the same reason (AIGA Standard Form of Agreement for Design Services).

The scope template below is designed for digital agency web work, not construction or enterprise PM. It focuses on design deliverables, revision logic, and client dependency clarity.

47%

of agency net revenue comes from project and fixed-fee work — making scope discipline a direct revenue protection issue.

Source: SoDA & Productive — Global Agency Landscape Study (2022) →

Template structure

# Web Design Scope of Work

Project:
Client:
Agency:
Version:
Date:

## 1) Objectives
[What outcome this web design project should achieve]

## 2) In-scope deliverables
- Page list and page templates
- Responsive states required
- Component/system deliverables
- Design handoff format

## 3) Out-of-scope items
- Development not included (if applicable)
- Copywriting not included (if applicable)
- Stock imagery licensing not included
- SEO implementation not included

## 4) Client inputs and dependencies
- Content owner and content due date
- Brand assets owner and due date
- Approver names and review cadence

## 5) Timeline and milestones
- Kickoff
- Wireframe review
- Visual design review round 1
- Visual design review round 2
- Final approval

## 6) Revision policy
- Included revision rounds:
- What counts as a revision:
- Additional revision pricing:

## 7) Change request process
- How requests are submitted
- How impact is estimated
- Approval requirement before work starts

## 8) Acceptance and sign-off
Client approver:
Agency approver:
Date:
CategoryIn scope exampleOut of scope example
Page design8 named page designsNew landing pages added mid-project
Visual assetsUse client-supplied brand assetsNet-new illustration production
Revision roundsTwo rounds per milestoneDirection reset after approval
Technical workDesign handoff specsCustom frontend implementation

Common mistakes

  • Deliverables listed by phase, not output. Design phase is not auditable scope.
  • No content dependency clause. Missing content dates are a common launch delay driver.
  • No named approver. Role-only approvals often create extra revision cycles.
  • No out-of-scope section. This is where most mid-project disputes begin.
  • No versioning. Scope updates without version control weaken enforceability.

Contract resources for independent creative work consistently stress explicit service descriptions, ownership boundaries, and change authorization, which map directly to web design scoping discipline (RGD Independent Contractor Agreement Resources).

How Clariva fits

Clariva helps teams tighten pre-scope inputs before writing the document: missing budget logic, unclear stakeholder chains, and vague deliverables are flagged before commitment. You can then draft this scope from stronger inputs and reduce downstream change pressure.

Pair this template with the website change request templateand the out-of-scope response scriptfor mid-project control.

Analyze your briefStart from scratch

Example scope excerpt for a website redesign

Use this as a quality benchmark for how specific web design scope language should be. Replace details for your project type, but keep the structure and precision level.

In scope:
- Homepage, About, Services, Contact, and 4 campaign landing page designs.
- Desktop and mobile layouts for each page template.
- Design system tokens for color, type, spacing, and button states.
- Up to 2 revision rounds per milestone with consolidated client feedback.

Out of scope:
- Net-new page templates not listed above.
- Copywriting and translation.
- Frontend development implementation.
- New illustration production beyond provided assets.

Dependencies:
- Client delivers finalized copy by [date].
- Client confirms final approver and review windows before kickoff.
- Delays in dependencies shift timeline accordingly.

Notice that this excerpt is deliverable-first, not process-first. It tells a delivery team exactly what to produce and what not to produce. That is what makes scope enforceable during live review calls.

Pre-pricing intake gate for fixed-fee web design

Before issuing fixed-price scope, collect these inputs. Missing any one of them raises probability of later rework or commercial friction.

  1. Final page list: no placeholder categories, only named pages/templates.
  2. Content owner and due date: avoid open-ended content assumptions.
  3. Approver list: include final decision-maker by name.
  4. Platform and technical constraints: include CMS limitations and integration requirements.
  5. Revision expectation: align on rounds and consolidated feedback process.

Teams often treat these as admin details and proceed anyway. In fixed-fee work, that is usually where margin leakage enters. Your scope template is only as reliable as the intake discipline behind it.

Implementation checklist for project leads

  • Store one approved scope version and include version number in all client-facing references.
  • Use the same terms across proposal, scope doc, and kickoff notes to reduce interpretation drift.
  • When requests arrive, classify immediately as revision or change and document rationale.
  • Keep exclusions visible in kickoff decks so boundaries are discussed before pressure points.
  • Run a weekly scope check against current tasks to detect hidden additions early.

Teams that follow this checklist usually reduce reactive scope conversations and keep client decisions faster because tradeoffs are consistently documented.

What strong scope language looks like in client reviews

When presenting this scope to clients, read key boundaries out loud: included deliverables, explicit exclusions, dependency dates, and revision limits. Many disputes happen because teams send scope documents by email but do not walk through them in a live review. A five-minute boundary review often prevents weeks of downstream debate.

Use plain language during review. Replace broad terms with concrete statements such as 8 page templates, two revision rounds per milestone, and copy provided by client by [date]. Specific language makes later classification easy when new requests appear. Ambiguous language makes every request look debatable.

If you detect uncertainty during the review, pause and resolve it before sign-off. Scope ambiguity never gets cheaper after kickoff. It only moves from planning to delivery, where the cost is higher and timelines are tighter.

Document decisions in writing the same day for clean project records, faster follow-through, and fewer disputes about what was agreed in review meetings.

Build a stronger scope before writing the document. See which inputs are missing from your client brief.

Analyze your brief

Frequently asked questions

What should a web design scope of work include?

Include named deliverables, exclusions, assumptions, milestones, responsibilities, revision limits, and change request rules with approvals.

Why are exclusions so important in scope documents?

Exclusions define boundaries. Without them, clients often assume additional pages, assets, or features are included.

Should CMS setup and integrations be in scope by default?

Only if explicitly listed. Technical setup should be stated as included or excluded to avoid ambiguity.

When should a scope of work be updated?

When approved changes alter deliverables, timeline, or assumptions. Keep version history clear and signed.

Related resources

Website change request templateHow to tell a client something is out of scopeHow to charge for revisionsHow to write a project brief that prevents scope creep