What a Good RFP Should Achieve
The purpose of an RFP isn't to get a price. It's to obtain comparable proposals and identify which vendor truly understands the problem. A document detailing a hundred requirements and asking for "supports / doesn't support" checkboxes achieves the opposite: all vendors check "supports," and the decision boils down to price.
Practical difference: Instead of writing "The system will allow opportunity management," describe that the company manages about four hundred deals a month, each deal passes through a pricing approval, and this approval currently happens via email. Vendors will return very different answers—and that's precisely the point.
The Nine Sections of a Salesforce RFP
1. Background and Business Objectives. What the organization does, what the problem is, and what success will look like in a year. One paragraph to one page.
2. Current State. Systems in use, number of users, what works today, and what doesn't. If there's an existing Salesforce environment, specify edition, age, and customization level.
3. In-Scope Core Processes. Three to seven processes, each in a paragraph: who performs it, what the decision points are, what happens when something deviates.
4. Volumes and Data. Number of records for each central entity, monthly creation rate, years of history to retain, and known data quality status. This section has the most impact on pricing accuracy and is most often skipped.
5. Integrations. For each system: name, interface type if known, direction, required frequency, and its owner within the organization.
6. Constraints. Regulation, information security, storage location, languages, accessibility, immovable timelines.
7. What is Required from the Bidder. Proposed approach, wave plan, team composition with names and roles, assumptions, risks, and pricing according to a fixed structure.
8. Evaluation Method. Criteria and weights, published in advance. This generates focused proposals and reduces arguments after the award.
9. Tender Schedule. Questions due date, answers due date, submission due date, demo date, decision date.
Data You Must Disclose to Get Real Pricing
| Data Point | Why it's Critical | What Happens Without It |
|---|---|---|
| Number of users by type | Determines licensing, training, and permissions | Proposals with too wide a range |
| Record volume and history | Determines migration effort | Migration priced with rough estimate |
| Number of source systems | Determines complexity and integration | Surprises after signing |
| Level of existing documentation | Determines how much discovery is needed | Vendors assume existing documentation |
| Availability of process owners | Determines decision pace | Unrealistic timeline agreed by both sides |
| Budget or range | Focuses the solution | Proposals that are not comparable |
Questions that Distinguish Vendors
The following questions elicit very different answers from various vendors, making them useful. A question everyone answers identically isn't worth space in the document.
- What are the three main assumptions your proposal is based on, and what is the impact if one of them is incorrect?
- In what cases would you recommend configuration even if development would work better, and vice versa?
- Describe a project where you exceeded the timeline. What caused it, and what have you changed since?
- Who will be the actual team members, and what percentage of time will each dedicate to this project?
- What do you need from us to succeed, and what will you do if you don't get it?
- How will you transfer the ability to maintain the system without you?
The last question is a good test of the engagement's nature. A vendor who dodges it is planning for dependence.
What to Demand as a Deliverable Within the Proposal
- Preliminary architectural diagram at the block level, including sources of truth.
- Wave plan with the content of each wave, not just dates.
- Detailed pricing in a uniform structure that you dictate, by phase and by role.
- Explicit list of assumptions.
- Risk map with mitigation strategies.
- Example of a real deliverable from a previous project, anonymized — for example, a decisions document or a test plan.
The last item is perhaps the most distinguishing, as it shows a standard of work rather than a promise.
Uniform Pricing Structure — The Tool that Prevents Apples-to-Oranges Comparisons
Define the table that every bidder must complete:
| Phase | Senior Hours | Junior Hours | Cost | What is Considered Complete |
|---|---|---|---|---|
| Discovery | ||||
| Configuration and Development for Wave 1 | ||||
| Integrations | ||||
| Data Migration | ||||
| Testing and UAT | ||||
| Training and Adoption | ||||
| Post-go-live stabilization | ||||
| Project Management |
A vendor who refuses to break down the price according to this structure is not necessarily expensive—but they cannot be compared, and that's a sufficient reason to demand it.
Illustrative Example: A Medium-Sized Provident Fund
This scenario is hypothetical and illustrative. A financial institution issued an RFP that included eighty functional requirements in a table. The four bidders checked "supports" on almost every line, and the proposals differed only in price and number of hours.
In a second round, the document was changed: instead of the requirements table, it included three fully described processes, actual volume data, and a request to solve one scenario in a demo. The proposals received differed significantly—one proposed a completely different data model, another identified a dependence on regulatory approval that no one had thought of.
The committee did not choose the cheapest proposal and did not regret it. They chose the one that successfully explained why the seventh requirement in the original document was not needed at all.
Common Mistakes in RFP Writing
- Copying a document from another project without adapting volumes and processes.
- Requesting a client list instead of deliverable examples.
- Evaluation criteria formulated after proposals are received.
- A timeline that doesn't allow time for questions and answers.
- A hidden preference for an existing vendor, which causes others to invest in vain and harms the quality of future proposals.
What Happens After Submission
A good document is only half the work. The next step is normalizing the proposals and comparing them on the same basis, as detailed in the Salesforce Proposal Comparison Guide, and then structured scoring according to pre-defined weights, as detailed in the Vendor Scorecard Guide.
The information base for writing the document itself usually comes from a short consulting process, as described in the Salesforce Consulting Guide, and the criteria for vetting the company are summarized in the Choose Salesforce Implementation Company Guide.
Next Step
Before you send the document, do one check: give it to someone in the organization not involved in the project and ask them to explain in a sentence what problem you are trying to solve. If they can't, neither will the vendors—and they'll simply return what they're used to selling.