Draft a statement of work for [PROJECT OR SERVICE] between [CLIENT] and [PROVIDER]. The business outcome is [BUSINESS OUTCOME]. Use these agreed inputs: [SCOPE AND DELIVERABLES], [TIMELINE AND COMMERCIAL TERMS], and [DEPENDENCIES AND CONSTRAINTS]. Write a practical operating document, not legal advice and not a substitute for a master services agreement. Preserve the facts I provide; mark any missing commercial, legal, security, or compliance term as “TBD” rather than inventing it. Produce a clean SOW with these sections: 1. Purpose and business outcome. 2. Scope of services, organized by workstream, including explicit in-scope activities and a separate out-of-scope list. 3. Deliverables table with description, owner, due date or milestone, format, and measurable acceptance criteria. 4. Project plan with phases, dependencies, client inputs, review windows, and decision points. 5. Roles and responsibilities for client and provider, including who can approve work. 6. Assumptions, constraints, and risks with a mitigation or escalation path. 7. Fees, invoicing triggers, and expenses only as supplied. 8. Change-control process stating what counts as a scope change, who approves it, and how timeline/fees are revised. 9. Governance, status cadence, and a concise acceptance/sign-off process. Use plain contract-ready language and avoid promises of outcomes outside the provider’s control. Before answering, self-check that each deliverable has an owner and acceptance criterion, and that no dependency is presented as the provider’s responsibility unless I said so. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROJECT OR SERVICE] | Name the work being purchased or delivered. | Customer onboarding redesign and implementation plan. |
| [CLIENT] | Enter the client’s legal or working name and key sponsor if known. | Northstar Logistics, sponsored by Priya Nair, VP Customer Success. |
| [PROVIDER] | Enter the provider’s legal or working name and delivery lead if known. | Pine & Field Consulting, led by Alex Moreno. |
| [BUSINESS OUTCOME] | State the intended business result in measurable or observable terms. | Reduce median time to first completed shipment setup from 14 days to 9 days. |
| [SCOPE AND DELIVERABLES] | List agreed activities, deliverables, exclusions, and any acceptance expectations. | Interview 10 customers and 6 internal staff; map current journey; deliver prioritized recommendations and a 90-day implementation plan; exclude software development. |
| [TIMELINE AND COMMERCIAL TERMS] | Provide dates, milestones, fees, payment timing, and expense rules that are already agreed. | Six weeks beginning October 7; fixed fee $24,000; 50% at kickoff and 50% on final delivery; pre-approved travel billed at cost. |
| [DEPENDENCIES AND CONSTRAINTS] | List required access, client inputs, approvals, technical limits, and known risks. | Client provides interview introductions within five business days, anonymized funnel data, and feedback within three business days; no access to production systems. |
How to use
- Paste agreed facts from the proposal, kickoff notes, and master agreement; do not use AI to fill unresolved terms.
- Compare the deliverables table with the proposal and ensure every item has a testable acceptance criterion.
- Have the delivery lead and client sponsor confirm assumptions, review windows, and approval authority before signature.
- Follow up with: “Convert the project plan into a weekly milestone table and identify the three dependencies most likely to delay delivery.”
Variations
Fixed-fee SOW
Use this when price is fixed and scope boundaries need to be especially clear.
Draft a fixed-fee SOW for [PROJECT] between [CLIENT] and [PROVIDER]. The fixed fee and payment milestones are [FEE TERMS]. Scope is [IN-SCOPE WORK]; exclusions are [OUT-OF-SCOPE WORK]. Create a deliverables table with acceptance criteria, a milestone schedule, and a change-order clause that requires written approval before work outside scope begins. Identify assumptions that could materially change effort. Do not add rate cards, warranties, tax treatment, or legal clauses not supplied. Mark missing terms TBD.
Discovery SOW
Use this for a short research or strategy engagement whose findings will shape later work.
Create a discovery-phase SOW for [BUSINESS PROBLEM]. The client is [CLIENT], provider is [PROVIDER], and the discovery inputs are [AVAILABLE INPUTS]. Define research activities, stakeholder participation, decision questions, and outputs such as findings, options, and a recommended next-phase plan. Make clear that discovery may change the future implementation scope. Include deliverable acceptance criteria focused on completed analysis and documented decisions, not guaranteed business results. State time box, fees, dependencies, and approval points from [TERMS].
Vendor implementation
Use this when a vendor is configuring or integrating a platform.
Draft an implementation SOW for [SYSTEM OR PLATFORM] for [CLIENT]. Include configuration scope, integrations, data migration, testing, training, launch support, and exclusions based on [SCOPE NOTES]. Use [TIMELINE] and [COMMERCIAL TERMS]. Create a responsibility matrix separating client, vendor, and third-party tasks. Define migration validation, user acceptance testing entry/exit criteria, defect severity handling, and launch readiness conditions. Do not claim security, availability, compliance, or integration capabilities that are not documented in the supplied materials.
Tips
- Define acceptance in observable terms, such as “a CSV with these fields reconciles to the approved source,” rather than “client is satisfied.”
- Put client review windows and input deadlines in the timeline; otherwise a provider can appear late when work is waiting for a decision.
- Separate discovery outputs from implementation commitments, because recommendations do not establish the effort needed to execute them.
- Treat a new integration, audience, geography, or revision cycle beyond the agreed limit as a potential change request.
FAQ
Can AI draft a legally binding statement of work?
It can draft a working document, but a qualified reviewer should check legal, tax, data protection, intellectual-property, and local-law requirements before signature.
What is the difference between a proposal and an SOW?
A proposal sells an approach; an SOW records the mutually agreed work, responsibilities, acceptance conditions, timing, and commercial terms.
Should fees be in the SOW?
Usually, yes, if the parties need the SOW to govern payment triggers. Use only terms already agreed and check alignment with the governing agreement.