Salesforce RFP Template
Structure a Salesforce request for proposal that partners can answer properly: what to include in each section, example rows, and how to compare responses fairly.
A weak RFP produces proposals that cannot be compared. One partner prices a full rebuild, another prices a configuration tweak, and both are answering the same vague sentence. A good Salesforce RFP gives every respondent the same picture of your current state, your goals and your constraints, then asks them to answer in the same shape.
Use the sections below as a template. Replace the guidance with your own content, keep the headings, and delete anything that genuinely does not apply.
1. Background and context
Describe the organisation in a paragraph, then the situation that triggered the RFP. Name the Salesforce products you already own (for example Sales Cloud, Service Cloud, Marketing Cloud Engagement, Account Engagement or Data Cloud), how long they have been in use, and who supports them today. Be honest about known problems; partners plan better when they know about the technical debt.
2. Objectives
List three to five business objectives, each with how you will know it has been met. "Reduce manual lead assignment" is better than "improve sales efficiency", and "sales managers can see pipeline by region without exporting to spreadsheets" is better still.
Sections 3 to 6: what the partner needs to scope
- 01
3. Current state
Users by role and region, org count, key customisations, integrations, data volumes for the main objects, and any known limits you are hitting. Attach an org health summary if you have one.
- 02
4. Scope
What is in scope and, just as important, what is out of scope. Split into phases if you already know the order. Mark items you are unsure about as 'for partner recommendation'.
- 03
5. Requirements
Functional and non-functional requirements in a numbered list with a priority for each. See the example rows below.
- 04
6. Integrations and data
Every system Salesforce must talk to, the direction of data flow, frequency, the owner of each system and whether APIs are documented. Include migration volumes and data quality concerns.
Example requirement rows
| ID | Requirement | Priority | Notes |
|---|---|---|---|
| REQ-01 | New web leads are assigned to the correct regional queue within the working day | Must | Region derived from country and postcode |
| REQ-02 | Marketing consent captured on web forms is visible on the Contact record | Must | Consent wording versioned |
| REQ-03 | Service agents see open orders from the ERP on the Account page | Should | Read only; ERP is system of record |
| REQ-04 | Weekly pipeline dashboard by region and product line | Should | Replaces current spreadsheet |
| REQ-05 | Single sign-on through the corporate identity provider | Must | Identity provider named in appendix |
| REQ-06 | Field history kept for key Opportunity fields | Could | Confirm retention needs |
Priorities using Must, Should, Could and Won't make trade-offs visible. If more than about half your requirements are marked Must, the list probably needs another pass.
7. Constraints and compliance
State security, privacy and compliance expectations: data residency, regulations that apply (such as GDPR or India's DPDP Act), access rules for partner staff, sandbox policies, and any procurement or contract terms the partner must accept. Ask how they handle production access and credentials.
8. Delivery expectations
Say how you want to work: preferred methodology, the roles you will provide (product owner, testers, data owners), expected time commitment from your side, environments available, and the support you need after go-live.
9. Response format
Ask every partner to answer in the same order and to state assumptions explicitly. A typical response structure:
- Understanding of the problem in their own words
- Proposed solution approach and architecture
- Delivery plan, phases and the roles they will assign
- Assumptions, dependencies and risks
- Commercial proposal with what is included and excluded
- Relevant experience, described in a way you can verify through references
- Named contacts for clarification questions
Example evaluation criteria
| Criterion | What good looks like | Example weight |
|---|---|---|
| Understanding of the problem | Restates your goals accurately and challenges weak assumptions | 20% |
| Solution approach | Uses standard platform features first; justifies custom code | 25% |
| Delivery plan and team | Realistic phases, named roles, clear dependencies on you | 20% |
| Risk and assumptions | Lists specific risks with mitigations | 15% |
| Commercials | Transparent about what is fixed, what is variable and why | 20% |
Questions we hear
Should we include a budget range?
How long should partners have to respond?
Should we ask for a fixed price?
How many partners should we invite?
Related reading
Preparing a Salesforce RFP?
We can review your draft for clarity and gaps before it goes out, or respond to it as a candidate partner.
