Statement of Work: What Belongs In One and What Goes Wrong Without It

A statement of work answers four questions about one specific engagement: what will be delivered, by when, for how much, and how both sides will know it is finished. Everything else in the document exists to protect those four answers from ambiguity.

It normally sits underneath a master service agreement, which handles the legal framework. That division is deliberate. The legal terms rarely change between engagements, while scope and price change every time, so separating them means only the second document needs negotiating for a second project.

Scope

Describe what will be done, and then describe what will not. Exclusions feel unnecessary while drafting and are the most valuable sentences in the document later, because they convert a disagreement about interpretation into an ordinary change request with a price attached. The test of a scope section is whether a reasonable person outside the project could read it and say what is and is not included.

Deliverables

Name countable things rather than activities. Configuration support is an activity that can continue indefinitely; a configured pipeline with six named stages is a deliverable that can be handed over. Every deliverable should have an acceptance criterion attached and, ideally, a payment milestone.

Acceptance criteria

This is where most engagements are won or lost. A criterion should be a test an observer could apply. Compare two versions of the same requirement. The weak one: the data migration will be completed to the client's satisfaction. The strong one: all contact records from the source export are present in the new system, verified by a total count match and a field-level comparison on a random sample of 200 records, with discrepancies below one per cent. The second can be settled with evidence; the first can be argued forever.

Assumptions and buyer obligations

Every estimate rests on assumptions, and writing them down is how you keep the right to raise a change when one fails. Typical entries include the format and quality of data to be supplied, availability of a named person for a stated number of hours, access to systems by a stated date, and the number of review cycles included. Most engagement delays begin on the buyer side, and an obligation that was never written cannot be pointed at when the schedule slips.

Change control

Define how a change is raised, who assesses its effect on price and timeline, and who may approve it. Without this, additional requests are absorbed informally by whoever wants to be helpful, and the engagement drifts past its budget in increments too small to object to individually.

The choice should follow from who can actually control the uncertainty. Asking a supplier for a fixed price on work whose shape depends entirely on the buyer's data quality transfers a risk the supplier cannot manage, and it is paid for in the price whether or not the risk materialises.

Deliverable three: a configured sales pipeline. Acceptance criteria: the pipeline contains the six stages listed in appendix A with the exit criteria stated there; three named users can move an opportunity through all six stages without administrator assistance; and a stage change generates the follow-up task described in appendix B. Acceptance to be confirmed in writing by the named approver within five working days of notification, and deemed accepted if no written objection is received within that period.

The final sentence is worth including. Deemed acceptance after a stated period prevents the common situation where a deliverable is finished, nobody objects to it, and it remains formally unaccepted and unpaid because the approver is busy.

A statement of work is a working document rather than a filing requirement. Milestone dates, acceptance status per deliverable and approved changes should be visible to the person who owns the commercial relationship, not only to the delivery team. Engagements that go wrong commercially usually went wrong operationally several weeks earlier, and the gap between those two moments is the window in which somebody could have acted.

A master service agreement provides the legal framework this document sits within. An order form performs a comparable role for product purchases rather than project work. A purchase order is the buyer's internal authorisation to spend, which may reference the statement of work but is not the same instrument. A change order or change request is the amendment mechanism defined by the change control section. Nothing here is legal advice, and a substantial engagement deserves review by someone qualified to give it.

Related pages on buying, onboarding and running a CRM engagement:book a demo, pricing, features overview, what a CRM is, use cases, and switching from Zoho.