How to Choose a Salesforce Implementation Partner: What Actually Predicts Delivery Risk

On March 2, 2026, Salesforce quietly retired the four-tier partner structure - Base, Ridge, Crest, Summit - that most buyers had learned to use as a shortcut for "this firm is credible." In its place: two tiers, Select and Summit, and 28 outcome-based competencies replacing roughly 170 legacy certification badges, most of them now weighted toward verified Agentforce and Data Cloud delivery rather than general platform knowledge. A lot of the "how to choose a Salesforce partner" guides still circulating online haven't caught up - several we read while researching this piece still reference Ridge or Crest as if they're current, six months after both stopped existing.

Partner selection was already the single highest-leverage decision in a Salesforce programme - more consequential than almost any technology choice that follows it. Most Salesforce Health & Roadmap reviews CloudAvant runs turn up at least one architectural decision nobody currently at the client can explain, usually made by whichever partner built the org originally. For the next year or two, it's also the decision where the easiest signal to check - a badge, a tier, a client logo wall - is the least reliable one it's been in years. Here's what still actually predicts whether a partner will deliver.

The short answer

In brief: a partner's current tier (Select or Summit) and named competencies are worth a quick sanity check, but they describe the firm, not the two or three people who'll actually sit on your project. What predicts delivery risk is narrower and checkable in a single call: who specifically gets staffed, whether the quote defines what's out of scope, whether delivery runs as one accountable team or a handoff between practices, and whether you can talk to a named reference who'll say something more specific than "they were great." None of that requires taking a partner's own pitch deck at face value.

What Salesforce just changed in its own partner program

Salesforce's Consulting Partner Program used to run four tiers - Base, Ridge, Crest, and Summit - plus roughly 170 individual certification and specialization badges a firm could collect over years. On March 2, 2026, Salesforce collapsed that into two tiers, Select and Summit, and replaced the badge system with 28 outcome-based competencies, each one earned at either an Accredited or an Expert recognition level. Most of the new competencies are weighted toward Agentforce and Data Cloud delivery specifically rather than general platform breadth - Salesforce's own framing is that it wants partners proven on measurable AI outcomes, not just certification count.

For a buyer, the practical effect is that two signals you may have relied on - "they're a Summit partner" and "they have dozens of badges" - now mean something different than they did six months ago. A partner still citing a Ridge or Crest tier, or quoting a badge count instead of a named competency, is telling you something about how closely they track their own ecosystem - not yours.

Why none of that settles the question on its own

A Summit badge, old or new, is a floor, not a guarantee. It tells you the firm has delivered verified outcomes somewhere, for someone - it says nothing about whether the specific team assigned to your account carries that competency individually, whether your industry's constraints are familiar to them, or whether their commercial model matches how you actually need this delivered. The checks below are the ones that travel past the credential layer into the actual engagement.

Eight questions that predict delivery risk better than a tier badge

Work through these before you sign, not after the first missed deadline. None requires more than a direct question and an unhedged answer.

1. Ask which tier they hold today - and ask them to show you, not tell you

A partner that still talks about being "Crest," or leads with a badge count instead of named competencies, hasn't updated its own positioning since March 2026. That's a small thing on its own, but it's a visible, checkable proxy for how closely a firm tracks a platform that changes constantly. Ask for the specific competencies relevant to your project - Agentforce, Data Cloud, Service Cloud, whatever applies - at Accredited or Expert level, and verify them rather than taking a homepage badge at face value.

2. Ask who specifically gets staffed, not who's on the website

The people in the sales call and the people doing the build are frequently not the same people, and the gap between them is where a lot of underperforming projects start. Ask for the actual consultant and architect names, their certifications, and - reasonably - their utilisation on other active projects during your delivery window. A firm that won't commit to named staff until after signature is telling you staffing is still an open question, which it shouldn't be by the time you're evaluating a proposal.

3. Find out whether they understand your business, or just the platform

"Salesforce is Salesforce, industry doesn't matter much" is a real answer some partners give, and it's wrong often enough to be a red flag on its own. A B2B manufacturer with complex account hierarchies, a regulated finance operation, and a multi-brand retailer need genuinely different sharing models, approval flows, and integration patterns. A partner who can't point to comparable delivery in a comparable context is asking you to fund their first attempt at your specific problem.

4. Read the quote for what it excludes, not just what it includes

Fixed-bid pricing without a specific statement of work defining out-of-scope requests is a near-guarantee of change orders later - the ambiguity is where the margin comes back. Time-and-materials pricing has the opposite risk: it's honest about uncertainty but gives a struggling team less commercial incentive to converge. Ask which model they're proposing and why, and ask specifically what happens, contractually, the first time a requirement turns out to be bigger than estimated.

5. Check whether delivery is one accountable team or a handoff between practices

"Our Salesforce team will coordinate with our integration practice" sounds reasonable in a pitch and often means two teams, two sets of assumptions, and a seam where responsibility gets vague the moment something breaks between them. If your project genuinely spans Salesforce, an ERP integration, and a data layer, ask who the single accountable owner is across all three - not which practices are involved, but who answers when something between them fails.

6. Treat any Agentforce or Data Cloud claim as something to verify, not take on trust

Every partner now has an AI slide. Under the new competency framework, "we do Agentforce" should map to a specific, verifiable Accredited or Expert competency with named client outcomes behind it - not a line in a capabilities deck. If a partner can't point to the competency and a concrete example of what it actually delivered for someone else, assume the capability is aspirational, because for a lot of firms right now, it still is.

7. Call a named reference who'll say something specific

A logo wall proves a client signed a contract once, not that the engagement went well. Ask for a reference you can actually call - ideally someone in a comparable role at a comparable organisation - and listen for specificity: what went wrong at some point (every real project has something), how it got handled, and whether they'd hire the same team again. A reference who can only offer generic praise hasn't necessarily had a bad experience, but they also haven't given you anything to evaluate.

8. Settle what you own, and how handover works, before either of you needs it

Access, documentation rights, exportable configuration, and a defined handover process belong in the contract before work starts, not negotiated under pressure if the relationship ends. This is the exact gap that turns a disappointing partner into a six-month rebuild - see our guide to switching Salesforce partners mid-project for what that recovery actually costs when it isn't settled upfront.

When the biggest name is still the right call

None of this is an argument for always choosing the smaller, more specialised firm. A large, simultaneous, multi-region transformation programme - several clouds, dozens of integrations, a hard regulatory deadline - genuinely needs the bench depth, programme-management maturity, and parallel-workstream capacity that only a large systems integrator carries. The eight questions above don't change with firm size; what changes is which answers should worry you. A boutique firm with two named architects and a thin bench is the wrong choice for that kind of programme regardless of how well it answers everything else.

It's also exactly the territory where a senior specialist is more useful plugged into an existing large-SI or internal programme as additional capacity than competing against it for the whole engagement - the model behind CloudAvant's own Enterprise Salesforce Expertise work, including a role scaling a global onboarding platform across multiple countries alongside exactly that kind of broader, multi-market programme. A large SI and a specialist aren't always competing bids for the same work; sometimes the right answer is both, scoped differently.

Frequently asked questions

What's the actual difference between a Select and a Summit partner now?

Select confirms a partner has demonstrated baseline delivery capability in at least one competency; Summit is reserved for partners with verified outcomes across a broader set of competencies, weighted heavily toward Agentforce and Data Cloud. Both are real signals worth checking, but neither tells you anything about the specific team your project would get - that still requires asking directly.

Why do some partner websites still list Crest or Ridge tiers?

Mostly lag - marketing pages take time to catch up to a programme change, and the overhaul is still relatively recent. A one-off outdated mention on an old case-study page is normal. A partner whose sales team references an old tier in conversation, or can't explain the new competency structure when asked directly, is a different and more concerning signal.

Is fixed-bid or time-and-materials pricing safer?

Neither is inherently safer - each shifts the risk to a different place. Fixed-bid without a tight statement of work shifts scope risk onto you; time-and-materials without a capped estimate and regular checkpoints shifts cost-control risk onto you. The safer question isn't which model, but whether the partner can explain, specifically, what happens the first time scope grows.

How many partners should actually make the shortlist?

Three is usually enough to compare meaningfully without the process itself becoming a project. Fewer than that and you can't tell whether a weak answer is a red flag or just how every partner answers that question; more than three mostly adds scheduling cost without adding decision quality.

The bottom line

Salesforce rewriting its own credentialing system doesn't make partner selection harder - it just removes a shortcut that was already doing less work than buyers assumed. A badge was always a proxy for the questions above, never a substitute for asking them directly. If you're mid-shortlist and want a second, independent read on a proposal or a specific partner's answers before you sign, that's a scoped conversation, not a sales pitch - get in touch, or start with a Salesforce Health & Roadmap if the bigger question is what state your current org is actually in.