A website scope of work records what a project includes, what will be delivered, who supplies the necessary information and how completed work will be reviewed. Before work starts, both sides can check the same document to confirm what has been agreed.
The useful detail goes beyond “build a responsive website.” Which pages are included? Who writes the copy? What must the contact form do? Who pays for connected services? What happens when someone requests another feature?
This website scope of work template helps answer those questions. Use it for a new website, a redesign or a defined improvement project. Adapt the fields to the actual work rather than treating every section as a mandatory service.
What the Scope Should Establish
A practical scope should let both sides answer five questions:
- What are we producing?
- What is outside this project?
- What information, access and decisions are required?
- How will we determine whether the agreed work is complete?
- How will changes be assessed and approved?
The University of Maryland, Baltimore’s statement-of-work template provides a useful general reference: it addresses tasks, exclusions, timing, deliverables and the process for accepting completed work. Its acceptance section also identifies who is authorized to approve deliverables.
In a website scope, identify the pages to be delivered, the functions they must perform, who supplies the content and the checks required before launch.
Keep individual page instructions in a separate website content brief. For example, the project scope might include three service pages, while each page brief specifies its audience, required facts, structure and next step.
Use the template below as a planning document. Contract provisions, ownership arrangements and other legal terms should be reviewed separately where necessary.
Copy-and-Paste Website Scope of Work Template
Replace the bracketed fields with agreed information. For an unresolved item, record the question, the person responsible for answering it and the decision deadline. Do not describe uncertain work as already included.
1. Project Record and Objective
Project name: [Name]
Business and delivery provider: [Names]
Current website, if applicable: [URL]
Project type: [New build, redesign, migration or targeted improvements]
Document version and date: [Version and date]
Business decision-maker: [Name or role]
Delivery lead: [Name or role]
Problem to address: [Specific problem supported by available evidence]
Intended audience and main tasks: [Who will use the website and what they need to accomplish]
Project objective: [What the delivered website should enable]
Constraints: [Budget boundaries, existing systems, required launch events or other limitations]
2. Included Deliverables
Complete a record for each deliverable:
- Deliverable: [What will be produced]
- Quantity or coverage: [Pages, templates, components, records or workflows included]
- Required behavior or content: [What it must contain or do]
- Delivery format or location: [Specify whether this item will be supplied as a file, repository, account or working feature, and where it can be reviewed]
- Responsible party: [Who produces it]
- Acceptance check: [How completion will be demonstrated]
- Approver: [Who reviews and accepts it]
- Dependencies: [Information or work required first]
Reference the approved page inventory, designs and technical specifications by name and version.
3. Pages, Content and Media
Page inventory: [Named pages and their purpose]
Distinct page templates: [Layouts included in the design and build]
Reusable components: [Navigation, footer, cards, forms or other shared elements]
Content responsibility: [Who writes, edits, approves and uploads each type of content]
Existing content: [What will be retained, revised, moved or removed]
Media responsibility: [Who supplies images, graphics, video and usage permissions]
Content entry: [What the provider will populate and what the business will add]
Languages: [List the languages included, who prepares each translation and who checks it before publication]
4. Functionality and Connected Services
Required workflows: [Contact requests, bookings, purchases, accounts or other agreed tasks]
Forms: [Fields, validation, destination, confirmation and failure handling]
Integrations: [Named services and the required exchange of information]
Data handling: [What information is collected, stored, transferred or deleted]
User roles: [Who can view, edit, approve or administer each relevant area]
Editing requirements: [What the business must be able to update without developer assistance]
Third-party dependencies: [Accounts, permissions, subscriptions and technical limitations]
Testing access: [Test accounts, sample records or a separate testing environment]
5. Existing-Site Changes and Migration
For a new website with nothing to transfer, omit this migration section.
Items being moved: [Pages, files, records, settings or other assets]
Source and destination: [Systems or environments]
Migration coverage: [What is included and excluded]
URL decisions: [Addresses being retained, changed or retired]
Redirect responsibility: [Who prepares, implements and checks the mapping]
Verification: [How transferred content, records and functionality will be checked]
Release coordination: [How changes made during migration will be handled]
6. Quality Requirements and Acceptance
Supported browsers and devices: [Agreed coverage and testing method]
Accessibility requirements: [Applicable standard, scope, evaluation method and reviewer]
Performance requirements: [Measures, representative pages and testing conditions]
Security responsibilities: [Controls and reviews included in the project]
Privacy inputs: [Information and decisions the business or its advisers must supply]
Acceptance environment: [Where deliverables will be reviewed]
Review period: [Agreed time for submitting feedback]
Issue handling: [How problems are recorded, prioritized, corrected and retested]
Approval record: [Name the authorized approver and specify how their decision will be recorded]
7. Responsibilities, Milestones and Revisions
Business inputs: [Content, brand materials, account access and operational information]
Input owners and deadlines: [Who supplies each item and when]
Milestones: [Deliverable, dependency, review point and expected completion]
Feedback coordinator: [Who consolidates comments]
Included revision rounds: [Number, coverage and submission method]
Approval dependencies: [Which decisions must be approved before later work begins]
Delay handling: [How missing inputs or delayed decisions affect the schedule]
Change process: [Who assesses requests and who authorizes revised work]
8. Costs, Exclusions and Assumptions
Pricing basis: [Fixed scope, time-based work or another agreed arrangement]
Included fees: [Work covered by the proposal]
Payment milestones: [Amounts and agreed triggers]
Separate costs: [Hosting, domains, subscriptions, licenses, advertising or other expenses]
Recurring expenses: [Renewal owner, billing arrangement and review responsibility]
Excluded work: [Specific services, features or assets outside the project]
Estimate assumptions: [List what must remain true for the quoted price and proposed schedule to apply, such as timely content delivery or access to an existing system]
Unresolved decisions: [Questions that must be settled before a firm commitment]
9. Release, Handover and Support
Production environment: [Where the website will operate]
Launch authority: [Who approves release]
Pre-launch checks: [Required tests and responsible parties]
Recovery arrangements: [Backup, rollback responsibilities and relevant limitations]
Accounts and administration: [What the business controls and how access is provided]
Files and documentation: [Source files, instructions and records included]
Training: [Format, audience and coverage]
Post-launch support: [Duration, included work, contact route and exclusions]
Ongoing maintenance: [Who is responsible after the project ends]
10. Approval
Approved scope version: [Version]
Approved by: [Authorized representatives]
Approval date and record: [Date and location]
Open conditions: [Anything approval depends on]
Referenced documents: [Approved designs, page inventory, specifications and relevant agreement]
Count Pages, Templates and Content Separately
A page count alone does not describe the design or development effort.
Consider an illustrative website with a homepage, an about page, a service overview, three individual service pages and a contact page. That is seven published pages. The three individual service pages might share one layout, but each still needs its own approved content.
Record three separate quantities:
- Published pages: The destinations visitors can open.
- Design templates: The distinct layouts being designed and implemented.
- Content items: The copy, images or records being prepared and entered.
This makes requests easier to assess. Adding another service page could involve an existing template and new copy. Adding a searchable service directory could require different functionality, administration and testing.
For a website with many products, locations or articles, attach an inventory rather than listing every item repeatedly in the scope. State whether the provider will migrate all approved entries, a specified subset or only sample entries used to establish the publishing process.
Write Requirements That Can Be Checked
Words such as “modern,” “fast” and “easy to manage” express preferences, but they leave the acceptance decision open.
Replace them with the behavior or evidence the project needs.
| Broad request | More specific scope wording |
|---|---|
| Make the website editable | Authorized editors can update service descriptions, images and navigation through the agreed administration interface |
| Add a contact form | The form validates the agreed fields, sends the inquiry to the specified destination and displays an appropriate confirmation or error |
| Make the design responsive | The agreed templates and customer tasks will be tested across the recorded viewport sizes and browser coverage |
| Improve performance | The named pages will be measured under agreed conditions, with targets and third-party limitations recorded before implementation |
| Connect the booking platform | The selected service passes the agreed booking information through the documented integration and handles the specified failure conditions |
These are example formulations, not requirements that apply to every project. Add the details needed for the particular website.
NASA’s requirement-writing checklist emphasizes clear, consistent requirements and asks whether they can be verified through testing, demonstration, inspection or analysis. That general principle is useful when turning a website preference into something a team can evaluate.
For accessibility, identify the evaluation coverage and method. An undefined promise of an “accessible website” does not tell either party which requirements will be assessed.
For performance, agree on the pages, tools, environment and conditions. A measurement taken on one page under one set of conditions should not become an unsupported promise about every visitor’s experience.
Example: Specify a Contact Form Deliverable
The following is an illustrative scope item, not a reported client project.
Deliverable: General business inquiry form on the contact page.
Included fields: Name, email address and message.
Required behavior: Missing required information and invalid email formats receive explanatory messages. A valid submission produces a confirmation and reaches the agreed business inbox.
Administration: The business supplies the receiving address and approves the notification content. The provider configures the agreed delivery method.
Acceptance: The reviewer submits an identified test inquiry, checks the visitor-facing result and confirms receipt at the destination.
Excluded functionality: File uploads, customer accounts, payment processing and customer-management integration.
Dependency: Access to the selected sending service and any required account configuration.
Failure check: Agree how a sending failure will be identified and how the inquiry should be handled.
The example separates the visible form from delivery, responsibility and testing. It also makes clear that a later request for customer-management integration needs assessment rather than being assumed part of the original form.
Resolve Unknowns Before Treating an Estimate as Final
Some projects need investigation before the delivery team can define the build accurately.
An existing website may have undocumented integrations. A requested feature may depend on another provider’s account permissions. Content may need specialist approval before it can be published.
Record these uncertainties instead of hiding them inside a broad promise.
Where necessary, define an initial discovery phase with its own deliverables, such as:
- A review of the current system.
- A page and content inventory.
- A description of required workflows.
- Integration feasibility findings.
- Unresolved decisions and their owners.
- A proposed implementation scope.
Explain which later costs and dates remain provisional. Completing discovery does not need to imply that the business has already approved every possible implementation option.
Distinguish Revisions, Defects and New Requests
Agree how these terms will be used within the project.
A revision could be an adjustment to a submitted design or draft within the approved brief. A defect is a failure to meet an agreed requirement. A new request introduces work that the approved scope does not cover.
For example, correcting a form that sends inquiries to the wrong agreed address is different from adding a second inquiry route with new fields and routing rules.
Define what counts as a revision round. One workable arrangement is a consolidated set of comments from the authorized reviewer at a named milestone. The project should also explain how conflicting feedback, later changes to approved work and correction of defects will be handled.
Do not assume every comment is additional paid work. Assess it against the actual requirement and the agreed commercial terms.
Record Changes Before Additional Work Begins
A change request should give both sides enough information to make a decision.
Record:
- The requested change and its purpose.
- The approved deliverables it affects.
- Additional work, dependencies and testing.
- The effect on price, schedule or other commitments.
- The person authorized to approve it.
- The decision and revised document version.
The outcome may be to approve the change, defer it, replace another item or decline it. A request does not automatically require a separate charge; its treatment depends on the work and the agreement.
Keep the current approved version easy to identify. Preserve earlier versions so the team can trace what changed and why.
Separate Completion From Ongoing Operation
Define where the build ends and continuing responsibility begins.
The release scope should identify who approves launch, who performs final production checks and who responds if an agreed customer task fails. Handover should specify accounts, documentation, files and training rather than simply promising to “send everything.”
Use a website handover checklist to turn those agreed items into receipt and verification checks at completion.
Post-launch support also needs boundaries. State its duration, included corrections or assistance, reporting route and any separately commissioned work.
A support period does not establish permanent responsibility for updates, backups, renewals or content accuracy. Assign ongoing website maintenance explicitly, whether the business handles it internally or appoints a provider.
Review the Scope Before Approving It
Read the document as someone who must deliver the work and as someone who must accept it.
Check whether:
- Each deliverable has identifiable coverage and an acceptance method.
- Page, template and content quantities agree with the attached inventory.
- Required inputs have owners and realistic deadlines.
- Integrations include the necessary account and testing responsibilities.
- Exclusions clarify the boundary without contradicting included work.
- Revisions and change requests have a defined process.
- Separate expenses and renewals are visible.
- Release, handover and continuing responsibilities are assigned.
- Unresolved decisions are clearly recorded.
- Everyone is reviewing the same document version.
If an item cannot yet be priced, scheduled or verified, record what needs investigation before committing to it.
A useful scope gives the project a reviewable starting point. The business should know what it is approving, and the delivery team should know what it is expected to produce. When a requirement changes, update that shared record before the change becomes undocumented work.