How to choose a Salesforce implementation partner
Choose a Salesforce implementation partner on points that proposals often leave out, rather than on presentation polish and partner-selected references: how thoroughly the partner investigated your processes before pricing them, which people fill the key roles from day one, how the partner ties quality to milestones and whether you could continue without them. As an architect on the client side I have seen partners replaced more than once. Many of the reasons were visible in the proposal.
Why references tell you little about an implementation partner
References are briefed by the partner. No partner will name the project where things went badly wrong. That is not an accusation: every implementation partner has skeletons in the closet, and anyone who claims otherwise has done few projects or is not telling you everything.
The figures on AppExchange help with the shortlist (Trailhead1). The satisfaction survey after the project goes to the contact the partner itself enters, and terminated projects do not count towards the average (Salesforce Partner Community2).
What the AppExchange listing shows
The better question is: which project went wrong for you, what did you learn, and how can I see that it will not happen again? A partner with a concrete answer, a changed rule or a new review step, has done something with its mistakes. If you can, also talk to a former customer who is not on the reference list.
Which warning signs show up in the proposal?
I have seen each of the following points in proposals, and each one made itself felt later in the project.
Warning signs in a Salesforce partner's proposal
The first point is often underrated. In my cases the fixed price was too optimistic, and the client did not even know which functions the individual work packages contained and whether they covered its needs. When a process then turns out to be missing, the price no longer covers the actual scope, and the protection of the fixed price erodes with every change request. How fixed price and time and materials shift now that partners build with AI is covered in fixed price vs. time and materials.
The discovery decides how reliable the estimate is
An estimate without any discovery has become rare. A discovery that stays on the surface is more common: I have seen estimates for which only the happy path was discussed, the standard case done by the book. At manufacturers, though, the effort often sits in the edge cases.
Discovery only for the happy path
- Only the standard case done by the book is discussed.
- Devices without a serial number, orders spanning two plants or own framework agreements are missing.
- Rules, data model and interfaces for them are in no estimate.
- The edge cases come back later as change requests.
Discovery with edge cases
- The list of special cases comes with the proposal.
- Assumptions behind the estimate and open decisions are written down.
- You see before the award what the price covers and what it does not.
So do not ask whether a discovery took place; ask to see this evidence. If the partner cannot show any of it, you have no evidence that edge cases were covered.
Part of the responsibility lies with the client. In every one of my projects, user acceptance testing took longer than planned, because the client’s people were not available, and change requests followed because the business had not looked closely enough at its own solution and the status quo beforehand. So also ask the partner what it expects from you: which process owners it needs and for how many days, when you have to make which decisions, and who prepares the test cases, provides test data and tests.
The team in the pitch is not automatically the team on the project
The pitch brings the experienced people. On the project, in my cases, the team was then very mixed, with many juniors. That is not bad in itself, juniors need projects. It becomes bad when nobody experienced reviews their work and the client only notices in the quality.
That gives you the questions for the pitch. Who fills the key roles from day one, by name and share of time, and what seniority does the rest of the team have? Who has implemented exactly this product and the scenarios you need, which for a manufacturer often means installed base and asset hierarchies, spare parts from the ERP or scheduling for field technicians? And who takes over when a key person leaves, and who pays for the onboarding?
How do you ask about quality without giving away the answer?
Ask “Will you work in our repository to our standards?” and every partner says yes. So I ask these questions indirectly: I describe a problem and let the partner explain how they would solve it. A partner with a good approach then describes it as their solution without me prompting it. Code review and test rules rarely appear in a proposal, and especially now that partners code with AI tools, a partner should explain unprompted how it reviews every change, whoever or whatever wrote it.
- Milestones and quality. “How do your project milestones connect with delivery and quality gates?” Good answers name concrete checks: code review, test coverage and automated checks in the pipeline, but also data migration, integration tests and readiness for acceptance testing. A milestone only counts as technically complete once they all pass; the business acceptance comes on top, with its own criteria. More in quality gates for AI code and partners using AI coding.
- A second partner. “In two years another partner joins for Field Service. How do we keep the two from overwriting each other?” Good answers mention pull requests, an object ownership matrix and a shared sandbox strategy.
- Taking over after go-live. “We want to run the platform ourselves later. What do we get from you then?” This shows whether code, configuration and documentation are meant to sit with you or stay with the partner.
What belongs in the contract with the partner
What sounds good in the pitch has to go into the contract, or it does not count. These points belong there at a minimum:
- Named key roles, swaps only with your consent, an equivalent replacement and a handover period at the partner’s cost.
- Ownership and access: code, metadata, documentation and pipeline configuration built for you belong to you from the start, with admin access to repository and pipeline. For the partner’s accelerators and templates, the contract states your right of use.
- Quality gates with defined checks for the technical completion of every milestone, with the evidence the partner delivers.
- Assumptions and exclusions of the estimate, and a rule for edge cases the discovery did not cover: who assesses them, and under what conditions do they become change requests?
If several partners work on one org, there is one more question: who sets the rules for all of them. In my largest programme, five partners worked with more than 30 developers on one org, and the standards came from the client side, as described on the partner governance page. When an independent architect makes sense for this is covered in Salesforce freelancer or consultancy.
First step: write down three problem cases for every partner
Before you invite partners, decide what you will measure them on and give all of them the same cases from your own programme.
- 01
Write down cases
An edge case from your process, a second partner joining, a key person on the partner side leaving.
- 02
Set criteria
The same criteria for every partner, so the best presentation does not win by default.
- 03
Play the cases
Each partner explains how it would handle the same three cases.
- 04
Ask for evidence
Key roles by name, the list of special cases from the discovery, the assumptions behind the price.
Sources2
- 1Trailhead (opens in a new tab)trailhead.salesforce.com
- 2Salesforce Partner Community (opens in a new tab)partners.salesforce.com
Frequently asked questions
How do I find a Salesforce implementation partner?
For a shortlist, use the consultant section on AppExchange and filter by product, industry and location. Base the decision on the discovery, the named team and the answers on quality assurance, not on stars and partner tier.
Does the partner tier (Summit, Crest, Ridge) say anything about quality?
Only to a point. The tier follows a score made up of several attributes, including the average customer satisfaction of completed projects, certifications and Navigator status. It says little about how the team assigned to you will work.
Fixed price or time and materials: which is better with a Salesforce partner?
A fixed price protects you when the discovery knows the edge cases of your processes and the proposal lists its assumptions, exclusions and acceptance criteria. Otherwise the risk comes back to you through change requests.
What if the partner replaces key people after the project starts?
Settle it in the contract beforehand: named key roles, your consent to any swap, an equivalent replacement and a handover period paid by the partner. Without that rule you usually notice the change only in the quality.