What Truly Breaks Contracted Projects
Almost no conflict in a Salesforce project begins with the question "How much does it cost?" It starts with the question, "Is it done?" The vendor believes the deliverable has been submitted; the organization believes it's unusable. Both sides are correct within their own perception because no one defined beforehand what "completed" actually means.
This leads to one principle that guides all sections in this article: A good contract doesn't protect your side in a conflict—it prevents the conflict.
Twelve Essential Clauses
1. Acceptance Definition for Each Deliverable
This is the most critical clause. Every deliverable requires an observable criterion: not "customer management screen," but "a user with profile X can execute scenario Y and achieve result Z, as defined in the approved acceptance criteria."
Recommended phrasing: A defined testing period begins upon delivery, at the end of which the client either approves or details the discrepancies in writing. Silence beyond this period is considered approval—a clause that protects the vendor and instills discipline in the client.
2. Change Request Mechanism
Defines who is authorized to request, who evaluates, within what timeframe, and at what rate. The rate must be established at signing, not when the need arises.
3. Bidirectional Dependency
Most contracts define what happens when the vendor is delayed but not what happens when the client is delayed. Result: when an organization is late with approval, the vendor absorbs the impact—and then recoups it through change requests.
Balanced phrasing: The timeline is contingent on defined client responsiveness (approval time, process owner availability, data delivery), and an undue delay shifts the milestone with written notice.
4. Ownership of Code, Configuration, and Documentation
Separation between specific deliverables and the vendor's generic components, with a perpetual, unlimited use license for generic components that is not contingent on continued engagement.
5. Documentation as a Mandatory Deliverable
Documentation not defined as a deliverable with acceptance criteria either won't be written or will be rushed in the final week. Define a minimum: architectural decisions, data model, integration mapping, operational procedures.
6. Warranty and Defect Correction
A defined period and a sharp distinction between a defect and a change. A working definition: A discrepancy between actual behavior and approved acceptance criteria is a defect.
7. Key Personnel
Names, allocation percentage, advance notice for replacement, and equivalent professional level with client approval.
8. Access, Environments, and Information Security
Who gets access to which environments, for how long, what happens to access upon completion, and how real data is handled in non-production environments.
9. Compliance with Regulatory and Privacy Requirements
Storage location, personal data handling, audit rights, and security incident reporting. In regulated organizations, this clause requires specific tailoring, not a template.
10. Go/No-Go Gates and Exit Points
The right to pause at the end of a defined milestone, with a predetermined payment arrangement. Such a clause reduces risk for both parties, so a good vendor won't object to it.
11. Knowledge Transfer
Not "training," but rather: number of hours, to whom, on what, and what the deliverable is. It's preferable for the transfer to be spread throughout the project rather than concentrated at the end.
12. Termination and Exit
A list of what is delivered, format, overlap period, and rate for support hours during transfer. This is the clause no one wants to discuss at signing, which is precisely why it's worth insisting on it then.
Risk Map: What Each Clause Prevents
| Clause | Failure It Prevents | Cost of Absence |
|---|---|---|
| Acceptance Definition | "Finished" debate | Payment delays and go-live delays |
| Change Requests | Pricing under duress | Uncontrolled cost overruns |
| Bidirectional Dependency | Mutual blame for delays | Untransparent timeline shifts |
| Ownership & Documentation | Vendor dependency | High cost in case of vendor change |
| Key Personnel | Quiet team replacements | Loss of relationship and knowledge |
| Warranty | Defect vs. change disputes | Double payment for fixes |
| Exit | Negotiation from a weak position | Unforeseen transfer costs |
Phrasing to Avoid
- "The vendor will perform the work with acceptable professionalism" — unenforceable without criteria.
- "The parties will agree later on..." — every such clause is a future conflict waiting to happen.
- "Subject to full client cooperation" — without defining what that means, it's a unilateral defense.
- "The deliverable will be submitted at project completion" — without defining what completion entails.
- Payment schedule based on calendar dates instead of acceptance.
Illustrative Example: Retail Chain
This scenario is hypothetical and illustrative. A retail chain signed an SOW that included "customer data migration from an existing system." The organization assumed the migration included duplicate cleansing; the vendor assumed they were migrating what was provided to them.
In reality, hundreds of thousands of records with duplicates were migrated. Both parties read the same sentence and interpreted it oppositely. There was no line in the contract defining what constituted a valid record.
The correction made in subsequent agreements by that same chain was brief: an appendix defining a measurable quality threshold for loading—a validation pass rate for records, duplicate identification rules, and who approves. This appendix replaced dozens of hours of debate.
What to Check Before Signing
- Every deliverable in the proposal appears in the SOW with acceptance criteria.
- Every assumption presented in the proposal appears as an explicit assumption in the contract.
- The payment schedule is linked to acceptance.
- There's an exit clause and a knowledge transfer clause.
- The defect definition is clear enough to resolve a borderline case.
What was agreed upon during proposal comparison but not included in the contract simply doesn't exist. The comparison process itself is detailed in the Salesforce Proposal Comparison Guide, and the basis for formulating requirements is established in the RFP document, as detailed in the Salesforce RFP Guide.
Connection to Vendor Selection
Some clauses here also serve as evaluation tools: a vendor who objects to a documentation ownership clause or an exit clause tells you something about their operating model. The combination of professional evaluation and contractual readiness is scored together in the Salesforce Vendor Scorecard Guide, and the broader criteria for vetting a company are consolidated in the Choose a Salesforce Implementation Company Guide. Aligning the type of engagement with the type of service purchased is detailed in the Salesforce Services Guide.
Next Step
Take the SOW in front of you and mark every instance where "will be delivered" or "will be performed" appears without an accompanying explanation of how to know when it has happened. Each such mark represents a potential conflict, and each one takes five minutes to fix now.