Markdown Editor

Statement of Work (SOW) Template

SOW: scope in/out, deliverables with acceptance criteria, milestones, roles of both parties, change control, payment schedule, signatures

NegociosCompletastatementwork

Cómo usar: Use to define a supplier engagement under a master agreement. Write deliverables and objective acceptance criteria first, then schedule and payments. The main pitfall is vague acceptance criteria and unstated client dependencies.

Vista previa

Statement of Work: [Project name]

Full Statement of Work (SOW) that defines exactly what a supplier will deliver to a client under an agreed contract: background, objectives, scope, deliverables with acceptance criteria, milestones, roles of both parties, assumptions and dependencies, acceptance process, change control, pricing and payment schedule, governance, warranties and signatures. Based on common contracting and project delivery practice. Replace every [bracketed] value and every row marked Example. This is a document format, not legal advice: have the final SOW and the governing agreement reviewed by legal counsel.

Document control

FieldValue
SOW number[SOW-YYYY-NNN]
Project[Project name]
Client[Client legal name]
Supplier[Supplier legal name]
Governing agreement[MSA reference and date]
Version[0.1]
Status[Draft / Under negotiation / Signed / Superseded]
Effective dateYYYY-MM-DD
End dateYYYY-MM-DD
Prepared by[@name]
Last updatedYYYY-MM-DD

Approvals

PartyRoleNameDecisionDate
ClientProject sponsor[@name][Approved]YYYY-MM-DD
ClientProcurement / legal[@name][Approved]YYYY-MM-DD
SupplierDelivery lead[@name][Approved]YYYY-MM-DD
SupplierCommercial / legal[@name][Approved]YYYY-MM-DD

Revision history

VersionDateAuthorChange summaryChange request
0.1YYYY-MM-DD[@name]First draft for client reviewn/a
1.0YYYY-MM-DD[@name]Example: Signed versionn/a
1.1YYYY-MM-DD[@name]Example: Added reporting integration deliverable D6CR-003

Contents

1. Background

[Client] operates [business context]. [Describe the problem or opportunity.] Following [proposal reference / tender reference] dated YYYY-MM-DD, [client] has engaged [supplier] to [high-level purpose].

Example: "The client runs an online store on a self-hosted platform that reaches end of support on YYYY-MM-DD. Following proposal PROP-2026-041, the client has engaged the supplier to migrate the store to a hosted commerce platform and integrate it with the existing warehouse and accounting systems."

2. Objectives

IDObjectiveMeasure of success
OB-1Example: Move the store to a supported platformLegacy platform decommissioned by YYYY-MM-DD
OB-2Example: Keep order flow to the warehouse automatic100% of orders reach the warehouse system without manual entry
OB-3Example: Preserve search trafficOrganic sessions within 10% of baseline 8 weeks after launch
OB-[N][Objective][Measure]

3. Scope

3.1 In scope

  • [Activity or work package, for example storefront build using the client's brand guidelines]
  • [Migration of products, customers and 24 months of orders]
  • [Integrations with warehouse system and accounting system]
  • [Training and hypercare as described in section 13]

3.2 Out of scope

  • [For example, new product photography]
  • [For example, changes to the warehouse system itself]
  • [For example, marketing campaigns and paid media]

Any work not listed in section 3.1 is out of scope and may be added only through the change control process in section 10.

3.3 Standards and constraints

[List standards, policies and constraints the supplier must follow, for example the client's information security policy, accessibility level (such as WCAG 2.2 AA), brand guidelines, approved hosting regions for personal data, and change freeze periods such as peak trading weeks.]

3.4 Location and working arrangements

[Where the work is performed, working hours, travel, access to client premises and systems, and any security vetting required.]

4. Approach

[Describe the delivery method (for example, phased, with two-week iterations), the environments used, testing approach, and how the client will see progress.]

Example: "Work runs in three phases: design, build and launch. The build phase uses two-week iterations, each ending with a demonstration in the client's staging environment. The supplier maintains separate development, staging and production environments; only the client may approve a release to production. Testing covers unit tests for custom code, integration tests for each interface, and a user acceptance test cycle run by client staff using scripts prepared by the supplier. Progress is visible at all times in a shared project board."

EnvironmentPurposeOwnerData
DevelopmentSupplier build and unit testingSupplierSynthetic data only
StagingDemonstrations, integration and user acceptance testingSupplier, client accessMasked copy of production data
ProductionLive storeClientLive data

5. Deliverables and acceptance criteria

IDDeliverableDescriptionAcceptance criteriaAccepted byDue
D1Example: Solution designPlatform configuration, data mapping, integration designDocument approved; covers all items in 3.1; no open high-severity review commentsClient project managerWeek 3
D2Example: StorefrontConfigured theme and pagesAll pages in the agreed sitemap present; Lighthouse performance score of 80 or more on mobile for home, category and product pagesClient e-commerce leadWeek 9
D3Example: Data migrationProducts, customers, ordersRecord counts match source within 0.1%; 50-record sample verified field by field without errorClient data ownerWeek 10
D4Example: Warehouse integrationOrder export and stock import200 test orders flow end to end with zero manual interventionClient operations leadWeek 10
D5Example: TrainingTwo sessions plus recordings and guidesSessions held; materials delivered; attendee list signedClient project managerWeek 11
D[N][Deliverable][Description][Criteria][Role][Due]

6. Milestones and schedule

MilestoneDeliverables includedTarget dateClient dependencyPayment linked
M1 Design approvedD1YYYY-MM-DDWorkshop attendance weeks 1-2Yes (P2)
M2 Build completeD2, D4YYYY-MM-DDTest data and system access by week 4Yes (P3)
M3 Go-liveD3, D5YYYY-MM-DDGo-live approval, DNS changeYes (P4)
M4 Hypercare closedSupport periodYYYY-MM-DDDefect triage within 1 dayYes (P5)

The schedule below shows the planned sequence.

7. Roles and responsibilities

7.1 Supplier

RoleNameResponsibilities
Delivery lead[@name]Overall delivery, status reporting, risk management
Solution architect[@name]Design, integration approach, technical quality
Developers / consultants[@names]Build, configuration, testing

7.2 Client

RoleNameResponsibilities
Project sponsor[@name]Funding, escalation, final acceptance
Project manager[@name]Day-to-day contact, coordinates client staff, signs acceptance forms
Subject matter experts[@names]Attend workshops, answer questions within 2 working days, test
IT / security[@name]Grants access to systems, approves security configuration

8. Assumptions and dependencies

IDTypeDescriptionOwnerImpact if not met
AD-01AssumptionExample: Source data is exported in CSV format by the clientClientAdditional effort for extraction
AD-02DependencyExample: Warehouse vendor provides API credentials by week 4ClientIntegration milestone moves day for day
AD-03AssumptionExample: Fewer than 15,000 product variantsSupplierMigration effort re-estimated
AD-[NN][Type][Description][Owner][Impact]

9. Acceptance process

  1. The supplier submits each deliverable with an acceptance form listing the criteria from section 5.
  2. The client reviews within [10 working days] and either accepts or issues a rejection notice listing each unmet criterion.
  3. The supplier corrects the listed issues and resubmits within [5 working days]; the client re-reviews only the listed issues.
  4. If the client neither accepts nor rejects within the review period, [the deliverable is deemed accepted / the supplier escalates under section 12], as agreed in the governing agreement.
  5. Use in live operation of a deliverable counts as acceptance, unless the parties agree otherwise in writing.
Defect severityDefinitionBlocks acceptance?
CriticalPrevents a core business function; no workaroundYes
HighMajor function impaired; workaround existsYes, unless agreed fix date
Medium / lowMinor or cosmeticNo; fixed during warranty

10. Change control

  1. Either party raises a change request (CR) describing the change and the reason.
  2. The supplier assesses impact on scope, schedule, price and risk within [5 working days].
  3. Both parties approve or reject the CR in writing. Approved CRs amend this SOW and are recorded in the revision history.
CR IDDescriptionRaised byImpact (cost / days)StatusApproved date
Example: CR-003Add sales reporting integrationClient+7,800 / +8 daysApprovedYYYY-MM-DD
CR-[NNN][Description][Party][Impact][Status]YYYY-MM-DD

11. Pricing and payment schedule

Pricing model: [Fixed price / Time and materials with cap / Retainer].

PaymentTriggerShareAmount (excl. tax)
P1Signature of this SOW20%Example: 19,600
P2M1 Design approved20%19,600
P3M2 Build complete30%29,400
P4M3 Go-live20%19,600
P5M4 Hypercare closed10%9,800
Total100%98,000
  • Rates for changes and out-of-scope work: [role and day rate table or reference]
  • Expenses: [for example, pre-approved travel at cost, capped at amount]
  • Invoicing and payment terms: [for example, invoice on milestone acceptance, payable within 30 days]
  • Tax: amounts exclude [VAT / sales tax], which is added at the applicable rate.

12. Governance and reporting

Forum or reportFrequencyAttendees / audienceContent
Status reportWeeklyClient PM, sponsorProgress, next steps, risks, issues, decisions needed
Project check-inWeeklyBoth PMs and leadsPlan review, dependencies
Steering meetingMonthlySponsor, delivery leadMilestones, budget, change requests, escalations

The weekly status report uses a red, amber or green rating for scope, schedule, budget and quality, with a one-line reason for any rating that is not green. Risks and issues are kept in a shared log with an owner and a due date for each action.

Escalation path: project managers, then delivery lead and client sponsor, then [executive contacts], within [3 / 5 / 10] working days at each level.

13. Warranties and support

[Placeholder: summarise the warranty period, for example "the supplier corrects defects in accepted deliverables reported within 60 days of go-live at no charge", hypercare hours and response targets, and any exclusions. The governing agreement's warranty and liability clauses apply and prevail.]

Support itemCommitment
Hypercare period[4 weeks after go-live]
Critical defect response[Within 4 business hours]
Warranty period[N days after acceptance]
Exclusions[Changes made by client or third parties; unsupported configurations]

14. Signatures

This SOW is entered into under, and is governed by, [governing agreement reference]. In case of conflict, [the governing agreement / this SOW] prevails.

ClientSupplier
Company[Client legal name][Supplier legal name]
Name[Name][Name]
Title[Title][Title]
Signature
DateYYYY-MM-DDYYYY-MM-DD

Standard and licence note

Based on common contracting and project delivery practice for statements of work. This template is original text written for this collection. It is a document format, not legal advice; have the SOW and its governing agreement reviewed by qualified counsel. Template licence: MIT.

Plantillas relacionadas