This outline covers the sections that scope disputes actually turn on. It is deliberately ordered the way a client reads: what we are doing, what it produces, what we are assuming, what we are not doing, and how we will handle it when reality differs.
Adapt the wording to your contract language and jurisdiction. Where a section offers sample sentences, treat them as a starting shape rather than legal text.
How to use this
- Draft sections 3 through 6 first — deliverables, assumptions, exclusions, dependencies. They carry the most risk and the rest of the document follows from them.
- Write nothing in the narrative that is not in the approved estimate, and nothing in the estimate that is not reflected in the narrative.
- Have someone who was not in discovery read the deliverables and acceptance sections and describe what the client will receive. Any gap between their reading and yours is a scope dispute in advance.
1. Parties, dates, and governing agreement
- Client legal entity
- Full legal name, not the brand name.
- Supplier legal entity
- Your contracting entity.
- Effective date / expected start
- Note if start is conditional on signature or dependency.
- Governing agreement
- MSA, framework agreement, or standard terms this SOW sits under.
- SOW reference and version
- Version matters once scope is renegotiated.
2. Background and objectives
Two or three short paragraphs in the client's own language. This section is where the client checks that you understood the problem, so use the words they used in discovery.
- The business situation prompting the engagement.
- The outcome the client is trying to reach.
- What is explicitly out of scope for this phase but on the roadmap.
- How success will be judged at the end of the engagement.
3. Scope of services and deliverables
Write deliverables as countable objects, each with a form, a quantity, and a recipient. Activities without an end state belong in the approach section, not here.
- Deliverable name
- The artifact: document, environment, configured module, trained team.
- Form and format
- Written document, working environment, dashboard, recorded session.
- Quantity
- How many reports, integrations, workshops, or rounds of revision.
- Recipient / reviewer
- Named role who receives and reviews it.
- Review cycles included
- State the number; unlimited revision is the most common margin leak.
Sample language
Deliverable 3.2 — Migration runbook. A written document covering the three production data pipelines identified in discovery, delivered in PDF and editable format to the Client Technical Lead. Includes two rounds of Client review and consolidated feedback.
4. Assumptions
The test for this section: if the belief were wrong, would the effort change? If yes, it belongs here in plain language.
- Environments, systems, and access are available from the stated date.
- Named Client roles are available for review at an agreed cadence.
- Client review feedback is consolidated and returned within the stated window.
- Source data is in the condition described during discovery.
- Required third-party licences and subscriptions are in place and paid for by the Client.
- Work is performed remotely during stated business hours unless otherwise agreed.
- No more than the stated number of stakeholder groups participate in review.
Sample language
This SOW and its estimate assume the conditions listed in this section. If an assumption proves incorrect, the parties will assess the impact on effort, schedule, and fees through the change control process in section 8 before further work is performed on the affected item.
5. Exclusions
Exclusions answer what a reasonable reader would otherwise assume is included. They should be specific and unsurprising — work handled separately, not work dismissed.
- Ongoing support, maintenance, or hosting after acceptance.
- Third-party licence, subscription, or infrastructure costs.
- Data remediation or cleansing beyond the stated volume or condition.
- Systems adjacent to the ones named in section 3.
- End-user training beyond the stated sessions and audience.
- Formal certification, accessibility audit, or penetration testing unless named as a deliverable.
- Travel and onsite attendance unless requested and agreed in writing.
6. Client dependencies
A dependency is an obligation on someone else. Give each one an owner and a timing expectation — these are the items that quietly consume schedule.
- Dependency
- Access, data, decision, environment, or personnel required.
- Owner
- Named Client role, not a department.
- Required by
- Date or project milestone.
- Impact if late
- State the consequence: schedule shift, idle time, re-planning.
Sample language
Where a Client dependency is not met by the date stated, the Supplier will notify the Client and the parties will agree a revised schedule. Effort incurred as a result of delay or re-planning may be chargeable at the rates in section 7.
7. Commercial terms
- Pricing model: fixed fee, time and materials, capped time and materials, or retainer.
- Total fee or rate card, with the estimate attached or referenced by version.
- Invoicing schedule tied to dates or milestones, and payment terms.
- Expenses policy and pre-approval threshold.
- Rate review or indexation, if the engagement runs beyond a stated period.
- Currency and tax treatment.
8. Change control
Keep the mechanism light enough that your own team will use it. Process that is bypassed is the same as no process.
- How a change is raised, and by whom on each side.
- Who approves on each side, with named roles and an authority threshold.
- What a change request records: description, effort impact, schedule impact, fee impact.
- How quickly each side responds to a raised change.
- Whether work on the affected item pauses pending approval.
- A lightweight path for small changes below an agreed effort threshold.
Sample language
Either party may request a change to scope, deliverables, or schedule in writing. The Supplier will assess the impact on effort, fees, and timeline and issue a change request. Work on the affected item proceeds once both named approvers have signed. Changes assessed at or below [X] hours may be approved by the Client Project Lead by email.
9. Acceptance
Acceptance is where scope confusion becomes financial. Criteria should be verifiable by someone who was not in the discovery sessions.
- Acceptance criteria
- A demonstrated behaviour, a document reviewed against a stated outline, a test that passes.
- Reviewer
- Named role with authority to accept.
- Review window
- Business days from submission.
- Deemed acceptance
- What happens if no response arrives within the window.
- Rejection handling
- Written reasons referencing criteria, and the remediation cycle.
Sample language
The Client will review each deliverable within ten business days of submission and either accept it or provide written reasons for rejection referencing the stated acceptance criteria. If no response is received within the review window, the deliverable is deemed accepted. Feedback submitted after acceptance is handled through change control.
10. Governance and communication
- Named project leads on both sides, with escalation path.
- Status reporting cadence and format.
- Standing meeting rhythm and who is expected to attend.
- Decision log and where it lives.
- Risk and issue review cadence.
11. Term, suspension, and termination
- Expected duration and any expiry of the SOW itself.
- Notice period for termination for convenience, if permitted.
- Treatment of work in progress and committed resources on termination.
- Suspension terms if Client dependencies stall the engagement.
12. Intellectual property, confidentiality, and data
- Ownership of deliverables on payment, and retained supplier background IP.
- Licence terms for reusable frameworks, accelerators, or tooling.
- Confidentiality reference to the governing agreement.
- Handling, location, and retention of Client data during the engagement.
- Use of subcontractors, and any AI tooling disclosure your client requires.
13. Signatures
- Client signatory
- Name, title, and confirmation of signing authority.
- Supplier signatory
- Name and title.
- Date and attachments
- List the estimate version and any annexes forming part of this SOW.
This template is general guidance for scoping and drafting practice, not legal advice. Have your own counsel review contract language before use.
Put this into practice
SOW Studio turns discovery inputs into structured scope, a reviewable estimate, and a client-ready Statement of Work — with your team approving every step.
No credit card required. Full Professional capabilities for 14 days.