LibraryZenithRequest a breakdown
Client / Agency DocsStandardCommercial handoffAgency-ready

Documentation reference

Statement of Work

A Statement of Work protects both the client and delivery team. It translates discovery, BRD, PRD, design, and architecture decisions into deliverables, phases, responsibilities, timeline, assumptions, exclusions, and acceptance criteria.

Overview

What this document is

A Statement of Work protects both the client and delivery team. It translates discovery, BRD, PRD, design, and architecture decisions into deliverables, phases, responsibilities, timeline, assumptions, exclusions, and acceptance criteria.

SOWProposalAgencyScopeDeliverablesAcceptance

Fit signals

When to use it

  • A proposal needs to become a delivery agreement.
  • Scope, timeline, and responsibilities must be clear before kickoff.
  • Client expectations need acceptance criteria and exclusions.
  • The delivery team needs a practical contract-adjacent execution reference.

Audience and ownership

Who uses it

Agencies, consultants, founders, and client stakeholders agreeing on what will be delivered and how success will be accepted.

Agency ownerClient sponsorProject managerProduct leadLegal reviewer

Before and after

Where it fits in the build chain

Idea Brief
BRD
PRD
Research
IA
Design System
Architecture
SOW
QA Plan
Launch

Gather before writing

Inputs required

  • Deliverables table
  • Assumptions and exclusions checklist
  • Acceptance criteria block
  • Change request process

What each part should cover

Section-by-section guide

Objectives

Explain what decision this section helps the team make and how success will be recognized.

Deliverables

Describe the deliverables clearly enough that a founder, teammate, or AI agent can use it without needing hidden context.

Scope

Describe the scope clearly enough that a founder, teammate, or AI agent can use it without needing hidden context.

Timeline

Describe the timeline clearly enough that a founder, teammate, or AI agent can use it without needing hidden context.

Acceptance

Make the standard observable so the team can review, approve, or reject the output without guessing.

Change control

Describe the change control clearly enough that a founder, teammate, or AI agent can use it without needing hidden context.

Practical workflow

How to create and use it

  1. 01Translate approved PRD and architecture into delivery phases.
  2. 02Define deliverables, responsibilities, assumptions, and exclusions.
  3. 03Set acceptance criteria and change request process.
  4. 04Use the SOW for kickoff, delivery tracking, and closure.

Copy into your workspace

Starter template

  1. 01Summarize the objective and approved scope.
  2. 02List deliverables, milestones, assumptions, exclusions, and dependencies.
  3. 03Define acceptance criteria and communication cadence.
  4. 04Add change control, handoff, support, and closure rules.

Make the draft usable

Weak vs strong examples

Scope boundary

Weak

We will build the product.

Strong

Zenith will design and build the client onboarding MVP covering intake, file upload, approval dashboard, notifications, and admin settings. Billing and CRM migration are excluded.

Acceptance

Weak

Client approves when it looks good.

Strong

A deliverable is accepted when it matches approved designs, passes listed acceptance checks, has no P0/P1 defects, and is reviewed within the agreed feedback window.

How to know it is useful

Quality checklist

  1. 01Deliverables and exclusions are clear enough to prevent scope ambiguity.
  2. 02Dependencies and responsibilities are assigned.
  3. 03Each phase has acceptance criteria.
  4. 04Change control is explicit.

Before you hand it off

Document readiness checklist

  • The statement of work has a named owner and approval path.
  • The business or product decision this document supports is explicit.
  • Inputs, assumptions, and open questions are separated from confirmed facts.
  • Scope boundaries and non-goals are clear enough to prevent silent expansion.
  • The document can be handed to a teammate, agency, or AI agent without hidden context.
  • Deliverables and exclusions are clear enough to prevent scope ambiguity.
  • Dependencies and responsibilities are assigned.
  • Each phase has acceptance criteria.

Generate the first draft

AI prompt

Draft prompt

Create a Statement of Work from this PRD and proposal context. Include objectives, deliverables, scope inclusions, exclusions, assumptions, timeline, milestones, responsibilities, dependencies, acceptance criteria, change control, communication cadence, handoff, support, and closure terms.

Avoid these

Common mistakes

  • Writing vague deliverables like build app without boundaries.
  • No exclusions, assumptions, or dependency owner.
  • No acceptance criteria for subjective deliverables.
  • No change request process.

Use this after the draft

Handoff assets

  • Phase and deliverables list
  • Client and agency responsibilities
  • Acceptance criteria
  • Change control process

Suggested build path

What to create before and after

Before

Idea Brief

Keep this connected so the build stays traceable.

Current

Statement of Work

Use this page to create the working draft.

After

PRD

Keep this connected so the build stays traceable.

Zenith CTA

Need this shaped for your business?

Zenith can turn rough notes into a founder-ready statement of work.

Bring your idea, current docs, users, constraints, and open questions. We will help make the next decision clear.

Request a breakdown