{"id":58,"date":"2026-07-05T23:49:52","date_gmt":"2026-07-05T23:49:52","guid":{"rendered":"https:\/\/wisegrid.co\/blog\/scope-of-work-template\/"},"modified":"2026-07-05T23:49:52","modified_gmt":"2026-07-05T23:49:52","slug":"scope-of-work-template","status":"publish","type":"post","link":"https:\/\/wisegrid.co\/blog\/scope-of-work-template\/","title":{"rendered":"Scope of Work Template: Every Section, With an Example"},"content":{"rendered":"<p><em>By <a href=\"\/blog\/author\/ryan-kramer\/\">Ryan Kramer<\/a>, founder of Wisegrid. Last updated July 2026.<\/em><\/p>\n<p>A scope of work (SOW) is the document that defines exactly what will be delivered on a project: the deliverables, the tasks that produce them, the timeline and milestones, the acceptance criteria, and, just as importantly, what is not included. It is the reference both sides return to when someone asks \u201cwait, is that part of the project?\u201d, which is why a good one is written before that question gets expensive.<\/p>\n<p>This guide walks through every section a scope of work needs, gives you the complete template to copy, shows a worked example, and untangles the three terms people use interchangeably: scope of work, statement of work, and project scope statement.<\/p>\n<blockquote>\n<p><strong>Key takeaways<\/strong> \u2013 <strong>A scope of work answers five questions:<\/strong> what will be delivered, what work produces it, when, how \u201cdone\u201d will be judged, and what is explicitly excluded. \u2013 <strong>Exclusions are the highest-value section.<\/strong> Almost every scope dispute lives in work the client assumed was included and the team assumed was not. \u2013 <strong>Deliverables need acceptance criteria<\/strong>, written as checkable statements. \u201cModern, professional website\u201d is an argument waiting to happen; \u201cpasses the launch checklist in Appendix A\u201d is not. \u2013 <strong>Scope of work and statement of work overlap but differ:<\/strong> the statement of work is the broader contractual document; the scope of work is its what-gets-done core. A project scope statement is the internal PM equivalent. \u2013 <strong>The SOW is not done when it is signed.<\/strong> It has to turn into a tracked plan, or the document and the delivered work drift apart.<\/p>\n<\/blockquote>\n<nav class=\"wg-toc\" aria-label=\"Table of contents\"><div class=\"wg-toc-eyebrow\"><span class=\"lp-dot\" aria-hidden=\"true\"><\/span> On this page<\/div><ul>\n<li><a href=\"#what-is-a-scope-of-work\">What is a scope of work?<\/a><\/li>\n<li><a href=\"#scope-of-work-vs-statement-of-work-vs-project-scope-statement\">Scope of work vs statement of work vs project scope statement<\/a><\/li>\n<li><a href=\"#the-sections-of-a-scope-of-work\">The sections of a scope of work<\/a><\/li>\n<li><a href=\"#the-scope-of-work-template\">The scope of work template<\/a><\/li>\n<li><a href=\"#a-worked-example\">A worked example<\/a><\/li>\n<li><a href=\"#the-mistakes-that-cause-scope-disputes\">The mistakes that cause scope disputes<\/a><\/li>\n<li><a href=\"#from-signed-sow-to-tracked-project\">From signed SOW to tracked project<\/a><\/li>\n<li><a href=\"#faq\">FAQ<\/a><\/li>\n<\/ul><\/nav>\n<h2 id=\"what-is-a-scope-of-work\">What is a scope of work?<\/h2>\n<p>A scope of work is the written definition of a project\u2019s boundaries: the deliverables to be produced, the work required to produce them, the schedule and milestones, the standards by which completion will be judged, and the assumptions and exclusions that fence the whole thing in. Between a client and a vendor it usually forms part of the contract; between internal teams it is the agreement that stops a project from quietly growing.<\/p>\n<p>Its real job is economic. Every project accumulates moments where someone wants more than was planned: another revision round, one more integration, \u201csmall\u201d additions that compound. Without a written scope, each of those moments is a negotiation the delivery side usually loses; with one, the conversation shifts from \u201cis this included?\u201d to \u201cthis is a change; here is what it does to the schedule and price.\u201d The SOW does not prevent change; it makes change visible and priceable.<\/p>\n<h2 id=\"scope-of-work-vs-statement-of-work-vs-project-scope-statement\">Scope of work vs statement of work vs project scope statement<\/h2>\n<p>The three terms get used loosely, and both \u201cscope of work\u201d and \u201cstatement of work\u201d abbreviate to SOW, which does not help. The working distinctions:<\/p>\n<div class=\"wg-table-wrap\"><table>\n<thead>\n<tr>\n<th>Term<\/th>\n<th>What it is<\/th>\n<th>Where it lives<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Statement of work<\/strong><\/td>\n<td>The broader contractual document governing an engagement: scope plus pricing, payment schedule, invoicing terms, governance, legal terms, signatures<\/td>\n<td>Attached to or referenced by the contract (often under a master services agreement)<\/td>\n<\/tr>\n<tr>\n<td><strong>Scope of work<\/strong><\/td>\n<td>The what-gets-done core: deliverables, tasks, timeline, acceptance criteria, exclusions<\/td>\n<td>Usually a section of the statement of work, or a standalone document on lighter engagements<\/td>\n<\/tr>\n<tr>\n<td><strong>Project scope statement<\/strong><\/td>\n<td>The internal PM equivalent: deliverables, boundaries, acceptance criteria, assumptions and constraints for a project team, no commercial terms<\/td>\n<td>Inside the project plan or charter; PMBOK-style projects produce one during scope planning<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/div>\n<p>In practice: if there is a client and money, you are writing a scope of work, possibly inside a statement of work. If it is an internal project, you are writing a project scope statement, which is the same content minus pricing and legal boilerplate. The template below serves both; delete the commercial rows for internal use.<\/p>\n<h2 id=\"the-sections-of-a-scope-of-work\">The sections of a scope of work<\/h2>\n<p><strong>1. Project overview and objectives.<\/strong> Two or three sentences: what the project is, for whom, and the outcome that defines success. Objectives should be checkable at the end (\u201creduce checkout steps from five to two\u201d), not aspirational (\u201cimprove the customer experience\u201d).<\/p>\n<p><strong>2. Deliverables.<\/strong> The heart of the document: every artifact the project hands over, listed individually with enough specificity to be counted and checked. \u201cWebsite\u201d is not a deliverable; \u201cresponsive marketing site of up to 12 templated pages, deployed to the client\u2019s hosting\u201d is.<\/p>\n<p><strong>3. Tasks \/ scope of services.<\/strong> The major work areas that produce the deliverables (discovery, design, build, testing, launch support). This section tells the reader what activity is covered, which matters when a dispute is about effort (\u201cwe assumed you\u2019d migrate the data\u201d) rather than artifacts.<\/p>\n<p><strong>4. Schedule and milestones.<\/strong> Phases, milestone dates, and the review gates between them. Anchor dates to dependencies where you can (\u201cdesign sign-off + 6 weeks\u201d) so one slip does not falsify the whole table.<\/p>\n<p><strong>5. Acceptance criteria.<\/strong> For each deliverable, the checkable conditions under which it is accepted, plus the review process itself: who reviews, within how many business days, how many revision rounds are included, and what happens when the review window lapses (deemed acceptance after N days is common and worth agreeing up front).<\/p>\n<p><strong>6. Exclusions.<\/strong> The explicit not-included list, written from experience of what clients in this kind of project tend to assume: content writing, data migration, ongoing maintenance, third-party license costs, post-launch changes. Every line here is a future dispute pre-resolved.<\/p>\n<p><strong>7. Assumptions and dependencies.<\/strong> What must be true, and what you need from the client by when. Pair each client-owed item with a consequence (\u201cdates shift day-for-day with late materials\u201d), or the dependency has no teeth.<\/p>\n<p><strong>8. Roles, governance, and change control.<\/strong> Who owns what on both sides, who can approve a change, and the change process: proposed in writing, priced for schedule and cost impact, approved before the work happens.<\/p>\n<p><strong>9. Commercial terms.<\/strong> Price, payment schedule, invoicing, expenses. On contractual engagements this may live in the statement of work or master agreement instead; make sure it lives somewhere and is referenced.<\/p>\n<p><strong>10. Signatures.<\/strong> Named approvers on both sides, with dates. Unsigned scopes protect no one.<\/p>\n<h2 id=\"the-scope-of-work-template\">The scope of work template<\/h2>\n<p>Copy this structure directly; the bracketed prompts tell you what each line needs.<\/p>\n<pre><code>SCOPE OF WORK\nProject: [name]  \u00b7  Client: [name]  \u00b7  Date: [date]  \u00b7  Version: [v1.0]\n\n1. OVERVIEW &amp; OBJECTIVES\n   [2-3 sentences: what, for whom, and the measurable outcome(s).]\n\n2. DELIVERABLES\n   D1. [Deliverable, with quantity\/spec: \"up to 12 templated pages\"]\n   D2. [...]\n\n3. SCOPE OF SERVICES (TASKS)\n   Phase 1 [Discovery]: [major activities]\n   Phase 2 [Design]: [...]\n   Phase 3 [Build\/Deliver]: [...]\n\n4. SCHEDULE &amp; MILESTONES\n   M1 [Kickoff]              [date]\n   M2 [Design sign-off]      [date or \"M1 + N weeks\"]\n   M3 [Delivery\/launch]      [...]\n\n5. ACCEPTANCE CRITERIA\n   D1 accepted when: [checkable conditions]\n   Review process: [who reviews] within [N business days];\n   [N] revision rounds included; deemed accepted after [N] days\n   without written feedback.\n\n6. EXCLUSIONS (NOT IN SCOPE)\n   - [Everything a reasonable client might assume is included\n      but is not. Be blunt.]\n\n7. ASSUMPTIONS &amp; CLIENT DEPENDENCIES\n   - [Assumption or client-owed item, its due date, and the\n      consequence if late.]\n\n8. ROLES &amp; CHANGE CONTROL\n   [Client owner], [vendor owner]. Changes are requested in\n   writing, assessed for schedule\/cost impact, and approved by\n   [names] before work begins.\n\n9. COMMERCIAL TERMS\n   [Price, payment schedule, invoicing, expenses; or reference\n    to the governing agreement.]\n\n10. APPROVALS\n   [Name, role, signature, date] x2<\/code><\/pre>\n<h2 id=\"a-worked-example\">A worked example<\/h2>\n<p>The key sections for a fictional but realistic engagement, a marketing site redesign:<\/p>\n<p><strong>Overview.<\/strong> Redesign and rebuild Meridian Outfitters\u2019 marketing website on their existing CMS, replacing the current 40-page site with a templated 12-page architecture. Objectives: launch before the Sep 15 campaign; pass Core Web Vitals on the ten highest-traffic pages.<\/p>\n<p><strong>Deliverables.<\/strong> D1: sitemap and wireframes for 12 page types. D2: visual design system (desktop + mobile comps for all 12). D3: built and deployed templates on the client\u2019s CMS. D4: content migration of the 40 existing pages into the new templates. D5: launch checklist execution and two weeks of post-launch defect fixes.<\/p>\n<p><strong>Milestones.<\/strong> Kickoff Jul 14 \u00b7 Wireframe sign-off Jul 28 \u00b7 Design sign-off Aug 18 \u00b7 Build complete Sep 5 \u00b7 Launch Sep 12.<\/p>\n<p><strong>Acceptance.<\/strong> D2 accepted when all 12 page types are approved in writing by the client\u2019s marketing director; two revision rounds included, further rounds change-controlled. D3 accepted when templates render the approved designs on the current versions of Chrome, Safari, Edge, and Firefox at the breakpoints listed in Appendix A and pass the launch checklist.<\/p>\n<p><strong>Exclusions.<\/strong> Copywriting and photography (client provides all content); SEO strategy beyond preserving existing URL redirects; CMS license and hosting costs; maintenance after the two-week post-launch window; any pages beyond the 12 templates.<\/p>\n<p><strong>Dependencies.<\/strong> Client provides brand assets by Jul 21 and final page copy by Aug 25; CMS staging access by Jul 16. Late materials shift downstream dates day-for-day.<\/p>\n<p>Notice the shape: quantities on every deliverable, sign-off owners named, revision rounds counted, and the exclusions list aimed precisely at what a marketing client tends to assume (copy, photos, extra pages). That last section is the one this example project would have been sunk without.<\/p>\n<h2 id=\"the-mistakes-that-cause-scope-disputes\">The mistakes that cause scope disputes<\/h2>\n<ul>\n<li><strong>Uncounted deliverables.<\/strong> Any deliverable without a quantity or spec (\u201csocial assets\u201d, \u201crevisions\u201d) will be interpreted generously by the other side. Count everything countable.<\/li>\n<li><strong>Adjectives as acceptance criteria.<\/strong> \u201cModern\u201d, \u201cintuitive\u201d, and \u201chigh-quality\u201d are opinions. Criteria must be checkable by both sides reading the same words.<\/li>\n<li><strong>No exclusions section.<\/strong> The most common omission. If the document only says what is included, everything else is ambiguous, and ambiguity resolves against whoever wants to get paid.<\/li>\n<li><strong>Client dependencies without consequences.<\/strong> \u201cClient provides content by Aug 25\u201d means nothing on Aug 26 unless the document says what happens next.<\/li>\n<li><strong>Change control that exists only on paper.<\/strong> If the team absorbs \u201csmall\u201d changes without invoking the process, the tenth small change is unbillable. The first change request sets the precedent; make it formally, however friendly the wording.<\/li>\n<li><strong>The signed SOW going in a drawer.<\/strong> If the delivery plan is rebuilt from memory in a task tool, scope drifts from the document within weeks, and nobody notices until the acceptance meeting.<\/li>\n<\/ul>\n<h2 id=\"from-signed-sow-to-tracked-project\">From signed SOW to tracked project<\/h2>\n<p>The document only protects you if the plan the team executes is visibly the same list of deliverables the client signed. The practical move: the day the SOW is signed, turn it into the project\u2019s tracking sheet, one row per deliverable and milestone with owner, due date, acceptance criterion, and status, plus client-owed dependencies as dated rows, so the chase list lives where the work does.<\/p>\n<p>In Wisegrid that structure is reusable: build the SOW-shaped project once (deliverables sheet, dependency rows, a status <a href=\"\/features\/dashboards\">dashboard<\/a> the client can be shown), save it as a <a href=\"\/features\/blueprints\">blueprint<\/a>, and provision an identical, pre-filled copy for every new engagement in under a minute. Date-triggered <a href=\"\/features\/automations\">automations<\/a> chase the client-owed items so \u201ccontent due Aug 25\u201d actually produces a nudge on Aug 25.<\/p>\n<p>The full build is in the companion guide: <strong><a href=\"https:\/\/wisegrid.co\/guides\/scope-of-work\">From scope of work to tracked project in Wisegrid<\/a><\/strong>.<\/p>\n<h2 id=\"faq\">FAQ<\/h2>\n<h3 id=\"what-is-a-scope-of-work\">What is a scope of work?<\/h3>\n<p>The document defining a project\u2019s boundaries: deliverables, the work that produces them, schedule and milestones, acceptance criteria, and explicit exclusions. Between client and vendor it usually forms part of the contract.<\/p>\n<h3 id=\"what-is-the-difference-between-a-scope-of-work-and-a-statement-of-work\">What is the difference between a scope of work and a statement of work?<\/h3>\n<p>The statement of work is the broader contractual document (scope plus pricing, payment terms, governance, legal terms); the scope of work is its core section defining what gets done. Both abbreviate to SOW, so confirm which document your counterparty means.<\/p>\n<h3 id=\"what-is-a-project-scope-statement\">What is a project scope statement?<\/h3>\n<p>The internal project management version of a scope of work: deliverables, boundaries, acceptance criteria, assumptions, and constraints, produced during scope planning, without commercial terms. Same content discipline, no contract attached.<\/p>\n<h3 id=\"how-do-i-write-a-scope-of-work\">How do I write a scope of work?<\/h3>\n<p>Work through the ten sections above in order: overview, deliverables (counted), tasks, schedule, acceptance criteria, exclusions, assumptions and dependencies, roles and change control, commercial terms, signatures. Then have someone read it looking only for ambiguity.<\/p>\n<h3 id=\"how-detailed-should-a-scope-of-work-be\">How detailed should a scope of work be?<\/h3>\n<p>Detailed enough that a disputed item can be resolved by reading the document rather than by negotiation. Quantities, checkable acceptance criteria, and a blunt exclusions list are where detail pays; task-level minutiae is where it does not.<\/p>\n<h3 id=\"is-a-scope-of-work-legally-binding\">Is a scope of work legally binding?<\/h3>\n<p>When it is part of a signed contract or statement of work, its terms are generally binding as part of that agreement. For anything with meaningful money attached, have your contract reviewed by a lawyer; this guide is about writing clear scope, not legal advice.<\/p>\n<hr>\n<h3 id=\"turn-the-signed-scope-into-the-plan-the-client-watches\">Turn the signed scope into the plan the client watches<\/h3>\n<p>One row per deliverable, dependencies with dates, and a client-facing dashboard, provisioned from a blueprint for every new engagement.<\/p>\n<p><strong><a href=\"\/signup\">Start free \u2192<\/a><\/strong> \u00b7 <a href=\"https:\/\/wisegrid.co\/guides\/scope-of-work\">From SOW to tracked project \u2192<\/a> \u00b7 <a href=\"\/blog\/client-onboarding-checklist\">Client onboarding checklist \u2192<\/a><\/p>\n<hr>\n<blockquote>\n<p><strong>About the author<\/strong> <strong><a href=\"\/blog\/author\/ryan-kramer\/\">Ryan Kramer<\/a><\/strong> is the founder of Wisegrid, a higher-capacity Smartsheet alternative with project blueprints, date-triggered automations, and client-facing dashboards included in the normal $9 and $19 tiers. He writes about turning client agreements into systems that keep both sides honest. <a href=\"\/blog\/author\/ryan-kramer\/\">More from Ryan \u2192<\/a><\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"<p>By Ryan Kramer, founder of Wisegrid. Last updated July 2026. A scope of work (SOW) is the document that defines exactly what will be delivered on a project: the deliverables, the tasks\u2026<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-58","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/posts\/58","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/comments?post=58"}],"version-history":[{"count":0,"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/posts\/58\/revisions"}],"wp:attachment":[{"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/media?parent=58"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/categories?post=58"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/tags?post=58"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}