Statement of Work (SOW)

What Is a Statement of Work?

A Statement of Work, almost always abbreviated SOW, is the project-level contract that turns a long-term services relationship into a concrete piece of work. It defines exactly what the customer is buying on a given engagement: the scope of services, the deliverables, the milestones, the acceptance criteria, the fees, and the timeline. The SOW is the operational half of a layered contract architecture in which the Master Service Agreement supplies the standing legal terms and each SOW supplies the project-specific terms.

The SOW is the document a delivery team actually reads. It is what disputes get measured against when the customer says “this is not what we paid for” or the contractor says “this is out of scope.” A well-drafted SOW removes that ambiguity before work begins.

Structure of a Strong SOW

A market-standard SOW for a US contractor engagement typically contains the following sections.

Scope of services. A precise narrative of what work will be performed. This section answers the question “what is the contractor actually doing?” Avoid open-ended language. “Build a customer onboarding flow including five wireframes, two design rounds, and a working prototype in Figma” is enforceable. “Provide design services as reasonably requested” is not.

Deliverables. A discrete, numbered list of artefacts that will be handed over. Each deliverable should have a name, a format, and a rough description. Deliverables anchor acceptance and payment.

Milestones and schedule. Dates by which each deliverable is due. Strong SOWs tie payment to milestone acceptance rather than calendar time, so the contractor is paid for work the customer has accepted.

Acceptance criteria. Objective tests that the deliverable must pass before the customer is required to accept it. Acceptance criteria convert subjective opinion (“I do not like it”) into measurable conditions (“it must pass these eight functional tests”). An SOW without acceptance criteria leaves both sides exposed.

Fees and payment schedule. Fixed price, time and materials, milestone-linked, or a hybrid. The payment schedule should specify the trigger (milestone acceptance, invoice date, calendar date), the amount, and the payment method.

Assumptions and dependencies. The customer-side inputs the contractor is relying on (test data, API access, design assets, decisions). If the customer misses an assumption, the schedule shifts and the contractor is not at fault.

Change control. A short clause explaining that scope changes are documented in a written change order signed by both sides, with the fee and schedule impact stated. This is the single most overlooked clause and the most common source of disputes.

Key personnel. If the customer is buying access to specific named individuals (a senior architect, a particular designer), the SOW should list them and specify the consequences of substitution.

How the SOW Sits Under an MSA

In the standard two-document structure, the MSA covers terms that should not change between projects: IP ownership, confidentiality, indemnification, limitation of liability, governing law, dispute resolution, term and termination, audit rights. The SOW covers terms that do change project by project: scope, deliverables, fees, schedule, key personnel.

The MSA typically contains an “order of precedence” clause stating that if any SOW term conflicts with the MSA, the MSA controls unless the SOW explicitly references and overrides a specific MSA section. This prevents accidental erosion of core legal protections through routine project paperwork. Some sophisticated buyers reverse this default for commercial terms (the SOW controls fees) while keeping the MSA on legal terms (the MSA controls indemnity).

A single MSA can support dozens of SOWs across a multi-year relationship. Each SOW is a separate, signed amendment that incorporates the MSA by reference. Termination of one SOW does not terminate the MSA. Termination of the MSA terminates all open SOWs.

Common Drafting Failures

The most expensive SOW failures share a pattern: language that felt fine in negotiation but collapses under stress.

Vague scope. “All services reasonably required to launch the product” sounds reasonable until launch slips and each side blames the other. Always describe the work in concrete artefacts and behaviours.

Missing acceptance criteria. Without acceptance criteria, the customer can refuse to sign off indefinitely and the contractor cannot invoice. Or the customer must accept work they consider substandard because there is no objective failure standard.

No change control. Scope inevitably moves. Without a change-control clause, the contractor either absorbs the cost or fights for it after the fact. Either outcome damages the relationship.

Fixed price with no contingency for client delay. If the contractor commits to a fixed price contingent on the customer delivering inputs by certain dates, the SOW must say what happens when the customer misses. Usually the schedule extends and the contractor can re-price.

Fee total with no payment schedule. A $120,000 SOW with payment “on completion” is bad for both parties. The contractor carries 100% of cashflow risk. The customer has no incentive to attend interim reviews. Milestone-linked payments align incentives.

Where Omnivoo Helps

Omnivoo’s Contract Management workflow includes SOW templates with built-in scope, deliverables, milestones, acceptance, change control, and a default order-of-precedence clause to a parent MSA. The flow is location-agnostic so US companies can use the same SOW pattern with contractors in India, the UK, Singapore, or the EU while keeping payments, audit trail, and signatures in one place. Pair the SOW with our Master Service Agreement template for the recommended two-document structure.