On this page (6)
A good Salesforce statement of work tells both sides exactly what will be built, what will not, and how you will know it is finished. It names the processes and teams in scope, lists the assumptions behind the estimate, defines each deliverable with acceptance criteria, assigns roles on both sides, and explains how changes are requested and priced. For data migration, integrations and post-launch support it should be concrete down to objects, systems and dates. Vague wording in any of these areas becomes a dispute later.
Why the SOW outweighs the proposal
Proposals are written to win. The statement of work is written to be enforced, and once it is signed it usually overrides whatever the sales deck promised. When a project goes sideways, both parties go back to this document to decide who owes what, so any item left out of it is effectively out of scope.
That makes the SOW a working document for your project team, not only for procurement or legal. The business owner, the future admin and whoever owns your other systems should read it before signature, because each will spot different gaps. Ask the partner to walk you through it section by section, and treat anything they cannot explain in plain language as a sign the wording needs to change.
The sections every Salesforce SOW needs
| Section | What good looks like | Warning sign |
|---|---|---|
| Scope | Named teams, processes and Salesforce products, with an explicit out-of-scope list | Scope described as "implement Sales Cloud" or "best practices" |
| Assumptions | Numbered, testable statements about users, data volume, integrations and your availability | No assumptions, or a single clause saying the estimate may change |
| Deliverables | Each item described as a thing you can inspect: a flow, a report set, a design document | Deliverables listed as hours or activities rather than outcomes |
| Acceptance criteria | How each deliverable is tested, who signs off and how long they have | Acceptance implied by go-live or by silence |
| Roles | Named partner roles and the client roles and time commitments the plan relies on | Only partner roles listed, or "resources as needed" |
| Change control | A written request process with effort, timeline impact and client approval | No process, or changes billed without written approval |
| Schedule and payment | Milestones tied to accepted deliverables | Payments tied only to calendar dates |
| Post-launch support | A defined hypercare window with scope, response expectations and exit criteria | Support after launch not mentioned |
The out-of-scope list deserves as much care as the scope itself. Reporting beyond a stated number of dashboards, historical data older than a set cutoff, additional business units and third-party packages are common candidates. Writing them down does not stop you adding them later; it means everyone knows they would be a change.
Assumptions, roles and your side of the work
Assumptions are where two estimates for similar work diverge, and where most disputes start. A strong SOW turns them into numbered statements you can check, such as the number of users by role, the record counts for each object being migrated, the systems that will connect and how, and the hours per week your subject-matter experts will give to workshops and testing.
Read the client responsibilities carefully, because the partner's timeline depends on them. Typical examples include providing sandbox and system access by a certain date, supplying cleaned source data, making decisions within an agreed number of business days, and running user acceptance testing. If you cannot meet one, say so before you sign rather than after the schedule slips.
Data migration and integration specifics
These two areas carry the most hidden effort, so general wording is not enough. For migration, the SOW should state:
- Each source system and the Salesforce objects it maps to, with approximate record counts.
- How much history moves, and what stays behind in an archive.
- Who cleans and deduplicates data, and whether that happens before or during migration.
- How many trial loads are planned, and how record counts are reconciled against the source.
- Who signs off the final load and the cutover plan, including any freeze on the old system.
For each integration, look for the system name, the direction data flows, the objects and fields involved, how often it runs, the tool or middleware used, and who owns the other end. Error handling and monitoring should be named deliverables, since an integration that fails silently is worse than none. If the partner depends on your ERP team or another vendor to expose an API, that dependency belongs in the assumptions with a date attached.
Acceptance, change control and hypercare
Acceptance criteria connect deliverables to payment. For configuration, they are usually test scripts based on your real processes, run in a sandbox by your users, with a fixed review window and a way to log defects. Distinguish defects, where the build does not match the agreed design, from new requests, where the design itself was incomplete. The first is the partner's to fix; the second goes through change control.
A workable change process has a written request, an impact estimate covering effort and schedule, approval by a named person on your side, and a running log both parties can see. Some teams also agree a small pool of hours for minor changes, which saves paperwork on the little things discovery always misses.
Hypercare is the period straight after go-live when the project team stays on hand to fix issues and answer questions. The SOW should say how long it lasts, which issues it covers, how requests are raised, how quickly the partner responds during business hours, and what must be true for it to end. It should also say what happens next, whether that is a handover to your admin, managed services, or both.
Red flags to catch before you sign
- The scope repeats product feature lists instead of describing your processes.
- A fixed price with no assumptions, which usually means risk is priced in or will surface as change requests.
- Deliverables described only as hours of effort or "configuration of Salesforce".
- No acceptance criteria, or acceptance deemed complete after a few days without response.
- Data migration listed as a single line item with no volumes, sources or reconciliation step.
- Integrations named without direction, frequency or error handling.
- Training limited to one session, with no materials handed over.
- Key people unnamed, or a clause allowing staff substitution without notice.
- No mention of documentation, ownership or what happens after hypercare.
None of these automatically disqualifies a partner, and some reflect a template rather than bad intent. Raise each one in writing and judge the response. A partner that tightens the wording quickly is showing you how it will behave when the project hits a problem.
Questions people also ask
What should a Salesforce statement of work include?
A Salesforce statement of work should include scope with an explicit out-of-scope list, numbered assumptions, deliverables you can inspect, acceptance criteria, roles on both sides, a change control process, milestones tied to accepted deliverables, and a defined hypercare window. Data migration and integrations need specifics down to objects, systems and dates. It should also state that you own the configuration, code and documentation produced.
How do we track a partner's delivery against the statement of work?
Track delivery against the deliverables and acceptance criteria the SOW defines. Each deliverable should be something you can inspect, tested with scripts based on your real processes, run in a sandbox by your users within a fixed review window. Tie payments to accepted deliverables rather than calendar dates, and keep a running change log both parties can see, so you can separate defects from new requests.
Why does the statement of work matter more than the proposal?
The statement of work matters more because it is the document that gets enforced. Proposals are written to win, and once the SOW is signed it usually overrides whatever the sales deck promised. When a project goes sideways, both sides go back to it to decide who owes what, so anything left out of it is effectively out of scope.
What cancellation or exit clause should a Salesforce statement of work include?
This is not legal advice, so have your counsel review the agreement. The exit terms buyers most often want settled up front are whether either side can end the work for convenience, the notice period, payment for work completed or accepted to that date, handover of configuration, code, documentation and credentials, how work in progress is finished or rolled back, any transition help the partner provides, and what happens to prepaid or banked hours.
