Statement of Work (SOW) Template (Free, Word)

About this template: This statement of work (SOW) is for a
technology or professional services engagement, such as a software
implementation, IT services or consulting. It is designed to sit under a
master services agreement (MSA) or a similar contract between the
parties. Legal terms such as liability, indemnities, intellectual
property, confidentiality, warranties, governing law and dispute
resolution belong in that agreement, not in this SOW. Text in [square
brackets] is for you to fill in, and the example entries show the level
of detail to aim for. Instructions in italics are for the people
drafting the SOW: delete them before you send it. Have your legal
counsel review the completed SOW and the master agreement together
before anyone signs.

1. Parties and background

1.1 Parties

1.2 Relationship to the
master agreement

This SOW is issued under the [Master Services Agreement] dated [date]
between [Customer legal name] (“Customer”) and [Vendor legal name]
(“Vendor”) (the “Agreement”). The terms of the Agreement apply to this
SOW. Capitalized terms that are not defined here have the meanings given
in the Agreement.

If this SOW conflicts with the Agreement, [the Agreement controls,
unless this SOW expressly states that a named provision of the Agreement
is changed for this SOW only].

Check whether the Agreement already says which document controls
when they conflict, and have counsel confirm this wording. If there is
no master agreement, ask counsel how the legal terms will be covered
before you use this SOW.

1.3 Background

[Describe the Customer’s situation in two or three short paragraphs:
the business, the problem this project solves, the systems involved
today and why the work is happening now.]

Example: Customer’s sales teams track accounts in spreadsheets
and a legacy contact database that does not connect to the ERP. Customer
selected [product] through a competitive RFP issued on [date] and
subscribes to it under a separate subscription agreement. This SOW
covers Vendor’s implementation services.

1.4 Documents referenced

Decide with counsel whether these documents form part of the
contract, and say so here. If a commitment in the proposal matters to
you, write it into this SOW.

2. Objectives

List the business outcomes the project supports. Objectives
explain why the work matters. They are not acceptance criteria unless
Section 8 says so.

3. Scope of work

3.1 In scope

Vendor will perform the following services (the “Services”).

Organize the scope by workstream. Be specific about quantities:
the number of workshops, integrations, data objects, environments,
reports and training sessions.

1. Project management. [Plan, manage and report on the
   project under Section 10.]
2. Discovery and design. [Run up to [number]
   requirements workshops and produce a solution design document covering
   configuration, integrations, data mapping and security roles.]
3. Configuration. [Configure [product] for [number]
   business units and the processes listed in the approved solution
   design.]
4. Integrations. [Build and test [number]
   integrations: [list each one, e.g. ERP customer and order sync, email
   and calendar sync, single sign-on with [identity provider]].]
5. Data migration. [Migrate the data objects listed in
   Section 3.2 from [source systems], including up to [number] trial loads
   and one production load.]
6. Testing. [Run system and integration testing, and
   support Customer’s user acceptance testing (UAT) under Section 8.]
7. Training. [Deliver [number] train-the-trainer
   sessions and [number] administrator sessions, with editable training
   materials.]
8. Cutover and go-live. [Plan and run the cutover, and
   support go-live.]
9. Post-go-live support (hypercare). [Provide [number]
   weeks of support after go-live, with the service levels in Section
   11.]
10. Knowledge transfer. [Hand over configuration,
    integration and administration documentation to Customer’s support
    team.]

3.2 Environment and volumes

Record the figures the Vendor priced against. If an actual figure
turns out to be significantly different, either party can raise a change
request under Section 9.

3.3 Out of scope

The following are not part of this SOW. Any of them can be added
through change control under Section 9.

• [Example: Software subscriptions and licenses, which are covered by
  [the subscription agreement or order form]]
• [Example: Changes to the ERP system itself, other than enabling the
  agreed integration interfaces]
• [Example: Cleansing or de-duplicating source data, which Customer
  will do before each load]
• [Example: Integrations other than those listed in Section 3.1]
• [Example: End-user training beyond the sessions listed in Section
  3.1]
• [Example: Support after the hypercare period ends]
• [Item]

4. Deliverables

List everything Vendor will hand over. Every deliverable that
triggers a payment needs acceptance criteria in Section 8.

5. Milestones and schedule

The timings below are an example schedule for a mid-sized
implementation, counted in weeks from kickoff. Replace them with the
dates in your agreed project plan.

The target dates assume that Customer meets its responsibilities in
Section 6 and that the dependencies in Section 7 are met on time. If
either party expects a milestone to slip, it will tell the other party’s
project manager in writing within [number] business days of becoming
aware of it, with a proposed recovery plan. Date changes that affect
scope or price go through change control under Section 9.

6. Roles and responsibilities

6.1 Vendor responsibilities

Vendor will:

• Provide qualified personnel, including the key personnel named in
  Section 14.
• [Configure, build, test and document the solution as described in
  Sections 3 and 4.]
• Tell Customer promptly about risks and issues that could affect the
  schedule, price or quality.
• Follow the Customer policies listed in Section 16 when working on
  Customer systems or premises.
• [Other responsibilities]

6.2 Customer responsibilities

Customer will:

• Name a project manager with authority to make day-to-day decisions,
  and a sponsor for escalations.
• Make subject matter experts available for workshops, design reviews
  and testing, for about [number] hours per week during [phases].
• Provide access to systems, environments and documentation, and
  on-site facilities under Section 15.
• Extract and cleanse source data and supply it in the agreed format
  by the dates in the project plan.
• Write UAT scripts with Vendor’s support, provide testers and
  complete UAT within the agreed window.
• Review deliverables and make decisions within the time limits in
  Sections 8 and 9.
• Manage Customer’s other suppliers this project depends on, such as
  [ERP support provider].
• [Other responsibilities]

6.3 RACI matrix

R = responsible (does the work), A = accountable (owns the
outcome and makes the final call), C = consulted, I = informed. Give
each activity exactly one A. The allocation below is an example starting
point: change it to fit your engagement.

7. Assumptions and
dependencies

7.1 Assumptions

The price and schedule in this SOW are based on the assumptions
below. If an assumption proves wrong, either party may raise a change
request under Section 9.

• [Example: Customer will supply source data extracts in [CSV] format,
  one file per object.]
• [Example: No more than [number] trial data loads will be needed
  before the production load.]
• [Example: The ERP exposes the APIs needed for the integrations in
  Section 3.1, and Customer’s ERP support provider will make any interface
  changes.]
• [Example: Standard [product] functionality meets the requirements,
  with no custom code beyond [describe].]
• [Example: Customer will answer design questions within [number]
  business days.]
• [Assumption]

7.2 Dependencies

The owner of a dependency will tell the other party as soon as it
knows the dependency will be late. Where a late dependency affects the
schedule, scope or price, the parties will handle it through change
control under Section 9.

8. Acceptance criteria and
sign-off

8.1 Acceptance criteria

Write criteria that someone outside the project could test and
reach the same answer. Name the test, the data, the environment and the
pass mark.

8.2 Acceptance process

1. Vendor submits each deliverable to Customer’s project manager in
   writing and states that it is ready for acceptance review.
2. Customer reviews or tests the deliverable within [number] business
   days (the “review period”).
3. Customer either accepts the deliverable in writing, for example with
   the certificate in Appendix B, or rejects it in writing and lists each
   failure against the acceptance criteria.
4. Vendor corrects the failures and resubmits the deliverable within
   [number] business days, at no extra charge.
5. Customer re-tests the corrected items, and anything the corrections
   affect, within [number] business days.
6. If a deliverable still fails after [number] rounds, either party may
   escalate under Section 10.4. [Customer’s other remedies are set out in
   the Agreement.]

Deemed acceptance: [Option A: If Customer neither accepts nor rejects
a deliverable within the review period, Vendor may send a reminder. If
Customer does not respond within [number] business days of the reminder,
the deliverable is treated as accepted.] [Option B: A deliverable is
accepted only when Customer accepts it in writing.]

Use in production: Customer’s use of a deliverable in production
[does / does not] by itself count as acceptance.

Choose the options that fit, delete the others, and have counsel
review them. If you agree to Option A, make sure the review periods are
realistic for your team.

8.3 Defect severity levels

8.4 Final acceptance

Final acceptance occurs when [all deliverables in Section 4 have been
accepted, the hypercare period has ended and no Severity 1 or 2 defects
are open]. [Any amounts held back under Section 12.1 become payable on
final acceptance.]

9. Change control

A change to the scope, deliverables, schedule, price or key personnel
takes effect only when both parties sign a change order. Vendor will not
start work on a change before the change order is signed.

1. Either party may request a change by sending a change request
   (Appendix A) to the other party’s project manager.
2. Vendor assesses the effect on scope, schedule, price, resources and
   risk, and replies within [number] business days. [If an assessment will
   take more than [number] hours, Vendor will say so first, and the time is
   chargeable only if Customer approves it in advance.]
3. Customer approves, rejects or asks questions within [number]
   business days.
4. Approved changes are recorded in a change order signed by the people
   authorized in the table below.
5. Vendor keeps a change log showing every request, its status and its
   effect on price and schedule, and includes the log in each status
   report.

10. Project governance and
reporting

10.1 Project managers

Each party’s project manager, named in Section 1.1, is the day-to-day
contact for this SOW.

10.2 Meetings

10.3 Status reports

Vendor will send a written status report [weekly] covering:

• Progress against the plan and milestones
• Work planned for the next period
• The RAID log, with an owner and due date for each item
• Decisions needed from Customer, and the date each is needed by
• The change log
• Defect counts by severity, during testing
• [For time-and-materials work: hours used by role against the
  estimate and the not-to-exceed amount]

10.4 Escalation

11. Service levels

Use this section if the SOW includes hypercare, managed services
or ongoing support. Delete it for project-only work. Put service credits
and other remedies in the Agreement or a separate service level
agreement, and refer to them here.

11.1 Support hours and
channels

• Support hours: [e.g. 8:00 to 18:00 [time zone], Monday to Friday].
  Severity 1 coverage: [24×7 / support hours only].
• How to raise a ticket: [support portal, email, phone for Severity
  1]

11.2 Response and
resolution targets

Severity levels are as defined in Section 8.3.

11.3 Reporting and remedies

Vendor will report performance against these targets [monthly].
[Remedies for missed targets, such as service credits, are set out in
[the Agreement / the service level agreement dated [date]].]

12. Pricing

Choose Option A or Option B, or combine them, for example time
and materials for a discovery phase and a fixed fee for the build.
Delete what you don’t use. Software subscription or license fees are not
part of this SOW unless you add them here.

12.1 Option A: Fixed fee

The fixed fee for the Services is [currency and amount], excluding
taxes. It covers all work needed to complete the scope in Section 3 and
the deliverables in Section 4. Vendor will invoice the fixed fee in
installments as each payment milestone is accepted.

The percentages below are an example split. Agree your
own.

[Optional holdback: Customer will hold back [number]% of each
milestone payment and pay the held-back amounts on final
acceptance.]

12.2 Option B: Time and
materials

Vendor will charge for time worked at the rates below. The rates are
fixed for [the term of this SOW / [number] months].

• Not-to-exceed amount: Charges for time under this SOW will not
  exceed [amount] without a signed change order.
• Early warning: Vendor will notify Customer in writing when charges
  reach [number]% of the not-to-exceed amount, with a forecast of the cost
  to complete.
• Timesheets: Vendor personnel record time [daily] against tasks in
  [system]. Customer’s project manager approves timesheets [weekly], and
  only approved time is billable.
• Billing units: [A day is [number] hours. Partial days are billed in
  [increment].]
• Travel time: [Not billable / Billable at [number]% of the
  rate].

12.3 Expenses

[Option 1: All expenses are included in the fees.]

[Option 2: Customer will reimburse reasonable travel and other
expenses that are approved in writing in advance, incurred under
Customer’s travel policy [reference], and billed at cost with receipts,
up to [amount] in total.]

12.4 Taxes

Taxes are handled as set out in the Agreement.

13. Invoicing and payment

• Invoice timing: [On acceptance of each payment milestone (Option A)]
  [Monthly in arrears for approved time and expenses (Option B)]
• Each invoice shows: the SOW number, Customer’s purchase order
  number, the milestone or period covered, approved hours by person and
  role (Option B), itemized expenses with receipts, and taxes.
• Send invoices to: [accounts payable email address or supplier
  portal]
• Payment terms: [As set out in the Agreement / Net [number] days from
  receipt of a correct invoice]
• Disputed items: Customer will tell Vendor about any disputed item
  within [number] business days of receiving the invoice. [Undisputed
  amounts are paid on the normal terms.] Disputes are handled under the
  Agreement.

14. Key personnel

• Vendor will not remove or replace key personnel without [number]
  days’ written notice to Customer, except for reasons outside Vendor’s
  control, such as illness or the person leaving Vendor.
• Replacements will have equal or better skills and experience, and
  Customer may interview them before they start.
• Vendor will provide a handover period for any replacement [at no
  charge].
• Customer may ask Vendor to replace a team member for reasonable
  cause, and Vendor will do so within [number] business days.
• [Background checks, security clearances or onboarding steps required
  for Vendor personnel: [describe, or refer to the Customer policy]]

15. Location and travel

• Work location: [Remote / Customer’s offices at [address] / Vendor’s
  offices / a mix, as described below]
• On-site activities: [e.g. design workshops in weeks [number] to
  [number], go-live support in week [number]]
• Working hours and time zone: [hours, time zone]. [Work outside these
  hours, such as a weekend cutover, is [included in the fees / charged at
  [rate]].]
• On-site facilities Customer will provide: [desks, network access,
  building passes]
• Offshore or nearshore resources: [Permitted / Not permitted /
  Permitted for [tasks] only, with Customer’s written approval]
• Travel and expenses: see Section 12.3.

16. Security and data
handling

The Agreement and any data processing agreement set the legal
obligations for data protection. Use this section for the practical
rules on this project, and have your security and privacy teams review
it.

• Customer data in scope: [categories, e.g. customer contact details,
  order history, employee names. Note any personal data, payment card
  data, health data or other regulated data.]
• Documents that apply: [the Agreement, the data processing agreement
  dated [date], Customer’s information security policy, acceptable use
  policy]
• Access: Vendor personnel will use only accounts issued by Customer,
  protected by multi-factor authentication, with the least access needed
  for their tasks. Customer will remove accounts when a person leaves the
  project.
• Data location: Customer data will be stored and processed only in
  [countries or regions], and only in systems Customer has approved.
  [Vendor will not copy Customer data to its own systems or devices
  without Customer’s written approval.]
• Production data in test and development environments: [Not permitted
  / Permitted only if masked or anonymized / Permitted with Customer’s
  written approval]
• Subcontractors: Vendor will not give subcontractors access to
  Customer data or systems without Customer’s written approval in
  advance.
• AI tools: Vendor personnel [may not / may, with Customer’s written
  approval,] enter Customer data into generative AI tools.
• Security incidents: Vendor will report any actual or suspected
  security incident affecting Customer data or systems to [contact] within
  [time], and as the Agreement requires.
• End of the engagement: Vendor will return or delete Customer data as
  Customer directs and confirm deletion in writing within [number]
  days.

17. Term and termination

Termination rights, payment on termination and the effects of
termination are legal terms. Keep them in the Agreement, use this
section to point to them and list the practical steps, and have counsel
review any SOW-specific additions.

• Term: This SOW starts on [start date] and ends on [end date] or on
  final acceptance under Section 8.4, whichever is [later], unless it ends
  earlier under the Agreement.
• Termination: This SOW may be terminated as set out in [section
  reference] of the Agreement. [Any SOW-specific termination right agreed
  with counsel.]
• On termination, Vendor will: [stop work as Customer directs; deliver
  all completed and in-progress work product; return or delete Customer
  data under Section 16; provide reasonable transition assistance [at the
  rates in Section 12.2]].
• Payment on termination: [As set out in the Agreement / Customer pays
  for accepted deliverables and approved time up to the termination
  date].
• Effect on other documents: [Ending this SOW does not end the
  Agreement or any other SOW issued under it.]

18. Signatures

By signing below, each party agrees to this SOW under the terms of
the Agreement.

Confirm that each person signing has authority to do so under
their organization’s approval rules.

Appendix A: Change request
form

Appendix B: Acceptance
certificate