Statement of Work — Template
Modeled on a real, closed $12k operating-system-build engagement; all parties and identifying details replaced with [BRACKET] placeholders. The MSA governs the relationship, this SOW governs the project. Attorney review before first client use.
[COMPANY]
STATEMENT OF WORK — Engagement One: [ENGAGEMENT NAME]
Prepared for: [CLIENT CONTACT], [CLIENT COMPANY] · [DATE] Prepared by: [FOUNDER], [COMPANY]
1. Engagement Summary
This Statement of Work (“SOW”) is entered into pursuant to the Master Service Agreement (“MSA”) between [COMPANY] (“Company”) and [CLIENT COMPANY] (“Client”), dated [MSA DATE]. This SOW is incorporated by reference into the MSA and governed by its terms.
This SOW describes the first engagement between the Parties: [one-sentence plain-English description of what is being built and what it covers].
| Engagement details | |
|---|---|
| Engagement name | Engagement One: [NAME] |
| Total investment | $[AMOUNT] USD |
| Timeline | [N] to [N] weeks from kickoff |
| Kickoff date | Week of [DATE] (target) |
| Target completion | [DATE RANGE] |
| Post-launch support | [60] days included |
2. Scope of Work
The Company will design and build [the system] for the Client, replacing or integrating with the Client’s current tools, providing role-specific views for each department, and giving leadership real-time visibility across the business.
2.1 Departments / workstreams
Role-specific views, workflows, and dashboards for:
- [Department 1] — [the 3–5 workflow steps it owns].
- [Department 2] — [steps].
- [Department 3] — [steps].
2.2 Cross-cutting workflows
- [e.g. Finance & Accounting] — [e.g. vendor invoice ingestion via dedicated email, automated extraction, project matching, accounting-system integration for bill creation and approval].
2.3 Integrations
The Company will use API connections where available and email-based integrations where APIs are not available or accessible.
| System | Integration type |
|---|---|
| [System A] | API integration, build around |
| [System B] | API integration |
| [System C] | Email parsing / inbox monitoring + AI extraction |
Tools identified together as candidates for replacement (the new system absorbs their functionality):
- [Tool 1] — to be replaced
- [Tool 2] — to be replaced
- [Tool 3] — to be migrated and replaced
2.4 Deliverables
Upon completion, the Client receives:
- A working [system], hosted on infrastructure managed by the Company, accessible via web browser by all Client stakeholders.
- Role-specific user accounts and views for each stakeholder identified in Section 3.
- A leadership dashboard providing real-time, cross-department visibility.
- Documented audit findings and architectural decisions, delivered as the Final Implementation Document at the end of the audit phase.
- Migrated historical data from [tools] where relevant.
- Up to [N] external system integrations as defined in Section 2.3.
- Live training sessions for each department during rollout.
- [60] days of post-launch support from the official launch date.
2.5 Out of scope
Explicitly out of scope; addressed, if needed, in a future engagement or Change Order:
- [e.g. AI agents and intelligent automation beyond X (planned for Engagement Two).]
- [e.g. Replacement of SYSTEM (integrate, don’t replace).]
- [e.g. Native mobile apps (responsive web only).]
- [e.g. Custom reporting beyond the leadership dashboard and standard views.]
3. Stakeholders & Audit Phase
The audit phase (weeks [1–2]) includes focused interviews with each stakeholder below. Each commits [2–4] hours per week during the audit phase.
| Role | Stakeholder |
|---|---|
| Owner / Executive | [NAME] |
| [Department 1] lead | [NAME(S)] |
| [Department 2] lead | [NAME(S)] |
The Client agrees to make these stakeholders reasonably available. The Company schedules all audit interviews during the kickoff call, locking calendar availability for the entire audit phase upfront.
4. Timeline & Phases
| Phase | Description | Timeline |
|---|---|---|
| 1 — Audit & Architecture | Stakeholder interviews, workflow mapping, tool audit, architectural blueprint + Final Implementation Document. | Weeks [1–2] |
| 2 — Core Build | Core data model, role-specific views, leadership dashboard. Working prototype reviewed in check-ins. | Weeks [2–7] |
| 3 — Rollout | Phased migration from existing tools, department by department. Live training. On-the-ground transition support. | Weeks [7–10] |
| 4 — Launch & Stabilization | Full production. Post-launch support begins. Refinements from real-world usage. Final handoff documentation. | Weeks [10–12+] |
Cadence: daily [30-minute] check-in huddles through the build, plus a weekly progress review with the owner.
5. Payment Schedule
Total fees: $[AMOUNT] USD, payable in [three] installments:
| Payment | Trigger | Amount |
|---|---|---|
| Payment 1 | Upon execution of this SOW | $[~65%] |
| Payment 2 | [60] days after kickoff OR completion, whichever first | $[~17%] |
| Payment 3 | [90] days after kickoff OR completion, whichever first | $[~17%] |
All payments due within [7] days of the trigger date, via ACH, wire, or other electronic method specified by the Company. No other fees are owed unless agreed in writing through a Change Order (Section 8) or a separate SOW.
6. Success Criteria
If traditional 90-day ROI metrics don’t fit the client’s deal cycle, say so here and define what does — agreed during scoping, in the client’s own words.
- Operational clarity — by the end of post-launch support, the Client operates with [a single source of truth / complete visibility on X]. (Capture the client’s own articulation from the scoping call here — their words, quoted back, become the acceptance standard.)
- Time reclaimed — the owner’s average hours worked per week is the leading indicator. Baseline captured during the audit phase; target is a meaningful reduction.
- Tool consolidation — measured by the Client’s ability to discontinue the tools listed for replacement in Section 2.3.
7. Division of Responsibility
Client agrees to: provide stakeholder access per the kickoff schedule; provide credentials/API/screen-share access to the systems in §2.3 by the dates each phase requires; provide existing process documentation; review Work Product and give feedback within [3] business days; attend (or delegate) daily check-ins; pay invoices per §5.
Company agrees to: conduct all activities with due diligence and professional expertise; lead the audit, design, and build; hold daily check-ins and weekly owner reviews; deliver the Final Implementation Document at the end of the audit; provide live training and rollout support; provide [60] days of post-launch support; address issues promptly.
8. Change Order Process
Scope, fees, and timeline in this SOW are fixed. Any material modification requires a Change Order, effective only on written agreement of both Parties, covering: the change and its impact, additional fees, and timeline impact. No out-of-scope work begins before a signed Change Order.
Scope items that legitimately emerge during the audit get flagged proactively; the Client may absorb them within existing scope (where reasonable), defer them to Engagement Two, or formalize a Change Order.
9. Ongoing Maintenance
After launch + post-launch support, the Parties enter a separate maintenance agreement (uptime, security updates, bug fixes, performance, small workflow adjustments). Monthly fee range $[LOW]–$[HIGH]/month, locked during rollout when final scope is visible. Maintenance is not part of this SOW; the Client is under no obligation, though the Company strongly recommends it.
10. Future Engagements
This SOW covers Engagement One only. Engagement Two ([e.g. AI agents and intelligent automation on top of the new system]) has been discussed in principle; its scope, fees, and timeline will be determined separately. Nothing here commits either Party to it.
11. Acceptance
By signing below, the Parties agree to be bound by this SOW and the MSA. Electronic signatures are valid and binding.
[COMPANY] — [FOUNDER], Founder · Date: ______
[CLIENT COMPANY] — [CLIENT CONTACT], [Title] · Date: ______