Scope of Work Template and How to Draft One (2026)

What is a scope of work, and when do you need one? A scope of work (SOW) is the part of a contract that says exactly what will be done: the objectives, the deliverables, the tasks, the timeline, who does what, and how you will know the work is finished. It sits inside or alongside a master services agreement or a project contract. You need one whenever you are paying for work rather than buying a finished product, because the scope of work is what turns "build us a website" or "advise us on the merger" into something both sides can measure and accept. A good scope of work is specific and measurable. It names deliverables you can point at, acceptance criteria you can test, and exclusions that make clear what is not included. A vague scope is the most common reason projects overrun, because every gap becomes an argument about whether the work was part of the deal. Below is a scope of work template you can copy and adapt, followed by guidance on how to fill each section. This is general information, not legal advice. For a large or high-value engagement, have the contract the scope sits in reviewed by a lawyer. ## Scope of work template ```

SCOPE OF WORK Project: [NAME] SOW No.: [NUMBER] Date: [DATE] Client: [CLIENT NAME] Provider: [PROVIDER NAME] Governing agreement: [Master Services Agreement dated [DATE]] 1. BACKGROUND AND OBJECTIVES Briefly, what the client wants and why: [e.g. deliver a customer portal that lets users self-serve account tasks, reducing support tickets]. Success looks like: [measurable objective, e.g. portal live, 5 features working, passing the acceptance tests in section 6]. 2. SCOPE OF SERVICES The Provider will: 2.1 [Task / workstream 1 - describe concretely] 2.2 [Task / workstream 2] 2.3 [Task / workstream 3] 3. DELIVERABLES No. Deliverable Description / specification Due D1 [e.g. design mockups] [reference spec or drawing] [date] D2 [e.g. working build] [features, environment] [date] D3 [e.g. documentation] [scope of docs] [date] 4. OUT OF SCOPE (EXCLUSIONS) The following are NOT included and require a separate SOW or change order: [e.g. ongoing maintenance; third-party license costs; content creation; data migration beyond [N] records; support after go-live]. 5. TIMELINE AND MILESTONES Milestone Target date Payment linked (if any) [Kickoff] [date] [-] [Milestone 1 / D1 accepted] [date] [% or amount] [Milestone 2 / D2 accepted] [date] [% or amount] [Final acceptance] [date] [% or amount] 6. ACCEPTANCE CRITERIA Each deliverable is accepted when: 6.1 It meets the specification in section 3; 6.2 It passes [named tests / review]; and 6.3 The Client confirms acceptance in writing within [N] days of delivery, or is deemed to accept if no written rejection with reasons is given in that period. Rejected deliverables are corrected and re-submitted within [N] days. 7. ROLES AND RESPONSIBILITIES Provider: [who does the work, named lead, key staff]. Client: [what the client must provide: access, data, approvals, a named point of contact, sign-off within agreed times]. 8. ASSUMPTIONS AND DEPENDENCIES This SOW assumes: [e.g. client provides content by [date]; stable requirements; a single staging environment]. Delay or failure in a client dependency may shift dates and cost via a change order. 9. FEES AND PAYMENT [Fixed fee of [AMOUNT] by milestone / time and materials at [rate] with an estimate of [AMOUNT] and a not-to-exceed cap of [AMOUNT]]. Taxes [inclusive / exclusive, e.g. GST]. Expenses [included / billed at cost with approval]. 10. CHANGE CONTROL Any change to this scope, deliverables, timeline or fee is agreed in writing through a change order before the changed work begins. Signed: Client: ____________________ Provider: ____________________