The Problem This Solves
Most Customer Success resources focus on post-launch relationship management. QBRs, health scores, renewal playbooks — all useful, but they assume the implementation went well. They start at the wrong point in the story.
Platform Success Managers and Implementation Managers live in the gap that most CS frameworks ignore: the pre-implementation scoping work that happens before a single line of code is configured. The SOW is where the project either gets set up to succeed or quietly loaded with the assumptions that will blow up three months later.
This framework fills that gap. It shows how to bridge sales promises and delivery reality, document the assumptions that protect both sides, and create a roadmap that prevents the "wait, that wasn't in scope" conversations when things go live.
You've been on both sides of SOW creation. You know what a well-scoped implementation looks like — and you know what it costs when scope, timeline, and stakeholder alignment aren't locked down from day one.
The Five-Step Process
01
Gather Context from Sales
Before touching a blank doc, get the full picture from the sales team. What was promised? What's the client expecting? Where are the landmines?
Ask the right questions
Spot red flags early
Sales handoff checklist
02
Discovery Session with Client
Confirm business objectives, map stakeholders, understand the current infrastructure, and surface constraints the sales team didn't know about.
Business objectives
Stakeholder mapping
Constraint identification
03
Technical Scoping with Delivery Team
Validate feasibility, surface dependencies, and close the gap between what sales sold and what delivery can actually build in the timeline given.
Feasibility validation
Dependency mapping
Bridge sales & delivery
04
Draft the SOW
Write the document using the eight required sections. Be specific. Use measurable criteria. Define what's out of scope as clearly as what's in.
8-section structure
Plain language
Out-of-scope definition
05
Review & Iteration
Internal review first. Then client walkthrough — not email delivery, an actual walkthrough. Final sign-off with the right stakeholders in the room.
Internal review
Client walkthrough
Exec sign-off
Common Pitfalls & Best Practices
Common SOW Pitfalls
- Vague scope that leaves room for "that's obviously included" arguments
- Timelines built on best-case assumptions, not realistic delivery capacity
- Missing dependencies — especially third-party integrations and client-side IT
- Assuming technical capabilities the client doesn't actually have
- No change management process for when (not if) scope shifts
SOW Best Practices
- Be specific — ambiguous language is a liability, not flexibility
- Use measurable acceptance criteria so "done" means the same thing to everyone
- Document assumptions explicitly; they're your protection when reality diverges
- Build in buffer time — delivery always has surprises
- Define out-of-scope as clearly as in-scope
- Get stakeholder buy-in before final sign-off, not after
The 8-Section Template
01
Project Overview
02
Scope of Work
In Scope + Out of Scope
03
Deliverables
With target dates
04
Implementation Timeline & Milestones
4-phase structure
05
Roles & Responsibilities
Vendor vs. client
06
Assumptions & Dependencies
07
Change Management Process
08
Acceptance Criteria
With sign-off section
12-Point Final Checklist
Scope clearly defined — no ambiguous language
Out-of-scope items explicitly listed
All deliverables have target dates and owners
Timeline includes buffer; not best-case only
Technical dependencies documented
Third-party integrations scoped and confirmed
Client-side responsibilities clearly assigned
Assumptions documented and shared
Change management process defined
Acceptance criteria are measurable, not subjective
Stakeholder sign-off from the right people
Delivery team has reviewed and confirmed feasibility
Who Should Use This
Platform Success Managers
Leading SOW creation from the sales cycle through implementation and beyond.
Implementation Managers
Scoping complex B2B SaaS projects where technical feasibility needs validation before commit.
Customer Success Managers
Involved in pre-sales technical discovery or inheriting accounts post-implementation.
Solutions Engineers
Working with delivery teams on scoping and translating business requirements into technical spec.
Why This Framework Exists
This came out of a realization: most CS frameworks start at go-live. They assume implementation went smoothly and the account is ready for the relationship management motion. But the work that determines whether an implementation succeeds or becomes a firefight happens before any of that — in the scoping conversations, the sales handoff, the technical discovery that either surfaces the constraints early or buries them until they become escalations.
Platform Success Managers who lead SOW creation are doing some of the highest-leverage work in the customer lifecycle. Getting scope, timeline, and stakeholder alignment locked down from day one is what separates implementations that generate advocates from ones that generate churn.
This framework codifies that process — built from 20+ years of seeing what works on both sides of implementation.