What a Salesforce Statement of Work Should Actually Include (And What to Watch Out For)

Most Salesforce project problems are not technical. They are contractual. The scope was not defined clearly enough. The deliverables were described in terms of effort rather than outcomes. The change order process was not spelled out, so every new request became a negotiation. The project ran long, the budget ran out, and both sides felt like the other one was being unreasonable.

A well-written statement of work prevents most of this. It is not a legal formality. It is the document that defines what success looks like and how you will know when you have reached it. Here is what it should include, and what to watch out for when you are reviewing one.

What a Good SOW Covers

Project scope and objectives

The scope section should describe what the project will accomplish in plain language. Not "implement Sales Cloud" but "configure Sales Cloud to support the lead-to-opportunity process for a 12-person sales team, including custom fields for X, Y, and Z, a lead assignment rule based on territory, and a dashboard showing pipeline by stage and rep." The more specific, the better. Vague scope is where budget overruns are born.

Explicit deliverables

Every deliverable should be named and described. Configuration of specific objects and fields. Custom reports and dashboards. Data migration from a named source system. User training for a defined number of users. Documentation of what was built. If it is not listed as a deliverable, it is not in scope.

What is explicitly out of scope

This section is just as important as the scope section. A good SOW names the things that are not included: integrations with systems not listed, custom development beyond declarative configuration, training beyond the sessions specified, support after go-live. Explicit exclusions prevent the "I thought that was included" conversations that derail projects.

Timeline and milestones

The timeline should include named milestones with dates, not just a total project duration. Discovery complete. Configuration complete. UAT begins. Go-live. Each milestone should have a clear definition of what "complete" means. Milestones create accountability on both sides and give you natural checkpoints to assess whether the project is on track.

Client responsibilities

This is the section most clients skip over, and it is one of the most important. A Salesforce project requires active participation from your team. Someone needs to be available for discovery sessions. Someone needs to review and approve configuration. Someone needs to provide test data and participate in user acceptance testing. Someone needs to make decisions when requirements are unclear. If those responsibilities are not defined and staffed, the project will stall.

Change order process

Scope changes happen on almost every project. The question is not whether they will happen but how they will be handled. A good SOW defines the process: how changes are requested, how they are evaluated, how they are priced, and how they are approved. Without this, every change request becomes a negotiation that slows the project and strains the relationship.

Acceptance criteria

How will you know when the project is done? Acceptance criteria define the conditions under which the client signs off on each deliverable. They should be specific and testable. Not "the system works correctly" but "all 47 test cases in the UAT script pass without critical defects." Clear acceptance criteria protect both parties.

Red Flags to Watch For

• Deliverables described as hours of effort rather than specific outputs — "40 hours of configuration" tells you nothing about what you will receive
• No out-of-scope section — if everything is potentially in scope, nothing is truly defined
• No client responsibilities section — this usually means the consultant has not thought through what they need from you
• Vague acceptance criteria like "client satisfaction" or "system performs as expected" — these are not measurable
• No change order process — this is how projects quietly double in cost
• Timeline with no milestones — a single go-live date with no checkpoints means you will not know the project is in trouble until it is too late

Fixed-Price vs. Time-and-Materials

Most Salesforce consulting engagements are structured as either fixed-price or time-and-materials. Fixed-price gives you budget certainty but requires a well-defined scope upfront. Time-and-materials gives you flexibility but puts the budget risk on you.

For well-defined projects with stable requirements, fixed-price is usually the better choice for the client. For exploratory work, ongoing support, or projects where the requirements are likely to evolve, time-and-materials with a not-to-exceed cap is often more appropriate.

The pricing model matters less than the clarity of the scope. A fixed-price contract with a vague scope is not actually fixed-price in practice, because every ambiguity becomes a change order. A time-and-materials contract with a detailed scope and a disciplined change process can be just as predictable.

Before You Sign

Read the SOW carefully. Ask questions about anything that is unclear. If a section is missing, ask why. A consultant who is uncomfortable with specific scope, clear deliverables, and defined acceptance criteria is telling you something important about how they work.

The best consulting relationships start with a document that both sides understand and agree to. The SOW is not bureaucracy. It is the foundation of a project that actually delivers what you need.