Most advice on choosing a Salesforce consultant tells you to check certifications and look at the AppExchange rating. That is fine as far as it goes, which is not very far. Certifications are widely held. Ratings are collected from clients a partner chose to ask.
The harder problem is telling a genuinely good partner from a merely plausible one, before money changes hands and while everyone is still being charming. This guide is about that problem. It is written from the perspective of having inherited a fair number of orgs built by somebody else.
Work out what you are actually buying
The phrase "Salesforce consultant" covers at least four different services and conflating them is the first way projects go wrong.
- Advisory. Someone who helps you decide what to build, which edition to buy and how to sequence a roadmap. Usually weeks, not months.
- Implementation. A team that configures, migrates data, integrates and launches. The most common engagement.
- Rescue. Diagnosing and repairing an org that a previous project left in poor shape. Different skill set, needs seniority.
- Managed service. Ongoing administration, enhancement and support after go-live.
Firms will happily sell you all four. Few are equally good at all four. Decide which you need before you take the first call, because a partner optimised for large implementation programmes is rarely the right choice for a two-week advisory engagement.
What separates a good partner from a plausible one?
Four signals carry most of the weight in our experience.
They push back during the sales process
A partner who agrees with everything you say is not listening, they are closing. The consultants worth hiring will tell you that part of your requested scope is a bad idea, or that your timeline is unrealistic given your data. That friction before contract is the best available preview of how they will behave when something goes wrong mid-project.
They insist on discovery before quoting
Fixed-price quotes produced from a single call are guesses. They get corrected later through change requests, which is where the relationship sours. A short paid discovery that produces a written scope, a data assessment and a realistic estimate costs a fraction of the project and removes most of the risk. Our Salesforce implementation cost guide sets out what the resulting numbers usually look like.
You meet the delivery team, not just the sales team
This is the single most useful question you can ask: who specifically will be working on this and can I speak to them. The gap between the people who win work and the people who do it is where a great deal of disappointment lives. Ask for names, seniority and how much of their time you get.
They talk about adoption, not just configuration
A partner who discusses training, change management and what happens in the eight weeks after launch is thinking about whether the project succeeds. One who only discusses build scope is thinking about whether the invoice gets paid. The difference matters, because low adoption is the most common reason implementations fail, as we cover in why Salesforce projects fail.
Questions worth asking and the answers to distrust
| Ask this | Good sign | Walk away if |
|---|---|---|
| Who will do the work? | Named people, with seniority stated | Vague talk about "our team" |
| Can I see a similar project? | A reference in your size and sector | Only logos, no contacts |
| How do you handle scope change? | A written, predictable process | "We are flexible" |
| What happens after go-live? | A concrete support and handover plan | Support sold as a separate conversation |
| Who owns the code? | You do, in your repository | Any hesitation at all |
| What could go wrong here? | Specific risks about your situation | "Nothing, we have done this before" |
That last question is unusually diagnostic. Anyone who has genuinely delivered these projects can name three things that might go wrong with yours inside thirty seconds. An inability to do so means they have not thought about your situation yet.
Red flags that justify ending the conversation
- A fixed price without discovery. Either they are guessing or they have padded it heavily. Both are bad.
- Reluctance to give you admin access to your own org, at any point, for any reason.
- Code kept in their repository rather than yours. This is a lock-in mechanism, not a technical necessity.
- No documentation in the deliverables list. An undocumented org is a liability you inherit at handover.
- Pressure to sign before a discovery call with the delivery team.
- Every answer is yes. Real constraints exist. A partner pretending otherwise will discover them later at your expense.
Onshore, offshore or blended?
Cost differences here are large enough to matter, so it is worth being clear-eyed rather than ideological. Offshore delivery works well for build-heavy work with a stable, well-documented scope. It works less well for engagements that need constant stakeholder conversation in your timezone, such as early discovery or change management.
The blended model most of our clients settle on puts a senior consultant in or near their timezone for discovery, design and stakeholder work, with build capacity offshore. The considerations are much the same as for any distributed engineering arrangement, which we cover in the offshore software development buyer's guide. If your need is really for extra hands under your own management rather than a managed project, hiring Salesforce developers directly may be the better route.
Before you sign
- Confirm in writing that you own the org, the code and the documentation.
- Get the named delivery team and their allocation stated in the contract.
- Agree a written change-request process with indicative rates.
- Define what "done" means for each deliverable, including handover materials.
- Agree how the org will be assessed at completion. An independent org health check written into the contract keeps everyone honest.
None of this is adversarial. Good partners welcome it, because clear expectations protect them just as much as they protect you. The ones who resist are telling you something useful for free.
How should you compare competing proposals?
Once two or three proposals arrive, they will be difficult to compare directly because each will have scoped the work differently. That is not always deliberate, but it does work in the seller's favour. A few steps make the comparison honest.
- Normalise the scope yourself. Write your own one-page list of what must be delivered, then map each proposal against it. Anything a partner excluded is a conversation, not a discount.
- Compare total hours, not day rates. A lower rate against twice the hours is more expensive. Ask for the estimate broken down by workstream.
- Look at the seniority mix. A proposal staffed largely with juniors at a blended rate is cheaper on paper and slower in practice.
- Check what is excluded. Data migration, training, documentation and post-launch support are the four most commonly left out and all four are things you will need.
- Price the second year. Ask what ongoing support costs once the project ends. A cheap build followed by an expensive retainer is a common shape.
If one proposal is dramatically cheaper than the others, assume it has understood the work differently rather than that it is better value. Ask what they think the hard part is. The answer tells you whether they have seen the difficulty yet.
Where to go from here
Choosing a Salesforce consultant is mostly an exercise in avoiding the wrong one. Look for specificity, insist on meeting the people who will do the work and treat certifications as the floor rather than the ceiling.
If you would like a second opinion on a proposal you have received, or want a scoped discovery before committing to a build, our Salesforce implementation team is happy to help. You can also talk to us directly about where your project currently stands.
