You have reached the deliverables section of your Statement of Work, and this is the part that decides whether "done" is something you can prove or something you have to argue about later.
This guide walks you through what the section does, how to tell a deliverable apart from an activity and a milestone, what every entry should specify, and a fillable example you can copy. If you want to skip ahead and grab the example, jump to the fillable table below.
Key takeaways
- A deliverable is an output the client can review and accept, while activities are the work performed and milestones are the dates that mark progress.
- Every deliverable should clearly state its name, format, quantity, due reference, and acceptance criteria.
- Scope creep and disputes over payment are often come from poorly stated deliverables.
- CreateMySOW helps you build a complete Statement of Work, including a clear deliverables section with defined outputs, acceptance criteria, and payment-linked milestones
What the deliverables section does in a SOW
A deliverable is a noun the client can inspect, e.g., a report, a build, a file. Don't confuse it with the activity that produced it.
The deliverables section is the list of acceptance-ready outputs you owe the client. It is the inventory of what they actually receive at the end of the engagement, written so that each item can be checked off rather than debated.
It is the first thing most clients turn to and the part they push back on hardest. When you know what a Statement of Work is, the deliverables section is its payload — everything else (scope, schedule, payment) exists to define, time, and pay for these outputs.
A precise list does not remove the chance of disagreement, but it reduces the risk of one. The clearer each output and its acceptance criteria, the less room there is for "that is not what I thought I was getting."
Deliverable vs activity vs milestone
Most drafting errors start here, because readers conflate three different things. Here is the distinction in one place.
| Term | What it is | Example |
|---|---|---|
Deliverable | An output the client receives and inspects | A 5-page responsive website, delivered as a staging URL |
Activity | The work that produces the output | Designing, coding, and testing the site |
Milestone | A date that marks progress or completion | "Staging site ready by week 6" |
A deliverable is the thing. An activity is how you make the thing. A milestone is when the thing is due.
The deliverables section lists outputs, not tasks and not dates. That said, the three connect: activities produce deliverables, and milestones tell you when each deliverable is expected. List the outputs here and let the schedule handle the dates — just do not blur a verb ("design the site") into the deliverable column, or you have described work instead of a result.
What every deliverable entry should specify
A complete entry answers five questions.
- Name. What is the output, stated as a noun? A responsive marketing website.
- Format. How does it arrive — a PDF, a staging URL, a Figma file, a live build? Delivered as a staging URL plus exported source files.
- Quantity. How many, and how big? 5 pages, with up to 2 rounds of revisions.
- Due reference. Which milestone does it tie to? Due at the "design complete" milestone, week 6.
- Acceptance criteria. How does the client confirm it is acceptable? Accepted when all 5 pages render correctly on current mobile and desktop browsers.
Put together, those five turn a fuzzy promise into a checkable item: a 5-page responsive WordPress site, delivered as a staging URL with exported source files, up to 2 revision rounds, due at the week-6 design milestone, accepted when every page renders on mobile and desktop.
The fifth question is the load-bearing one. Each deliverable needs its own acceptance criteria section to be enforceable — without it, "done" is whatever the client decides it means on the day.
How to write deliverables step by step
Writing this section is mechanical once you have the scope nailed down. Work through it in order.
- Derive each deliverable from the scope statement. Read the scope statement and pull out every concrete output it implies. If scope says "redesign the marketing site," the deliverable is the redesigned site, not the redesigning.
- Write each one as a noun. Name the output, not the effort. "A migrated CRM dataset," not "migrate the CRM."
- Attach acceptance criteria to every entry. State exactly how the client confirms each output is complete. This is what makes the line enforceable.
- Sequence by dependency. Order the list so outputs that depend on earlier ones come later — a deliverable that needs sign-off before it can start should say so.
- Check each deliverable maps to a payment trigger. Every output should tie to something in the payment schedule, so that accepting a deliverable releases the matching payment.
If a deliverable cannot be traced back to scope or forward to a payment trigger, it usually does not belong in the section.
A fillable deliverables example you can copy
| Deliverable | Format | Quantity | Acceptance |
|---|---|---|---|
Responsive marketing website | Staging URL + exported source files | 5 pages, up to 2 revision rounds | All pages render on current mobile and desktop browsers; forms submit successfully |
Brand style guide | 1 document, 8-12 pages | Covers logo usage, color palette, and typography; approved in writing by the client | |
Analytics setup | Live configuration + handoff doc | 1 setup, 3 tracked goals | Tag fires on all goal events, verified in a test session |
Two quick notes. The Acceptance column is the one that stops arguments — write it as something testable, not "looks good." And this is a starting point, not a finished SOW: when you are ready, build the whole SOW with the generator and fill in your real rows.
Common mistakes in the deliverables section
Most disputes trace back to one of these. Scan your draft for them before you send.
- Vagueness. "A website" tells the client nothing about what they are accepting.
- Listing activities instead of outputs. "Design work" is effort. Name the thing the work produces.
- Missing acceptance criteria. Without a test for "done," every handoff is a negotiation.
- No format or quantity. "A report" leaves open whether that is a one-page summary or a 40-page audit.
- Not stating the number of revisions. Unbounded revisions are the fastest route to unpaid rework. Cap them explicitly.
- Deliverables that do not map to a payment trigger. If accepting an output does not release a payment, your schedule and your scope have drifted apart.
Why vague deliverables cause disputes
Imprecise outputs are a leading scope-creep vector: when nobody can point to a line that says what "done" means, the work tends to expand to fill whatever the client imagined.
The scale of the problem is well documented. PMI's 2018 Pulse of the Profession found that 52% of all projects face scope creep. A precise deliverables list does not prevent that on its own, but it gives both sides a fixed reference when expectations start to drift.
When a change does arrive, handle it through a change order rather than absorbing it silently, so the new work is priced and agreed rather than assumed
How deliverables connect to the rest of your SOW
The deliverables section does not stand alone. Deliverables flow from the scope statement, are verified by their acceptance criteria, and gate the payment schedule — accepting an output is what releases its payment. Read in that order, the SOW reads as one chain: scope defines, deliverables list, acceptance verifies, payment follows.
Once your SOW is drafted, send it for signature and track approvals in PandaDoc. The finished document goes out for signature and approval tracking there, so the version everyone signed is the version everyone agreed to.
Deliverables-level disputes are usually commercial, not legal — but if a clause raises a question about liability or enforceability, consult a qualified attorney before you sign. When you are ready to draft, CreateMySOW walks you through every section, including this one.
