A Salesforce RFP can produce a strong implementation plan and still leave the buyer with a delivery model that fails at the first contested decision. The important Salesforce RFP operating model decisions are usually made before a supplier has written its estimate: who can decide, who must be consulted, who owns the platform after go-live, and what evidence changes a decision.
Those questions are often spread across a governance slide, a staffing appendix, and a line in the contract. That makes them easy to admire and hard to enforce. Treat them as part of the solution design instead.
Put decision rights in the RFP, not in the kickoff deck
An RFP should ask a bidder to describe decision rights at the points where a programme can stall or diverge. A generic RACI is not enough. It can name an accountable executive while leaving open whether that person can resolve a conflict between a global data standard, a local commercial requirement, and a vendor delivery dependency.
Ask for a decision register from the start. Each entry should name the decision, the owner, the contributors, the evidence required, the deadline, the escalation route, and the consequence of delay. The register turns abstract governance into a working control. It also gives the sponsor a way to distinguish a real dependency from a supplier preference.
The RFP should test this with scenarios. For example: a business unit requests a change to a shared Account model after build has started; an integration owner rejects an API contract proposed by the Salesforce team; a security control conflicts with a release target. A credible response names the person who decides and the artefact that informs that decision. “The steering committee will align” is not a delivery method.
Decision rights also need a boundary. The implementation partner can recommend a design and own delivery commitments. It should not become the final authority on the buyer’s data policy, target operating model, or risk acceptance. If internal ownership is absent, the contract does not repair the gap. It only records it.
Separate solution authority from delivery management
Many RFPs ask for a programme manager, a solution architect, and a delivery team. They do not ask how those roles disagree. That omission matters more than a polished organisation chart.
The solution authority should own the integrity of the design: data model boundaries, integration contracts, security constraints, non-functional requirements, and exceptions to standards. Delivery management should own the plan, dependencies, delivery forecast, and the path to recover missed commitments. Business owners should decide whether the proposed outcome remains worth the cost and change effort.
These responsibilities overlap, but they are not interchangeable. A delivery lead can expose the impact of a late design decision. They should not quietly make that decision to protect a milestone. An architect can explain why a local configuration creates a shared-platform risk. They should not choose the business priority without the accountable business owner.
Salesforce’s Architecture Decision Guides provide a useful reference for framing architecture choices, while its diagram library shows how dependencies and implementation order can be made visible. In an RFP, the test is not whether a bidder links to those resources. The test is whether its proposed team can turn a choice into a bounded decision with an owner, assumptions, acceptance criteria, and a recorded outcome.
The buyer should require a named design authority on both sides. On the customer side, that authority needs access to business sponsors and the mandate to reject a locally convenient design that damages a shared capability. On the supplier side, the named architect needs enough time in the delivery model to govern the work, rather than appearing only for an early workshop and a late escalation.
Make handover an operating-model acceptance criterion
A Salesforce programme does not end at deployment. The commercial model often assumes a handover, but the RFP rarely defines what the customer must be able to operate without the delivery team.
Set acceptance criteria for the operating model alongside functional acceptance criteria. They can include an owned decision log, named owners for integrations and critical metadata, a release process, a support triage route, a backlog ownership model, and accessible records of material design choices. The exact set depends on the organisation. The point is to make operational ownership observable before the supplier’s role changes.
Ask bidders to identify which responsibilities remain with them after go-live, which transfer to internal teams, and which require a retained service. Then ask what knowledge, documentation, access, and rehearsal make that transfer credible. A transition plan that lists meetings is weak. A transition plan that identifies the incoming owner, the decision they must take, the evidence they need, and the date they assume authority can be tested.
This matters most where a platform spans business units or delivery partners. Without a shared owner for cross-cutting concerns, local teams optimize their own backlog. Integration debt and inconsistent data definitions follow. The Salesforce Center of Excellence design guide explains the operating layers that can hold those concerns without routing every request through a central committee.
Score the commercial model against its control model
Rate cards, blended day rates, and delivery velocity estimates matter. They do not show how a supplier behaves when a decision changes the commercial plan.
The RFP should ask bidders to state which events change scope, which events trigger a forecast revision, and who has authority to approve a trade-off between cost, date, and design integrity. The answer should connect contractual change control to the programme decision register. Otherwise the project has two versions of reality: the delivery plan and the commercial process.
Review the incentives as carefully as the estimate. A supplier rewarded only for utilization may defer difficult design work until it becomes an expensive exception. A supplier rewarded only for speed may produce a release that transfers risk into the support team. Neither outcome proves bad intent. Both are predictable when the operating model leaves quality, ownership, and recovery outside the commercial conversation.
A useful comparison is a short scenario review with each shortlisted bidder. Give the same constrained case to every team: an integration dependency is late, a sponsor requests a new priority, and the original go-live date remains visible to leadership. Ask for the next two weeks of decisions, not a generic recovery framework. Compare the assumptions they challenge, the people they involve, the evidence they request, and the commitments they refuse to make without approval.
Use the first month to test the RFP promises
The RFP creates hypotheses. The mobilisation period should test them before design and build work makes reversal costly.
Confirm that the named roles attend the forums they were proposed to lead. Check whether the decision register has clear owners and whether escalations reach a decision before they become planning noise. Test one cross-team design decision from request through evidence, approval, recording, and communication. If the result depends on informal access to one supplier leader, the proposed model is less resilient than the bid suggested.
Do not wait for a major issue to find out whether governance works. A small, real decision is enough to show whether the buyer’s authority, the supplier’s delivery method, and the commercial controls connect. If they do not, correct the operating model while scope is still limited.
Key takeaways
- Put decision owners, evidence, escalation routes, and delay consequences into the RFP response requirements.
- Solution authority and delivery management need separate mandates, even when one person contributes to both conversations.
- Handover is complete only when incoming owners can make and record the decisions that the delivery team previously made.
- If a bidder’s commercial controls and programme controls do not refer to the same decision record, expect disputes to surface late.
- Test the operating model with a real cross-team decision during mobilisation, then repair the gaps before the programme scales.
