---
name: sow-drafter
description: Draft a Statement of Work from a plain-English brief — scope, deliverables, timeline, fees, assumptions, acceptance criteria, and an explicit out-of-scope section — for consulting or MSP engagements.
version: 1.0.0
author: VantagePoint Networks
author_url: https://www.vpnetworks.co.uk
audience: Consultants, MSP Account Managers, Sales Engineers, Solo Founders, Agency Leads, In-house IT pitching internal projects
output_format: Formatted Markdown SoW with cover page, scope, deliverables table, timeline, fee schedule, assumptions, acceptance criteria, change control, and signature block.
license: MIT
last-reviewed: 2026-04
---

# Statement of Work Drafter

A Claude Code skill for producing a proper SoW — the document that turns "yeah we can help with that" into an engagement that starts, finishes, and gets paid for on time — without hiring a lawyer for every proposal.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. In Claude Code, run `/sow-drafter`. Describe the engagement. Answer the clarifying questions. Receive a client-ready SoW draft.

## When to use this

- A prospect has said yes and you have a week to turn a conversation into a signable document.
- You're renewing a retainer and need to refresh scope, fees, and acceptance criteria.
- You want a consistent SoW house style so every engagement starts from the same baseline.
- You've been burned before on scope creep and want "out of scope" and "change control" in writing from day one.
- You're presenting internally and need an SoW-style document to pitch a project to the Board.

## What you'll get

A single Markdown document containing:

- **Cover page** (parties, date, version, reference)
- **Engagement summary** (what, why, outcomes)
- **Scope** (what's in)
- **Out of scope** (what's explicitly NOT in — the most important section)
- **Deliverables table** (name, description, acceptance criteria, delivery date)
- **Timeline** (phases, milestones, dependencies)
- **Team & responsibilities** (your side, their side)
- **Fee schedule** (fixed / T&M / hybrid, payment terms, expenses, VAT)
- **Assumptions** (the things that have to be true for this to work)
- **Risks & mitigations**
- **Change control** (how scope changes are handled — written, priced, signed)
- **Acceptance criteria** (how "done" is defined)
- **Commercial terms** (IP, confidentiality, data handling, termination, liability cap)
- **Signature block**

## Clarifying questions I will ask you

1. **Client name, sector, and size?**
2. **What's the outcome the client wants?** (not "an audit" — "a pass on Cyber Essentials Plus by end of Q2")
3. **How did the conversation start?** (cold outreach, referral, RFP, existing client)
4. **What is the scope in one sentence?**
5. **What is the deliverable — the thing you hand over?**
6. **What's NOT in scope?** (be specific — what might they assume that you won't do)
7. **How will they know it's done?** (acceptance criteria)
8. **When does it need to be done by?** (fixed deadline, or flexible)
9. **Who's involved on their side?** (named stakeholder, business sponsor, IT lead, end users)
10. **Fee model?** (fixed price, T&M, retainer, hybrid)
11. **Estimated fee and payment terms?** (£X on kickoff, £X on delivery, 30 days net, etc.)
12. **Any known risks or dependencies?** (data readiness, third-party access, exec availability)
13. **Your standard T&Cs in use?** (yes, attach / no, need a short commercial terms section in the SoW)
14. **IP handling?** (their IP / your IP / jointly owned / bespoke)

## Output template

```markdown
# Statement of Work

**Between:** <Client legal entity>
**And:** <Your legal entity>
**Date:** <date>
**Reference:** SOW-<N>
**Version:** 1.0

## 1. Parties
**Client:** <Legal name, registered address, primary contact — name, role, email>
**Supplier:** <Your legal name, registered address, primary contact — name, role, email>

## 2. Engagement Summary
<One paragraph. What, why, outcome. In business language.>

## 3. Scope
The supplier will:
- <activity 1>
- <activity 2>
- <activity 3>
- <activity 4>

## 4. Out of Scope
For the avoidance of doubt, the following are explicitly **not** included:
- <item 1 — typically "ongoing support after delivery">
- <item 2 — typically "any work on systems not listed in §3">
- <item 3 — typically "licence costs, hardware purchase, third-party fees">
- <item 4 — typically "training beyond one handover session">
- Additional scope is priced and agreed under §11 Change Control.

## 5. Deliverables
| # | Deliverable | Description | Acceptance criteria | Due date |
|---|---|---|---|---|
| D1 | <name> | <description> | <measurable criteria> | <date> |
| D2 | <name> | <description> | <measurable criteria> | <date> |
| D3 | <name> | <description> | <measurable criteria> | <date> |

## 6. Timeline
| Phase | Activity | Start | End | Milestone |
|---|---|---|---|---|
| 1 | Discovery | <date> | <date> | Kick-off, interviews complete |
| 2 | Design | <date> | <date> | Design doc accepted |
| 3 | Implementation | <date> | <date> | D1-D3 delivered |
| 4 | Handover | <date> | <date> | Acceptance + handover |

Dependencies:
- <dependency 1 — typically "client to provide admin access by <date>">
- <dependency 2>

## 7. Team & Responsibilities
### Supplier
| Role | Named individual (if known) | Involvement |
|---|---|---|
| Lead Consultant | <name> | Throughout |
| Technical Consultant | <name> | Phases 2-3 |
| QA / Peer Reviewer | <name> | Phase 3-4 |

### Client
| Role | Named individual | Responsibility |
|---|---|---|
| Business Sponsor | <name> | Sign-off on deliverables, fee approval |
| IT Lead | <name> | Technical access, decisions in phase 2-3 |
| Operational contact | <name> | Day-to-day liaison |

## 8. Fee Schedule
**Fee model:** <Fixed price / Time & materials / Hybrid>
**Total fee:** £<N>.00 (+ VAT where applicable)
**Fee breakdown:**
| Milestone | Payment | Due |
|---|---|---|
| SoW signed | £<N> (<%>) | Invoice on signature, 14 days |
| D1 delivered & accepted | £<N> (<%>) | Invoice on acceptance, 30 days |
| D2-D3 delivered & accepted | £<N> (<%>) | Invoice on acceptance, 30 days |

**Expenses:** reimbursed at cost with receipts. Capped at <£N> unless agreed in writing.
**Travel:** <included / billed separately per reasonable policy>.
**Payment terms:** <30 days net / as invoiced>.
**Late payment:** statutory interest per the Late Payment of Commercial Debts (Interest) Act 1998 applies after due date.

## 9. Assumptions
This engagement assumes:
- <assumption 1 — typically "client IT team available for agreed meetings">
- <assumption 2 — typically "admin access granted within 5 working days of kick-off">
- <assumption 3 — typically "no material change in scope during delivery">
- <assumption 4 — typically "third-party vendors cooperate where identified">

If any assumption proves false, supplier will raise a change request under §11.

## 10. Risks & Mitigations
| Risk | Impact | Likelihood | Mitigation |
|---|---|---|---|
| Delayed access to systems | Timeline slip | Medium | Escalation to Business Sponsor after 3 working days |
| Scope expansion during delivery | Fee + timeline impact | Medium | Change-control process per §11 |
| Client resource unavailable | Delivery risk | Low | Named backup contact in §7 |

## 11. Change Control
- Any change to scope, timeline, or fee requires a written Change Request.
- Change Requests are priced and signed by both parties before work begins.
- Verbal agreements, email side-chats, and "while you're in there" additions are not binding until papered.
- Template Change Request available on request.

## 12. Acceptance
A deliverable is deemed accepted when:
- Delivered in the agreed format by the agreed date.
- Meets the acceptance criteria in §5.
- Business Sponsor provides written sign-off (email acceptable).
- If not rejected in writing within <N> working days of delivery, the deliverable is deemed accepted.

## 13. Commercial Terms (summary)
- **Confidentiality:** each party protects the other's confidential information for the duration of the engagement and <N> years after. Excludes public information and information independently developed.
- **IP:** supplier's pre-existing IP remains supplier's. Work product created specifically for this engagement belongs to <client / supplier / jointly> as agreed. Third-party OSS licences honoured.
- **Data protection:** where supplier processes personal data on client's behalf, the parties' Data Processing Agreement at Annex A applies.
- **Termination:** either party may terminate for convenience with <N> working days' written notice. Supplier paid pro-rata for work completed.
- **Liability:** liability capped at the total fees paid in the <N> months preceding a claim. Neither party liable for indirect or consequential loss. Nothing in this SoW limits liability for death/personal injury caused by negligence or fraud.
- **Governing law:** England and Wales. Courts of England and Wales have exclusive jurisdiction.

(Where the parties already have a Master Services Agreement, it takes precedence over this section.)

## 14. Annexes
- Annex A: Data Processing Agreement (if applicable)
- Annex B: Change Request template
- Annex C: Acceptance Certificate template

## 15. Signatures
**For the Client:**
Name: ____________________________  Role: ______________________
Signature: ________________________  Date: ______________________

**For the Supplier:**
Name: ____________________________  Role: ______________________
Signature: ________________________  Date: ______________________
```

## Example invocation

**User:** "A 30-person London accountancy firm wants a private-AI pilot. Fixed fee £24,000 over 10 weeks. Three deliverables: readiness audit, 5-seat pilot deployment on their infrastructure, and a 90-day review. Referral from an existing client."

**What the skill will do:**
1. Ask the 14 clarifying questions, drilling on: acceptance criteria for "readiness audit" (what does pass/fail look like?), out-of-scope items (typical for pilots: "scaling beyond 5 seats, licence fees, ongoing support"), assumptions (client provides VM / endpoint / sandbox account by week 2).
2. Produce the full SoW with:
   - Deliverables D1 (readiness audit — signed memo with 8 specific findings), D2 (5-seat pilot live and documented), D3 (90-day review memo with use-case evaluation)
   - Payment milestones: 30% on signature, 40% on D2, 30% on D3
   - Out-of-scope: anything beyond 5 seats, SRA-specific compliance mapping (separate SoW), ongoing managed service (separate retainer)
   - Change-control clause explicit about pilot-expansion requests
   - ICAEW-aligned confidentiality statement
3. Flag that IP for the prompt library and private-AI configuration should be explicitly assigned (usually jointly owned — client pays, supplier retains right to reuse techniques).

## Notes for the requester

- **"Out of scope" is the most important section in the whole document.** Most scope creep starts with something the client assumed was included. Be specific and slightly uncomfortable about it.
- **Acceptance criteria must be measurable.** "High-quality output" is not a criterion. "Pilot produces at least one measurable time-saving per user per week, evidenced by the weekly survey" is.
- **Name the Business Sponsor.** If there's no single person who can sign off deliverables, the engagement has no acceptance path and will drift.
- **Don't skip the liability cap.** For most SMB engagements, cap at fees paid in the preceding 12 months is the market-standard starting point. Your insurer may require it.
- **Good looks like:** signed within two weeks of submission, no mid-engagement "we also need X" that you didn't already anticipate in Out-of-Scope or Assumptions, final invoice paid on time.

---
*VantagePoint Networks · <https://www.vpnetworks.co.uk> · Authored by Hak · Free under the MIT licence*