How to choose a Salesforce implementation partner: a buyer-side checklist

Short answer: choose on evidence of delivery, not on the rate card. Ask for three things you can verify: a reference project in your industry with a named outcome, the certifications of the specific people who will sit on your team rather than the firm's total, and a written description of what support looks like the week after go-live. A cheap day rate that produces rework is the most expensive option on the table.

Why does the rate card mislead so reliably?

Because it prices a seat, and you are buying an outcome. Three patterns repeat:

• The blended rate hides the bench. One average number can mean a senior architect for a week and juniors for six months. Ask for the team composition per phase.
• Rework is invisible at signing. Configuration that ignores your data model looks identical on a status report to configuration that fits it. The difference surfaces in month five, as change orders.
• The scope cut to hit the number was the integration. Salesforce projects rarely fail at the CRM. They fail at the boundary: the ERP, the telephony, the identity provider, the migration nobody costed.

None of that argues for the highest bid. It argues for comparing the total cost of a working system, and asking each bidder to show where their number will move.

Do Salesforce partner tiers still tell you anything?

Less than they did, and the rules have just changed. On 3 March 2026 Salesforce overhauled its consulting partner program: the four tiers of Base, Ridge, Crest and Summit collapse into two, Select and Summit, and 170 Navigator badges become 28 competencies, each recognised at Accredited or Expert level.

The useful part for a buyer is how a competency is earned: certifications, completed projects and customer satisfaction scores. That makes it a claim about delivery history rather than about sales volume. Two consequences:

• A tier badge quoted in an older deck or case study may no longer mean what it meant. Ask what the partner holds today.
• A competency in the exact product you are buying, whether that is Agentforce, Data Cloud or Field Service, is worth more to you than a higher overall tier earned somewhere else.

What delivery proof should you ask for?

Ask for artifacts, not adjectives. A partner who has done the work can produce these within a day:

1. One reference project in your industry, with the before-and-after number attached and a client willing to take the call.
2. A redacted solution design from a past project. You are checking whether they document decisions or improvise them.
3. Their deployment method. How does a change get from a developer to production, who approves it, and how is a bad release rolled back? If the answer is change sets and a spreadsheet, you will feel it every release.
4. A named failure. What went wrong on a recent project, and what changed afterwards? A partner with no answer has either no history or no candour.

Which certifications actually matter?

The ones held by the people who will be on your project. A company-wide certification count is a recruitment statistic. What matters is:

• An architect credential on whoever owns the data model, if you have more than one source of customer truth.
• A product certification matching your real scope: Field Service, Service Cloud, Data Cloud, CPQ. Generalists make you pay for discovery twice.
• PDO or ISV experience if anything you build will be packaged, distributed or taken through AppExchange security review. That is a different discipline from org configuration, and the one most often assumed.

Salesforce certifications are individually verifiable, so verify them. Name the delivery team in the statement of work and make substitutions require your approval.

Who will actually do the work?

The pitch team is rarely the delivery team. Three questions settle it: who is full time on your project rather than allocated across four, in which time zones, and whether any of the work is subcontracted. None of these has a wrong answer. A partner who will not answer them plainly has given you one anyway.

What does support look like after go-live?

Get it in writing before you sign, in these terms:

• The hypercare window, how long it lasts and who is in it.
• Response targets by severity, and what qualifies as severity one.
• Who holds the knowledge if your admin leaves, and where the documentation lives.
• How enhancements are funded once the project budget closes.

Salesforce ships three releases a year, so "done" is not a state your org gets to occupy. The partner who plans for that costs less over three years than the one who books the launch party.

What are the red flags?

• A fixed price quoted before any discovery. It is either padded or it will be reopened.
• No questions about your data. Migration is where schedules die.
• Certifications quoted as a company total.
• Reluctance to name the delivery team.
• Custom code proposed where configuration would do, or the reverse, with no stated reason.

Tekunda is a certified Salesforce SI, ISV and PDO with 16+ organisations live in production, and we would rather publish the numbers than the adjectives: for ASSA ABLOY, weekly cases fell from 3,000 to 350 across 11,000 connected devices, with no added support staff. Ask us for exactly the proof you should ask anyone else for. See what we build.

FAQ

Is a bigger Salesforce partner safer?

Not inherently. Scale buys coverage and continuity, a smaller firm usually buys seniority on your actual project. Decide which risk matters more for your scope.

How long should choosing a partner take?

Two to four weeks for a shortlist of three, reference calls included. Beyond that the business case ages faster than the evaluation improves.

Should I run a paid discovery before the full project?

Usually yes. A short paid discovery buys you a real estimate and a sample of how the partner works, for a fraction of the cost of finding out mid-build.

What if the partner I like lacks one skill I need?

That is normal, and fine if they say so upfront. Ask how the gap is covered, by whom, and who is accountable where the two halves meet.