Write a Statement of Work With Observable Acceptance Criteria

In short: For each paid deliverable, state what the provider will hand over, what conditions make it reviewable, who checks it, and how the parties handle corrections. A clear acceptance process makes delivery easier to evaluate without treating a campaign result outside the provider’s control as proof that the work itself was delivered.

An RFP helps a company compare possible providers. A statement of work (SOW) turns the selected approach into work the client and provider can review together. If a deliverable is described only as “improve paid search” or “support content,” both sides may believe the work is complete while expecting different outputs.

For the earlier decision about comparing agency proposals, see the agency RFP guide. This article focuses on defining and accepting agreed work after provider selection.

1. Describe a deliverable as a reviewable output

Give each deliverable a name, a brief description, a due date or milestone, and the format or location where it will be provided. Examples include a campaign structure and build sheet, a documented measurement plan, a set of approved landing-page drafts, or a monthly performance review with a stated analysis period.

Separate the output from its intended business effect. “Deliver a tracking plan that lists each agreed event, trigger, property, and test case” is reviewable. “Increase qualified pipeline” may be an important objective, but it depends on factors beyond the document or implementation itself. If performance outcomes matter, define them as a separate goal with assumptions and shared responsibilities.

U.S. federal acquisition guidance lists work description, delivery schedule, performance standards, and special requirements among the elements of a statement of work. A UK public-sector contract template separately records deliverables, acceptance criteria, milestone dates, and the person responsible for verification. These are useful examples of the information a client and provider can make explicit.

2. Turn expectations into observable acceptance criteria

For each deliverable, write criteria that a reviewer can check from the output. Useful questions include:

• Is the agreed file, implementation, or meeting output present and in the required format?
• Does it cover the agreed channels, audiences, pages, events, or reporting period?
• Are required sources, assumptions, definitions, and known limitations included?
• Does it pass the agreed functional or quality checks, such as working links, valid event names, or a documented test result?
• Does it match the version, brand, or account environment named in the SOW?

Avoid terms such as “high quality,” “strategic,” or “comprehensive” unless the SOW explains what the reviewer should look for. Keep criteria proportional to the fee and risk. A one-page diagnostic does not need the same acceptance procedure as a production website migration.

3. Assign review, timing, and correction steps

Name the client reviewer who can accept the deliverable and the provider contact who will respond to findings. Set a review period that matches the work and the client’s availability. Specify how the reviewer will report a mismatch, what evidence to include, and how the provider will correct in-scope issues.

Define how many review cycles are included, what counts as a correction to the agreed criteria, and what becomes a change request. If the client changes the goal, adds a channel, or supplies new requirements after work begins, record the resulting scope, timeline, and fee change before proceeding.

State what happens if the reviewer is unavailable or the client’s inputs are late. Do not assume silence means acceptance unless the parties have explicitly agreed to that process in the governing terms. A contract professional should review acceptance language, payment conditions, and dispute steps for the relevant jurisdiction and agreement.

4. Record dependencies and boundaries on both sides

List the access, data, approvals, subject-matter input, and internal decisions the provider needs. Assign an owner and due date to each client dependency. If a dependency is late, state how both sides will reset the schedule and what work can continue safely.

Write down exclusions and assumptions beside the deliverable they affect. For example, clarify whether copywriting, legal review, analytics implementation, media spend, or post-launch support is included. Boundaries help the team identify a real change in scope instead of hiding extra work inside a vague “support” line.

5. Link acceptance to evidence and the right decision

Keep a delivery record with the SOW version, submitted artifact or environment, review date, checked criteria, findings, corrections, approval, and any change request. Store the evidence where both parties can retrieve it. If one deliverable has several parts, track each part instead of relying on a general status such as “in progress.”

Review patterns across the engagement: first-pass acceptance, correction cycles, client-input delays, change requests, missed milestones, and time spent resolving unclear requirements. Repeated rework may signal that criteria were vague, assumptions changed, or the provider missed an agreed requirement. Use the evidence to improve the next SOW and the working relationship.

SOW acceptance worksheet

• Deliverable name and unique reference: ______
• Description, format, and delivery location: ______
• Due date or milestone: ______
• Observable acceptance criteria: ______
• Functional, content, or quality checks required: ______
• Evidence the provider will submit: ______
• Client reviewer authorized to accept: ______
• Review period and way to report a mismatch: ______
• Included correction cycles and response owner: ______
• Client inputs, access, and decision dates: ______
• Assumptions, exclusions, and out-of-scope requests: ______
• Change-request and schedule-reset process: ______
• Acceptance record location and approval evidence: ______

A useful SOW gives both sides the same view of the output, the review, and the next step if the result does not meet the agreed criteria. Keep acceptance tied to evidence of the work and review commercial or legal terms in the context of the full agreement.

If provider work is repeatedly disputed because “done” means something different to each side, request a marketing diagnostic to review scope, evidence, and acceptance ownership.

Request a marketing diagnostic

Sources and scope

• U.S. Acquisition.gov: FAR 8.405-2, Ordering procedures for services requiring a statement of work — lists work description, delivery schedule, performance standards, and special requirements as SOW elements in the U.S. federal acquisition context.
• UK Contracts Finder: Statement of Work template — provides a public-sector example that pairs deliverables with acceptance criteria, milestone dates, and a verification owner.

These procurement materials illustrate SOW structure; they are not universal contract terms. Acceptance, payment, remedies, and dispute procedures depend on the complete agreement and applicable law. Accessed October 8, 2026.