SOW Template Builder

---
name: sow-template-builder
description: Use when drafting a Statement of Work for a services engagement. Triggers on "draft an SOW", "statement of work", "build an SOW", or scope/timeline/fee data for a services project.
---

# SOW Template Builder

Build an SOW that survives the inevitable "wait, was that in scope?" conversation in week 3. Most SOWs fail because they describe activities ("we will work on...") instead of deliverables ("we will deliver X by date Y, accepted when Z"). Force the deliverable framing.

## Required inputs

1. **Parties** — provider, client, signatory names + titles
2. **Reference to MSA** if one exists, OR standalone terms
3. **Project name and 1-paragraph description**
4. **Deliverables** — 4-10 named, atomic things. Each one shippable.
5. **Timeline** — start date, milestones, end date
6. **Fees** — fixed / T&M / hybrid; payment schedule tied to milestones
7. **Acceptance criteria** — how the client signs off on each deliverable
8. **Assumptions** — what the client provides, what's out of scope
9. **Change order process** — how scope changes get approved

If the user gives you "we'll help them with their data stuff," push back. Vague SOWs lose money — the consultant eats the scope creep.

## Document structure

1. **Header** — SOW number, project name, effective date, MSA reference if any
2. **Project description** (1 paragraph) — what we're doing, for whom, why
3. **Scope of services** — what's included, by phase or workstream
4. **Deliverables table** — Number | Deliverable | Description | Due date | Acceptance criteria
5. **Project schedule** — milestones with dates; Gantt-style table or bullet list
6. **Project team** — provider's named team + client's named counterparts (RACI optional)
7. **Fees & payment schedule** — amounts tied to milestones, invoice cadence, payment terms (net 15/30)
8. **Assumptions** — what the client must provide (access, data, decision-makers, environments)
9. **Out of scope** — explicit list. This section saves the engagement.
10. **Change order process** — how a scope change gets requested, estimated, approved, and added
11. **Acceptance** — what counts as deliverable acceptance, deemed-acceptance window (e.g., 5 business days)
12. **Term & termination** — duration, termination for cause, kill-fee on convenience termination
13. **Signature block**

## Deliverable writing

Each deliverable line must answer:
- **What is it** — a noun, not a verb. "Data model documentation" not "Document the data model."
- **Format** — .docx? .pdf? Live system? Trained users?
- **Definition of done** — measurable, observable, time-bounded

Bad: "Help client improve their analytics."
Good: "Deliverable 3: Production dashboard suite — three Looker dashboards (Revenue, Retention, Acquisition) deployed to client's instance, accepted when client product owner has reviewed each dashboard against the agreed wireframes (Exhibit B) and signed acceptance form."

## Style & tone

- **python-docx** with proper heading styles, or markdown → docx via Pandoc.
- Use a deliverables TABLE, not a bulleted list. Tables survive Word's auto-formatting.
- 11pt body, 1.15 line spacing, headings in a contrasting weight.
- Number every section and sub-section. Counsel and PMs both reference by number.
- Dates in a single format throughout — "April 29, 2026" or "2026-04-29". Pick one.

## Common pitfalls

- **No "Out of scope" section**: the most-used clause when a client asks for something extra.
- **Activities instead of deliverables**: "Conduct discovery workshops" is an activity, not a deliverable. The deliverable is the discovery report.
- **Acceptance criteria too soft**: "client is satisfied" — undefined. Use objective criteria.
- **Payment not tied to milestones**: invoice schedule with no link to delivery means cash flow risk if a milestone slips.
- **No deemed-acceptance clause**: client never explicitly accepts and project drags forever. Add: "Deliverable is deemed accepted if client does not provide written objection within 5 business days of submission."
- **Change orders verbal**: scope creep happens through Slack messages. Force a written change order with a fee impact estimate.

## Output

Produce the .docx and a 1-page **kickoff summary**: project name, total fees, key dates, key risks, what the client must provide before week 1. PMs use this to brief their team without re-reading the SOW.