Project Scope Document Template for Agencies (Free Template)
A project scope document is a boundary document. It defines what the project includes, what it explicitly excludes, the constraints under which work will proceed, and the conditions under which both parties agree to proceed. It is different from a brief. A brief captures what the client wants and why. A scope document captures what the agency will deliver and under what terms.
What is a project scope document?
Both a brief and a scope document are necessary. Together they form the foundation of a commitment both parties can stand behind. The brief ensures the agency understands the client's goals. The scope document ensures the client understands what they are buying and what is not included.
A scope document without explicit exclusions is an invitation for scope creep. A scope document without a defined change request process is a guarantee of it. Every section of a scope document that is vague or missing is a negotiation deferred to a more expensive moment in the project.
What to include in a scope document
- Project summary: A two to three sentence description of the project: what it is, what it will accomplish, and for whom. Written from the agency's perspective, not the client's.
- Deliverables list: An explicit, named list of every output, with format, quantity, and platform. Not 'a website' but '12 pages, designed in Figma, built in Webflow, mobile-optimized, with a blog CMS and a Klaviyo integration.'
- Explicit exclusions: What the project does not include. This section is as important as the deliverables list. If it is not in the scope document, clients will assume it is included. List every common assumption that does not apply.
- Assumptions: The conditions that must hold for the scope and timeline to be valid. 'This scope assumes the client provides all copy and images by the content handoff date. Delays to content delivery will affect the project timeline.'
- Timeline milestones: Not just a final deadline, but the dates by which each major deliverable will be completed and each review round will close. Milestones with specific dates, not durations.
- Pricing basis: What the cost covers, what triggers an additional cost, and the process for approving out-of-scope work. If the pricing is fixed, define what changes would make it variable.
- Change request process: How changes to scope are requested, evaluated, priced, and approved. Without a defined process, every change becomes a goodwill negotiation rather than a business conversation.
Download the free scope document template
The template below is structured around the seven sections above. Adapt the exclusions and assumptions sections carefully, because these are the most project-specific sections and the ones most often left blank.
# Project Scope Document **Project:** [Project name] **Client:** [Client name] **Agency:** [Agency name] **Date:** [Date] **Version:** [v1.0] ## Project Summary [Two to three sentences describing the project, its objective, and the client it serves.] ## Deliverables [List every output with format, quantity, platform, and any constraints.] 1. [Deliverable: format, platform] 2. [Deliverable: format, platform] 3. [Deliverable: format, platform] ## Exclusions The following are explicitly not included in this scope: - [Exclusion 1] - [Exclusion 2] - [Exclusion 3] ## Assumptions This scope is valid under the following conditions: - Client provides all copy and images by [content handoff date] - [Additional assumption] - [Additional assumption] ## Timeline - Scope sign-off: [Date] - [Milestone]: [Date] - [Milestone]: [Date] - Final delivery: [Date] ## Pricing Total: [Amount] Basis: [Fixed / hourly / milestone-based] Out-of-scope work: [Pricing mechanism and approval process] ## Change Request Process [Describe how changes are submitted, who evaluates them, how they are priced, and who approves them before work proceeds.]
How Clariva generates your scope document from a brief
When you analyze a brief in Clariva, the output maps directly to a scope document. Coverage dimensions correspond to scope sections. Risk flags identify the gaps that will cause scope creep if left unresolved. The brief pack Clariva generates includes a scope definition that your team can use as the basis for a client-ready scope document.
Every gap Clariva flags before commitment is a scope creep vector after it. The analysis stage, before the project starts, is where scope documents are validated, not amended. Analyze your brief before you commit, and the scope document becomes a confirmation of what both parties already agreed to.
Scope creep: the gaps that let it happen
Both parties thought they understood what was included. Neither wrote it down. By week six, the client is asking for something the agency never priced. The fix is a specific deliverables list with explicit exclusions, written before commitment, not after.
A scope document without exclusions invites expansion. If you built a five-page site and the brief said 'website,' the client will ask about the blog, the careers page, and the e-commerce section. Exclusions make the boundary visible before either party crosses it.
The first out-of-scope request is the easiest to say yes to. By the time you have said yes four times, the economics of the project no longer work. A defined process with a pricing threshold and a written approval step makes every additional request a business conversation rather than a goodwill decision.
Skip the template. Generate it automatically.
Clariva generates this document from a brief description or existing document, scored, validated, and ready to use.