Turn a fuzzy engagement into a clear, agreed plan
A Statement of Work is what separates a professional engagement from a misunderstanding waiting to happen. It pins down the scope, the exact deliverables, the timeline, who pays what and when, the assumptions everyone is relying on, and how changes get handled. This builder walks you through each section and assembles a complete, well-structured SOW you can copy or print and attach to your agreement.
How it works
The tool collects the standard sections of a SOW and renders them in a conventional order:
- Background — the context and objective of the project.
- Scope — what is included, plus an explicit out-of-scope list.
- Deliverables — the concrete outputs the client receives.
- Milestones — each with a target date, building the timeline.
- Payment schedule — amounts tied to milestones or percentages.
- Assumptions — the conditions the plan depends on.
- Change-order process — how additional work is requested, priced, and approved.
Each list (deliverables, milestones, payments) is editable, and the milestone dates form the project timeline. Everything is concatenated into one clean document.
What makes a good SOW — section by section
Background and objective: One or two sentences explaining why the project exists and what success looks like for the client. This grounds every other section and provides the “north star” if disputes arise later.
Scope vs out-of-scope: This is the most consequential section. In-scope items define what you are building; out-of-scope items define what you are not. A common mistake is writing a long in-scope list but leaving out-of-scope blank, which means every ambiguity defaults to “included.” Write “the following are specifically not included” and list anything the client has mentioned that is outside this engagement.
Deliverables: Be specific and measurable. Compare these two framings:
- Vague: “A website.”
- Specific: “Responsive marketing site, 6 pages (Home, About, Services, Blog, Contact, Privacy Policy), deployed to a production URL the client controls, passing Lighthouse performance score above 80.”
The second leaves no room for “I thought it would include X.”
Milestones and acceptance: Each milestone should have a target date and an acceptance condition — what does the client check, and how long do they have to respond? A common pattern is a 5-business-day review window after delivery, after which the deliverable is deemed accepted. Silence cannot mean rejection.
Payment schedule: Tie payments to accepted deliverables, not to calendar dates. A retainer-style fixed monthly fee is easier administratively but removes your leverage if scope creep occurs. Milestone-based payments keep both parties accountable.
Assumptions: List everything the plan depends on that is outside your control — client provides copy by date X, API credentials delivered before kick-off, no more than one round of revisions per deliverable. Assumptions become your protection when a missed dependency delays the project.
Change-order process: Keep it simple: any change is requested in writing, you estimate effort and cost within three business days, and work only starts after written approval. The key word is “written” — verbal approvals are unenforceable.
Tips for using the output
Copy the generated SOW into your master services agreement as a schedule or annex. If you work under a client’s paper rather than your own, extract the key terms and negotiate them into the client’s form. Have both parties sign before any work starts — an unsigned SOW is a draft, not a contract.