Generate a detailed Statement of Work free — deliverables, milestones, payment schedules, and acceptance criteria in a ready-to-use SOW document.
This tool builds a plain-text Statement of Work from a four-step form. You describe the project and the two parties, list deliverables with due dates and acceptance criteria, choose a payment structure, set change management and communication terms, and then copy or download a twelve-section document. It runs entirely in your browser: client names, rates and budget figures are never transmitted anywhere.
What it is not: legal advice, or a document ready to sign as it stands. A statement of work is a commercial contract, usually sitting under a master services agreement, and the version this generator produces should be reviewed by a qualified lawyer before either side executes it. The value of working through the form is that it forces the decisions — what is in scope, what is explicitly out, when payment is triggered, what "done" means — that cause almost all project disputes when they are left implicit.
| Step | What you enter | Where it lands in the document |
|---|---|---|
| 1. Project overview | Project name (required), client name and contact, provider name and contact, start and end dates, project description | Header, Parties block, section 1 |
| 2. Scope and deliverables | Any number of deliverables, each with name, description, due date and acceptance criteria; an out-of-scope statement | Sections 3, 4 and 5 |
| 3. Terms and conditions | Payment structure and figures, change management text, meeting frequency, primary contacts, assumptions | Sections 6 to 9 |
| 4. Review and export | Nothing — the assembled document is displayed | Copy, download .txt, or download PDF |
Blank fields become bracketed placeholders such as [Client Name] or [Amount], so a partially completed form still generates a readable draft with its gaps visible. Dates are rendered in long US format ("March 14, 2026"); an empty date field prints [Date].
Step 2 starts with one empty deliverable row and lets you add as many more as you need, or remove any of them. Each row has four fields, and all four are used twice in the output. First they are rendered as a fixed-width summary table with columns for number, deliverable, due date and acceptance criteria. Then every deliverable is repeated in full underneath, in a "Detailed Deliverable Descriptions" block that carries the untruncated description.
The summary table truncates: deliverable names are cut to 22 characters, dates to 14, and acceptance criteria to 29. Nothing is lost — the full text survives in the detail block below — but a deliverable called "Phase 2 Data Migration and Validation" will read as "Phase 2 Data Migratio" in the table. Short, distinct names in the name field and the real explanation in the description field produce a better-looking document.
The same deliverable list is reused a second time, in section 4, as the project milestone timeline: each deliverable name paired with its due date, bracketed by the project start and end dates. There is no separate milestone entry for schedule purposes, so a milestone that is not a deliverable — a design review, a client sign-off gate, an environment handover — has to be entered as a deliverable to appear on the timeline.
The acceptance criteria field is the one worth the most thought. Section 10 of the generated document defines a deliverable as accepted when it meets the criteria stated in section 3 and the client has given written acceptance — or when five business days have elapsed since delivery with no written rejection or request for revision. A rejected deliverable comes with a reasonable opportunity to cure.
That deemed-acceptance window is fixed at five business days in the template and cannot be changed on the form; if a different period is right for your engagement, edit it after export. Note also what it implies about the criteria themselves. Deemed acceptance only protects the provider if the criteria are objective enough to argue from. "Client is satisfied with the design" gives the client an indefinite veto. "Three homepage concepts delivered as Figma files at 1440px, each with mobile breakpoint" is testable. Write criteria you could adjudicate without either party in the room.
Two free-text fields do disproportionate work. The out-of-scope box populates section 5, followed by a fixed sentence stating that anything outside the defined scope requires a separate SOW or a change order. The assumptions box populates section 9, followed by a fixed sentence requiring the provider to notify the client promptly if an assumption proves wrong, and noting that scope, timeline or budget may then need adjusting through the change process.
Neither field is required, and both default to a bracketed placeholder. Leaving them empty is the most common way this document gets weak. Useful things to put in them:
Section 6 is generated differently depending on which structure you pick, and the form's own fields change with it.
| Structure | Fields shown | What section 6 says |
|---|---|---|
| Fixed price | Total budget, payment schedule (free text) | States the total cost and reproduces your schedule text verbatim |
| Time and materials | Hourly rate, estimated budget, invoicing frequency | States the rate, treats the budget as a not-to-exceed figure absent written approval, requires detailed time records, sets payment due 30 days from invoice |
| Milestone-based | Total budget, plus a repeatable list of milestone names and amounts | Lists each milestone with its amount; each payment falls due 30 days after written client acceptance |
Fixed price is the only option where the payment schedule is entirely yours to write — the field's own prompt suggests a split such as 50% on signing, 25% at midpoint, 25% on completion, but nothing is imposed. Under time and materials the invoicing cadence you type is substituted into a sentence that otherwise defaults to monthly. Under milestone-based billing the milestone list is separate from the deliverable list, so a milestone payment named "Design approval" does not automatically correspond to a deliverable of that name; keeping the two lists aligned is on you, and mismatches between them are a frequent source of invoicing arguments.
All monetary fields are plain text. Type the currency symbol you mean — nothing is validated, formatted or converted, and no totals are calculated. In particular, the milestone amounts are not summed and not checked against the total budget, so a milestone schedule that adds up to the wrong number will generate without complaint. Add them up yourself before sending.
Section 7 is pre-filled with editable default text: changes must be submitted in writing on a change request form, are evaluated for impact on scope, timeline and budget, and take effect only when a written change order is signed by authorised representatives of both parties, with the provider reserving the right to adjust timeline and budget for approved changes. You can rewrite that box entirely.
Two things the default does not do, which experienced buyers will ask about: it sets no response time for evaluating a request, and it names no threshold below which a change is absorbed without paperwork. Adding both makes the clause more usable in practice than the boilerplate version.
Section 8 records a meeting frequency chosen from five options — daily standups, weekly status meetings, bi-weekly status meetings, monthly review meetings, or as needed — with weekly as the default, plus a named primary contact on each side. The document then states that project communications go through those contacts and that status reports follow the agreed cadence.
The primary contact fields are separate from the client and provider contact fields in step 1, so the person who signs and the person you talk to weekly can be different people. Fill both sets in; leaving the primary contacts blank produces a communication plan that names nobody.
Section 11 runs the SOW from your start date to your end date and gives both parties two exits: termination for cause on 30 days' written notice if a material breach is not cured within that period, and termination for convenience on 60 days' written notice. On termination the client pays for work satisfactorily completed to that date. Those notice periods are fixed in the template.
Section 12 produces signature blocks for both sides, pre-filled with the contact names from step 1 and blank lines for signature, title and date. There is no counterparts or electronic-signature language, which is worth adding if the document will be signed through an e-signature service.
The review step displays the full document and offers three actions. Copy puts the plain text on your clipboard. Download TXT saves it as sow-<project-name>.txt, with the project name lower-cased and spaces replaced by hyphens (it falls back to sow-document.txt if you never named the project). Download PDF renders the same text into a plain PDF when a PDF library is already present in the page, and otherwise silently performs the same .txt download instead.
Because the output is monospaced plain text, the deliverables summary table only lines up in a fixed-width font. Pasting it into a word processor and switching to a proportional font will break the column alignment — either keep that block in a monospaced style, or rebuild it as a real table once the text is in your document editor.
Nothing you type is uploaded. There is no login, no autosave and no server-side draft: closing or reloading the tab discards the form, so export before you navigate away. For a document containing a client's name, your rates and a full deliverable schedule, that local-only behaviour is a real benefit over pasting the same figures into a hosted template service.
[If the engagement also needs confidentiality terms before scoping conversations start, the NDA generator produces a matching plain-text draft the same way.