Choosing a Salesforce Implementation Partner
Partner selection often comes down to who presented best. A structured process that tests people, method and fit gives you a better basis for the decision.
Most partner selections are decided in a presentation. The proposals look similar, the slides are polished, and the choice comes down to rapport and price. Six months later the people doing the work are not the people who presented, and the method described in the pitch turns out to be a template.
This guide sets out what to evaluate, how to gather real evidence rather than claims, and how to run a selection that is fair to the partners and useful to you. It applies whether you are comparing large system integrators, specialist consultancies or independent contractors. (We are a consultancy ourselves, so read this with that in mind; the criteria apply to us too.)
First, decide what you need from a partner
Before you look at anyone, be clear about why you need outside help. Common reasons:
- Capacity. You know what to build but do not have enough people.
- Expertise. You need skills your team lacks, such as Data Cloud (now branded Data 360) modelling, Marketing Cloud SQL or integration design.
- Accountability. You want someone to own delivery of a defined outcome.
- Independent view. You want an assessment of an existing org or a second opinion on an architecture.
Each points to a different kind of engagement and a different kind of partner. If you are still deciding whether to build an internal team instead, see our comparison of in-house teams and implementation partners.
What to evaluate and how to test it
| What good evidence looks like | Red flag | |
|---|---|---|
| The actual team | Named people, their roles and time allocation, and a chance to talk to them | Only senior staff in the pitch, team to be confirmed later |
| Relevant experience | Specific explanation of how they handled a similar problem, with permission to contact a reference | Logo walls and generic claims with no detail |
| Method | A clear discovery, build, test and handover process with named outputs | A method slide that looks the same for every product |
| Technical depth | Clear answers to scenario questions about your data and constraints | Confident answers that skip trade-offs or edge cases |
| Handover | Documentation, admin training and knowledge transfer included in scope | Handover treated as optional or charged separately by surprise |
| Commercial clarity | Assumptions, exclusions and change control written down | A low headline price with vague scope |
A selection process that tests substance
- 01
Write a focused brief
Describe your goals, current systems, priority use cases, constraints and timeline. A clear brief gets comparable proposals; our RFP template can help structure it.
- 02
Shortlist a small number
Three or four partners is usually enough. More creates work for you and lowers the effort each partner puts in.
- 03
Run a working session, not a pitch
Give each shortlisted partner a real scenario from your org, such as a data quality issue or a journey design, and watch how they think through it with your team.
- 04
Meet the delivery team
Speak to the people who will do the work. Ask what they would need from you and what worries them about the project.
- 05
Take references properly
Ask references what went wrong and how the partner handled it. Everyone has a good story about what went right.
- 06
Compare on agreed criteria
Score proposals against criteria you set before the session, weighting the team and method above presentation quality.
Questions worth asking
- Who exactly will work on our project, for how many days a week, and who replaces them if they leave?
- What would you need from us in the first two weeks, and what happens if we cannot provide it?
- What are the three biggest risks you see in our brief, and how would you reduce them?
- How do you test before production, and who signs off UAT?
- What documentation and training will our team receive at handover?
- How do you handle a change in scope? Can you show us an example change request?
- How will you access our org, and how do you handle credentials and data? Our page on security and data handling shows the kind of answer to expect.
Credentials and partner status
Salesforce credentials and partner programme status are worth checking, but they tell you about an organisation, not the individuals on your project. Ask for the relevant credentials of the named team members, and ask them about real work. A partner's status in the Salesforce partner programme can be checked through Salesforce's own listings rather than taken from a proposal. Neither replaces a working session.
Mistakes buyers make
- Choosing on day rate alone. A lower rate with a longer timeline or heavy rework often costs more. Compare total cost against a well-defined scope.
- Skipping discovery. Asking for a fixed price before anyone has looked at your data forces partners to either pad estimates or underestimate. A short paid discovery often produces a more reliable plan.
- No internal owner. A partner cannot make your business decisions. Without someone on your side with time and authority, any partner will stall.
- Contracting for features, not outcomes. "Configure Journey Builder" can be delivered without anything useful happening. Tie milestones to working, tested use cases.
- Ignoring the exit. Plan from the start how your team will run and change the system once the partner leaves.
Selection checklist
- Clear reason for using a partner: capacity, expertise, accountability or review.
- A written brief with priority use cases and constraints.
- A shortlist of three or four.
- A working session on a real scenario.
- Conversations with the named delivery team.
- References asked about problems, not only successes.
- Scoring against criteria set in advance.
Related reading
Questions we hear
Should we choose a large integrator or a specialist?
Is a fixed price safer than time and materials?
How many references should we ask for?
Can we use more than one partner?
Considering GeekMidst for your project?
We are happy to run a working session on a real scenario from your org, introduce the people who would do the work and be clear about what we would and would not take on.
