A statement of work (SOW) is a document that sets out exactly what a vendor will do for a specific engagement: the tasks, the deliverables, who is responsible for what, the schedule, how the work will be accepted, and the price. In IT and telecom it is common for projects such as a network refresh, an office move, a migration or the onboarding of a managed service. A SOW is often signed under a master services agreement (MSA), which holds the legal terms, so that each new project only needs its own SOW.
At a glance
- A SOW describes one engagement’s work, deliverables, schedule, responsibilities, acceptance criteria and price.
- It usually sits under an MSA that supplies the legal terms, though a SOW can stand alone.
- Pricing may be fixed-fee, time-and-materials, or a recurring fee for an ongoing service.
- Assumptions, exclusions and a change-order process decide what counts as extra work.
- A vague SOW is a frequent source of cost overruns and disputes.
What problem it solves
IT projects and managed services fail on expectations more often than on technology. The buyer assumes the vendor will configure every site, migrate all users and train the help desk; the vendor priced for configuring a template and handing it over. Without a written scope, both sides remember the sales conversation differently.
A SOW fixes the expectations in writing before work starts. It names the deliverables, the boundaries of the work, the buyer’s own obligations (such as providing access, approvals or equipment), and how the parties will know the job is done. It also creates a known path for changes, so new requests are priced and approved rather than argued about at invoice time.
How it works
Structure. A typical SOW includes a background or objective, the scope of work, deliverables, a schedule with milestones, roles and responsibilities, assumptions and exclusions, acceptance criteria, pricing and payment terms, and a change-order process. Ongoing services often add service levels, reporting and a governance cadence.
Relationship to other documents. Under a master services agreement (MSA), the SOW references the MSA, and an order-of-precedence clause decides which document wins if they conflict. A service level agreement (SLA) may be attached to the SOW or to the MSA.
Pricing models. A fixed fee can shift the cost risk for the defined scope to the vendor, so the scope and assumptions tend to be tighter; the assumptions, exclusions, buyer dependencies and change-control terms decide who pays for overruns outside that scope. Time-and-materials SOWs bill for hours used, so the buyer carries more of the cost risk and should ask for estimates and caps. Managed services often combine a one-time onboarding fee with a monthly fee.
Acceptance. Good SOWs say how deliverables are tested and accepted, how long the buyer has to review them, and what happens if they fail. Payment milestones are often tied to acceptance.
Changes. A change-order process requires both parties to agree in writing on any change to scope, schedule or price before the work happens.
For examples of SOW-driven work, see our field support overview, which covers dispatched technicians for installs, moves and repairs.
When it matters for buyers
- Starting a project. Network refreshes, office moves and migrations should have a SOW that names every site and every deliverable.
- Onboarding a managed service. The SOW defines what the provider manages, what stays with your team and how handoffs work.
- Comparing proposals. Responses to a request for proposal (RFP) are easier to compare when each vendor’s SOW uses the same scope.
- When costs creep. Repeated change orders often trace back to assumptions and exclusions in the original SOW.
- At review time. A quarterly business review (QBR) is a natural point to check delivery against the SOW.
Questions to ask vendors
- What exactly is out of scope, and what assumptions is your price based on?
- What do you need from us, and what happens to the schedule and price if we’re late?
- How will each deliverable be accepted, and how long do we have to review it?
- What is the change-order process, and what rates apply to extra work?
- For time-and-materials work, can you give an estimate and a not-to-exceed cap?
- Who are the named roles on your side, and can they be replaced without notice?
How it differs from a service order
A service order buys a defined service, such as an internet circuit at a set speed, for a term and a recurring price. A SOW buys work: tasks and deliverables that someone has to perform, often once. The two can appear together, for example a service order for a managed network service plus a SOW for its onboarding, and some vendors use the names loosely, so judge the document by what it commits to rather than its title.