Why Salesforce Proposals Are Almost Never Comparable
When you lay three proposals side by side and see a difference of tens of percentages, the instinct is to assume one of them is inflated. In most cases, the reason is simpler: each proposal prices a different project.
One vendor included three years of history migration, the second assumed one year. One included six weeks of stabilization after go-live, the second delivered and departed. One counted four integrations, the second two, because they assumed a daily report instead of a live interface. Neither of them misled – they simply weren't told otherwise.
Comparison therefore begins with normalization, not a price table.
A Six-Step Normalization Method
1. Define a uniform list of components. Eleven lines are sufficient: discovery, configuration, development, integrations, migration, testing, training, project management, stabilization, documentation, knowledge transfer.
2. For each proposal, mark what is included, what is partial, and what is missing. Do not fill in amounts at this stage.
3. Price the missing elements. For any component not included in a proposal, use a cost from another proposal as an estimate and add it.
4. Align assumptions. Number of users, edition, years of history, number of business units, languages.
5. Align warranty periods. A different period is worth money. A two-month difference in stabilization is a real cost component.
6. Calculate average hourly cost and team mix at each stage, not in total.
Only after these six steps can you compare numbers. In many cases, the proposal that seemed cheaper moves to second place.
Components That Disappear from Proposals – and Appear on the Bill
| Component | Why It's Omitted | Relative Order of Magnitude |
|---|---|---|
| Data cleansing before migration | Considered the client's responsibility | Often very significant |
| Second UAT round | Assumes one round | Low but blocks schedule |
| Role-based training | Priced as a single workshop | Medium |
| Increased support in the first weeks | Not defined | Medium to High |
| Organizational ownership of documentation | Considered self-evident | Low, critical later |
| Integration error handling and monitoring | Only includes the "normal path" | Medium |
| Environments and DevOps | Assumes they exist | Low to medium |
| Internal organizational management hours | Not in the proposal at all | High, and always present |
The last line is the one that surprises management. A Salesforce project consumes significant time from process owners and the PMO, and this is a real cost even if it doesn't appear on any invoice.
From Price Comparison to Three-Year Cost Comparison
A proposal is correctly evaluated over three years, not just for the project duration. A simple calculation structure:
| Component | Year 1 | Year 2 | Year 3 |
|---|---|---|---|
| Implementation cost | Full | — | — |
| Licensing | By number of users | Includes projected growth | Includes projected growth |
| Maintenance and support | Partial | Full | Full |
| Planned enhancements | — | Estimated scope | Estimated scope |
| Internal management cost | High | Medium | Medium |
The difference between proposals in the first year seems large. Over three years, what usually matters is how easy it will be to change the system without the vendor – meaning, the quality of documentation and handover, which are almost never factored into the decision.
Red Flags in a Proposal
- Data migration priced at a round figure with no questions about volume or quality.
- No warranty period, or defined as "bug fixing" without defining what a bug is.
- A proposal that only includes development hours and no project management line item.
- Team composition without names, or names that are not contractually committed.
- An unusually low price for the discovery phase, which is sometimes a gateway to a project that will be priced later.
- No explicit assumptions. A proposal without assumptions is an untested proposal.
Illustrative Example: Renewable Energy Company
This scenario is hypothetical and for illustration. A company received three proposals. The difference between the cheapest and most expensive was about eighty percent. The committee was leaning towards the cheaper option.
After normalization, it became clear: the cheaper proposal included no migration at all, only loading of active records; it assumed two integrations instead of four, believing financial reporting would be done via manual export; and its warranty period was two weeks compared to eight weeks in the expensive proposal.
After adding the missing costs from the other bidders, the gap narrowed to about ten percent. The decision ultimately made was not based on price but on the question of who offered structured knowledge transfer, as the company had no internal team.
What to Do with the Remaining Gap
After normalization, a real gap usually remains. Translate it into questions, not assumptions:
- Why is your estimate for integration lower than others' – what do you know that they don't?
- What happens if the assumption about data quality is incorrect?
- How many testing rounds did you plan?
- Which of the presented team members will accompany the project from start to finish?
Answers to these questions differentiate between a vendor who priced cheaply because they are efficient and a vendor who priced cheaply because they didn't understand.
Connecting to the Final Decision
An organized comparison provides only the commercial aspect. The professional aspect is scored separately, according to pre-defined weights, and price is just one of them – details are in the Guide to Choosing a Salesforce Implementation Company. Understanding what constitutes the cost in the first place is detailed in the Guide to Salesforce Implementation Cost, and choosing the engagement model in the Project Pricing Models Guide.
What is agreed upon in the comparison must be accurately worded in the contract, otherwise it does not exist – the relevant clauses are summarized in the Guide to Salesforce SOW and Contract Clauses.
Next Step
Build your normalization table before you open the price envelopes. Anyone who builds it after seeing the amounts will – unintentionally – build it to justify the proposal they already favored.