Why the choice is harder than it looks
Every Salesforce implementation partner says the same things: certified experts, proven delivery, trusted advisor. The words are free. What separates a partner who can handle a complex, high-stakes project from one who’ll hand it to a junior and hope is rarely on the homepage. Here’s the checklist we’d use if we were the ones buying.
Partner tier is a starting signal, not the answer
Salesforce restructured its consulting partner programme in 2026, collapsing the old four-tier ladder (Base, Ridge, Crest, Summit) into two tiers, Select and Summit, and shifting advancement toward verified outcomes such as customer satisfaction and completed projects rather than raw certification counts. That’s a welcome change, and a partner’s tier is worth checking. But a tier describes a firm’s overall track record, not the five people who’ll actually work on your org. Use it to build a shortlist, then judge the shortlist on the evidence below.
Certifications you can actually verify
Certifications matter, but only the current, verifiable kind, held by the specific people who will do your work, not a company-wide badge count. Ask which certified individuals are on your team and in which areas, then check them. A partner confident in its bench will tell you without hesitation. Be wary of the pattern where senior certified names win the pitch and juniors quietly deliver the project.
Product DNA and governance
A partner that has built and shipped its own product, and passed Salesforce security review, has proven it can engineer, not just configure. That is a different muscle from clicking through setup screens. We built iSyncSF and passed AppExchange security review on the first submission — what that involves is in how to pass AppExchange security review — and it shapes how we approach every client build. Pair product DNA with governance: architecture signed off before code, every change reviewed, and a clear answer on how AI output is checked before it reaches production. Speed without governance is how orgs break, which is why we work in an AI-native, engineer-reviewed way.
A track record on complex problems
Anyone can show a happy reference. The signal you want is evidence of hard problems solved: a rescued implementation, a multi-org consolidation, a pricing model nobody else would touch. Ask for case studies that look like your situation, and call the references behind them. How a partner talks about the projects that went sideways tells you more than the ones that went smoothly.
An engagement model that fits the work
The right partner offers a model that fits the shape of your project rather than forcing you into theirs: fixed scope for a defined implementation, staff augmentation to extend your own team, or managed service for ongoing improvement. Be wary of vague scoping with no architecture sign-off, usage-based AI billing that quietly pushes experimentation cost onto you, and a team you never actually meet before signing. We explain the alternative in we burn the tokens, you buy the outcome.
Red flags worth walking away from
A few patterns are reliable warnings: a proposal that cannot explain its own architecture, a refusal to name who will do the work, a demo that avoids your real data, and a price that only makes sense if the project stays simple. Complex Salesforce work rarely stays simple, and the partner should price and plan for that honestly. Add one more: a partner who agrees with everything in the sales cycle. The right partner pushes back on a bad requirement before it becomes an expensive build.
Run a paid discovery before the big commitment
For any project of real size, the best test of a partner is a short, paid discovery or architecture phase before the main contract. In two to four weeks you see how they think, how they document, how they handle disagreement, and whether the people you met in the pitch are the people doing the work. You also come away with an architecture and a scoped plan you own — useful even if you choose someone else to build it. A partner reluctant to work this way is telling you something.
Questions worth asking before you sign
Who specifically will do the work, and what are they certified in? Have you passed AppExchange security review? How do you sign off architecture, and how is AI output reviewed before production? What happens, concretely, if the project slips? Can I speak to a reference on a project like mine? The answers, and how directly they come, tell you most of what you need to know.
Key takeaways
- Use partner tier to shortlist, then verify certifications at the individual level, for the people who will actually deliver.
- Favour partners with real product DNA and governance built into how they deliver.
- Look for a track record on hard problems, and always call the references.
- Match the engagement model to your project, and treat vague scoping as a red flag.