Price Statement Of Work

---
name: price-statement-of-work
description: Writes a Statement of Work with the outcome, deliverables, testable acceptance criteria, the assumptions the price rests on, revision rounds, change triggers, the AI use and client data lines and plain commercial terms, with anything beyond plain terms marked for an adviser. Use for "run price-statement-of-work", "write a statement of work", "SOW for this project", "turn the proposal into a SOW", "stop scope creep", "acceptance criteria for the deliverables", "how many revision rounds", "AI line in the contract", part of the Pricing Under AI Pressure Pack by Polar Bear.
---

# Statement of Work

## When To Use
The price is agreed and the scope must stop moving. The client said yes to the proposal, and you already sense the "can you also" emails coming. This skill answers: what exactly did the client buy, how will we both know a deliverable is done, and what counts as a change?

## When Not To Use
If the client has not agreed a price or an option yet, use Three-Option Proposal; a SOW fixes a deal, it does not sell one. If the client's master agreement carries AI clauses you are unsure about, run AI Contract Questions before you sign either.

## Inputs
- The agreed proposal or option, with fee, phases and assumptions, plus the brief and any email where scope or dates were agreed
- Your AI Disclosure Policy, or how you use AI on this work in a line
- The client's own contract or master agreement, if this SOW sits under one
If you have none of this, I start from the agreed fee and a list of deliverables, and mark the output as a first draft.

## Approach
A statement of work is a practitioner convention: one document that says what will be delivered, how it will be accepted and on what assumptions the price rests, so it can serve as the signed baseline every later change is measured against. The AI line follows the clauses clients now add to their agreements, as reported by Digiday in September 2026 (data in AI tools, tool disclosure, human oversight). The failure it prevents: a vague deliverable like "recommendations" that turns into five rounds nobody priced, because nothing said when it was done.

## Workflow
1. Ask at most three questions: who signs for the client, whether this SOW sits under a master agreement, and how many revision rounds you priced.
2. Outcome in one sentence, in the client's terms. Then each deliverable as a noun you can hand over (a report, a workshop, a file), never an activity.
3. Acceptance criteria per deliverable, written so a third person could check them: what it contains, its format, who reviews it, how long they have to respond, and what silence after that period means. "Client is happy" is not a criterion.
4. Assumptions the price rests on, carried over from the proposal: client inputs and their dates, access, review turnaround, number of stakeholders, start date. Each assumption that fails is a change trigger; say so next to it.
5. Revision rounds per deliverable and what a round is (one consolidated set of comments). The change process: anything outside the deliverables, criteria or assumptions goes through a written change request, priced before work starts. This SOW is the baseline that request is checked against.
6. The AI use line pointing to your AI Disclosure Policy, and the client data line (what data you receive, which tools it may enter, what never goes into them). Both must match what you actually do.
7. Fee, schedule and payment terms in plain words from the agreed proposal. Anything beyond plain commercial terms (liability, IP, termination, confidentiality, how this sits under their agreement) is marked "check with a qualified adviser". Draft in Claude Docs (beta) or in the chat.

## Output Format
```markdown
# Statement of Work
**Client:** [name] | **Under agreement:** [name and date, or none] | **Version:** [n], [date]
## Outcome
[One sentence in the client's terms]
## Deliverables and acceptance
| # | Deliverable | Acceptance criteria | Reviewer | Response time | Revision rounds |
|---|---|---|---|---|---|
| D1 | [deliverable] | [checkable criteria] | [role] | [days] | [n] |
## Assumptions the price rests on
| Assumption | If it does not hold |
|---|---|
| [client input by date] | Change request, priced and approved before work starts |
## AI use and client data
[Pointer to AI Disclosure Policy, version and date] | [Client data line]
## Fee and terms
| Phase or deliverable | Fee | Invoice date | Payment terms |
|---|---|---|---|
| [phase] | [agreed fee] | [date] | [terms] |
Marked for adviser: [clause topics]. Check with a qualified adviser.
## Decision
[Your name] and [client signatory] sign this SOW by [date]; work starts on [date] and it becomes the baseline for every change.
```

## Done When
- Every deliverable has acceptance criteria a third person could check
- Every assumption from the proposal appears, each with its consequence if it fails
- The AI and data lines match your policy, and the fee matches the agreed proposal exactly

## Quality Bar
- Fees, dates and rounds come from the agreed proposal; Claude adds no number of its own
- Deliverables are things handed over, never open-ended activities like "support" or "ongoing advice"
- The AI line states your use plainly; it never promises less AI than you use
- The SOW stays in plain words; legal terms are listed for the adviser, never drafted
- Not legal advice: anything beyond plain commercial terms is marked "check with a qualified adviser"

## Next
Run price-ai-contract-questions (AI Contract Questions) when the client's agreement adds AI clauses.

## About the makers

This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).