How agencies prove what was actually in scope

A statement of work describes the engagement at a high level: what will be built, the rough timeline, the commercial terms. It does not describe what was in this specific release, what was deliberately excluded, or what was accepted as a known limitation. By the time release three ships, the SOW is twelve pages of language that doesn't map to anything concrete on the staging site.

Clients don't dispute the SOW. They dispute the release. So the evidence has to live at the release level, not the contract level.

Each release should produce one structured document with five fields. The fields don't change between releases; only the contents do.

• Included scope: per platform, per area, per module. Specific to this release.
• Excluded scope: items the client asked for that were not built in this release. With reason.
• Known limitations: things that ship working but with caveats (e.g., iOS only, English only).
• Accepted risks: items knowingly shipped with risk, owned by a named decision owner.
• Sign-off: name, role, timestamp, on the client side and your side.

When the client comes back in three weeks asking why feature X isn't behaving as expected, you open release 4's record and either see "feature X excluded, deferred to release 5" or "feature X included, signed off by Sarah on April 18". The conversation ends there.

The biggest mistake agencies make is keeping the delivery record internal. A document the client never saw isn't proof; it's a self-serving log. The record needs to land in the client's inbox on release day, with the same attribution and timestamp the internal version has.

Some teams use a shared Notion page. Some use a PDF export. Some use a structured tool like Dockbase that produces a portable, signed record automatically. The format matters less than the discipline of sending it on the day of release, not the day of dispute.