Salesforce SOW Template: Scope, Assumptions and Pricing Models

Most Salesforce statements of work are assembled from a template somebody downloaded, adjusted once, and has reused since. They are usually weaker than they need to be, and the quickest way to see where is to read the contract Salesforce itself signs.

Salesforce publishes its Professional Services Agreement. It is the terms under which Salesforce sells implementation and advisory work to its own customers, and it is specific in exactly the places partner SOWs are vague.

Salesforce publishes the contract it uses, and it protects the supplier carefully

The Professional Services Agreement is linked from Salesforce’s own customer agreements page and was last updated on March 8, 2024. It governs the purchase and receipt of Salesforce professional services, and it binds a customer on either a click-through acceptance or the execution of a statement of work or order form that references it.

Read it as a benchmark rather than as a template to copy. Salesforce is the supplier in that document, so every clause is drafted from the supplier’s side, which is the side a partner SOW is written from too.

Five of its provisions are worth comparing against whatever SOW you are currently sending out. Each one closes a gap that costs partners money, and in every case Salesforce has written the protective version while most partner templates have the loose version.

Client delay is a billable event in Salesforce’s own agreement

Start with the clause that recovers the most margin, because it is the one almost no partner SOW contains.

Section 3.2 of the agreement, headed Delays, reads: if SFDC is unable to perform the Professional Services due to a Customer delay, including failure to comply with Section 3.1, Customer may be responsible for additional resource fees.

That sentence does two things at once. It establishes that a client-caused delay has a cost, and it ties that cost to a specific list of client obligations rather than to a judgment call about whose fault something was.

Compare the usual partner equivalent, which is a line in the assumptions saying the client will provide timely access to stakeholders. That is a hope. It has no consequence attached, so when the client takes three weeks to approve a sharing model, the partner absorbs three weeks and reports it as project slippage. The approval delay that caused it never appears in a commercial conversation.

What makes the Salesforce version work is that the obligations it refers back to are enumerated. Which brings us to the next clause.

Customer obligations are enumerated, not assumed

Section 3.1 lists what the customer must do, in three named groups, and the specificity is the point.

On resources, the customer assigns an internal project manager as primary point of contact for each project and allocates sufficient resources to meet its obligations under each SOW.

On actions, the customer promptly responds to inquiries, provides accurate information, data and feedback as necessary, actively participates in scheduled meetings, and where the project requires it, provides appropriate administrative access to the customer’s Salesforce account.

On facilities, the customer provides at no charge office workspace, access to other facilities where needed, and suitably configured computer equipment with Internet access.

Three details in that list reward attention. A named internal project manager is a single point of contact, which removes the commonest cause of stalled decisions. Administrative access is called out explicitly, because a project cannot proceed without it and asking later turns into a security conversation. And at no charge forecloses an argument nobody wants to have about who pays for a desk.

So the obligations section is not boilerplate. It is the thing the delay clause points at, and a delay clause with nothing specific behind it cannot be invoked. Where these obligations come from in the first place is the planning question, and they belong in the plan as dated commitments as well as in the contract, which is covered in the plan that carries them.

A time-and-materials number is an estimate, and the contract says so

This is the clause partners most often get wrong, and Salesforce’s wording is worth reading twice.

Under Section 5.1, professional services are provided on either a time-and-materials or fixed fee basis. Then the qualification: any amount set forth in a time-and-materials SOW is solely a good-faith estimate for the customer’s budgeting and Salesforce’s resource-scheduling purposes, and is not a guarantee that the work will be completed for that amount. The actual amount may be higher or lower. If the estimated amount is expended, Salesforce will continue to provide the services under the same rates and terms.

Three things are happening in that passage.

That number gets labeled. Calling it a good-faith estimate, and saying what it is for, removes the ambiguity that lets a client treat a T&M figure as a cap.

Direction is left open. “Higher or lower” is a fairer framing than a one-way warning, and it is harder to argue with.

And the overrun behavior is pre-agreed. Work continues at the same rates rather than stopping for a renegotiation, which is the clause that prevents a project pausing at the worst possible moment.

A partner SOW that states a T&M figure without this qualification has effectively written a fixed-price contract and called it time and materials. Which pricing model to choose in the first place is a separate decision with its own risk trade-offs, set out in choosing between fixed price, time and materials and outcome-based, and the estimate feeding either one comes from the method that makes a number defensible.

GetGenerative.ai supplies the scope the clauses attach to

Clause quality has a prerequisite that gets skipped, and it is not legal.

A change control clause can only be invoked against a baseline. An acceptance clause can only be tested against stated criteria. A delay clause can only be triggered against enumerated obligations. Every protective provision above depends on a scope statement precise enough to be compared with something, and that scope is usually written last, by whoever is assembling the document, from material that has not been structured.

GetGenerative.ai addresses that upstream half. Discovery output arrives structured rather than as notes, then carries into stories and acceptance criteria in one format. That gives a scope section built from recorded decisions instead of recollection. Reading the org directly matters here too, because a scope statement that names objects and fields which actually exist is harder to dispute than one describing a design assumption.

What it does not do is decide the commercial posture. How hard to press on a delay clause with a client you want a second project from, whether to cap expenses, what acceptance period to offer: those are relationship judgments, and they belong to whoever owns the account. Teams structuring presales this way can see what the platform costs to run.

Change orders require a signature before the work, not after

Section 4.2 is short and the sequencing is the whole clause: changes to an SOW require a written change order signed by the parties prior to implementation of the changes. It names what such changes may cover, including scope of work and any corresponding changes to estimated fees and schedule.

Prior to implementation is the operative phrase. A failure mode it prevents is familiar on every project that has ever run hot. Somebody agrees verbally that a small addition is fine, the team builds it, and the paperwork follows weeks later into a conversation where the client has already received the thing they are being asked to pay for.

Two additions make the clause usable rather than decorative.

Name who may sign. A change order clause that does not identify the authorized signatory on each side produces change orders signed by people whose authority is later questioned.

State what happens to the schedule. Salesforce’s version ties scope changes to corresponding changes in fees and schedule in the same sentence, which stops a client accepting the cost of a change while treating the original date as unaffected. How the date actually moves is a separate calculation, covered in what changes a go-live date.

Expenses need an estimate that only the client can raise

A small clause that resolves an annoying argument.

Section 5.2 has the customer reimburse reasonable travel and out-of-pocket expenses, and then adds the symmetry: if an estimate of incidental expenses is provided in the SOW, Salesforce will not exceed that estimate without the written consent of the customer.

That construction is better than either alternative. Expenses with no estimate invite dispute over every invoice. Expenses with a hard cap mean the supplier eats overruns caused by client-requested travel. An estimate that cannot be exceeded without written consent keeps the client in control of their own costs while leaving the supplier a route to raise them legitimately.

Payment terms sit alongside it. Invoiced amounts fall due net 30 days from the invoice date, which is worth stating explicitly in any SOW rather than leaving to a purchase order someone raises later.

The template holds twelve sections and four carry the commercial risk

With those clauses understood, the structure follows. Twelve sections, conventionally named, and unevenly weighted.

That deliverables row carries more weight than it looks. Salesforce’s agreement defines a deliverable as any output of the professional services identified as a deliverable under an SOW, which means something only becomes a contractual deliverable if the SOW says so. Listing a document in a project plan does not make it one.

Out of scope and client obligations do the work that the assumptions section is usually asked to do and cannot. An assumption is a statement about the world. A client obligation is a commitment by a party. Where the scope itself comes from is covered in the document that fixes it before design.

Salesforce-specific clauses a generic SOW leaves out

A general-purpose services SOW has no field for the things that most often cause disputes on this platform.

Sandbox and environment provision. Which environments the client provides, at which tier, and who pays if an extra one is needed. Entitlement varies by edition and an unplanned sandbox is a purchase.

Data migration scope expressed in objects and passes. “Migrate legacy data” is unpriceable. Named objects, a record volume range, and a stated number of load cycles is a scope. Anything beyond that count is a change order.

Integration endpoints and failure handling. Each interface named, with direction, frequency and what happens on failure. That last one gets omitted most often, and its absence is what turns a failed sync into an argument about whose job it was.

Release window acknowledgement. Salesforce ships three major releases a year and sandboxes move ahead of production. A project spanning a release should say so, and say who absorbs any remediation it causes.

Agent consumption assumptions. Where the scope includes Agentforce, the SOW needs a stated interaction volume and a repricing trigger. Agent work carries a run cost that moves with usage after the build is finished, so a fixed-price agent engagement with no volume assumption transfers an open-ended cost to the supplier. The configure-or-build-or-agent decision behind that scope is covered in the disposition behind that scope line.

Acceptance is the clause that decides when you get paid

Acceptance language is where SOWs are weakest, because it is the clause nobody expects to need.

Salesforce’s agreement does not supply one. Section 4.1 commits only to providing the services and any deliverables in accordance with the agreement and the applicable SOW, which pushes the whole question of when something counts as accepted into the SOW itself. On this clause the benchmark offers no wording to borrow, only the instruction that you have to write it.

Three elements make it function.

A test against stated criteria, not a judgment of satisfaction. Acceptance measured against the criteria in the deliverable is testable; acceptance measured against whether the client is happy is not. Where those criteria are produced and signed off is covered in the cycle that generates the evidence.

A review period with a defined length. Five business days, ten, whatever suits the deliverable. Without one, a deliverable sits unaccepted indefinitely and the payment attached to it sits with it.

Deemed acceptance on silence. If no written rejection with reasons arrives within the review period, the deliverable is accepted. This is the single most valuable sentence in a partner SOW and the one most often missing, because without it a client who simply does not respond has an unlimited free option.

Rejection should require reasons tied to the criteria. A rejection that says it is not what we wanted, with no reference to the stated criteria, is a change request wearing a rejection’s clothes, and the SOW should say which one it is.

Where a Salesforce SOW leaks money

Five patterns, each traceable to a clause that was present but weak rather than absent.

Row two is the most expensive over a year of projects, and it is also the cheapest to fix. Moving three sentences from the assumptions section into a client obligations section, and adding the consequence clause Salesforce uses, changes what happens in every subsequent delay conversation. Where this document sits in the wider sales motion is covered in the presales sequence that produces it.

Questions that come up when the SOW is drafted

What should a Salesforce SOW include?

Twelve sections: parties and term, background and objectives, scope of services, out of scope, deliverables, assumptions, client obligations, pricing and payment, change control, acceptance, expenses, and termination with liability. Four carry the commercial risk: scope, out of scope, deliverables and client obligations.

Does Salesforce publish a statement of work template?

Not a template, but something more useful. Salesforce publishes the Professional Services Agreement under which it sells its own implementation and advisory work, and that agreement is triggered by executing an SOW referencing it. Reading it shows how the supplier side is drafted when the supplier is Salesforce.

What is the difference between assumptions and client obligations in an SOW?

An assumption is a statement about conditions you believe to be true. A client obligation is a commitment by the client, which can be relied on and enforced. Salesforce enumerates obligations including a named internal project manager, prompt responses, participation in scheduled meetings, administrative access, and facilities at no charge, then states separately that customer delay may make the customer responsible for additional resource fees.

How should a time-and-materials SOW describe its value?

As an estimate, explicitly. Salesforce’s agreement calls the amount in a time-and-materials SOW solely a good-faith estimate for budgeting and resource scheduling, states that it is not a guarantee the work will be completed for that amount and that the actual amount may be higher or lower, and provides that if the estimate is expended the services continue at the same rates and terms. A figure without that language functions as a cap.

What does deemed acceptance mean in an SOW?

That a deliverable is treated as accepted if the client does not issue a written rejection with reasons within a stated review period. Without it, an unresponsive client holds an unlimited free option over both the deliverable and any payment linked to it. Rejections should be required to reference the stated acceptance criteria.

What Salesforce-specific clauses does a generic SOW template miss?

Environment provision and who pays for additional sandboxes, data migration scoped by named objects and a number of load passes, integration endpoints with direction and failure handling, acknowledgement that a project spanning a Salesforce release may need remediation, and for Agentforce scope, a stated interaction volume with a repricing trigger because agent run cost moves with usage.