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

Short answer: to choose a Salesforce implementation partner, shortlist three firms with delivery history in your products and industry, verify the credentials of the people who will actually be on your project, run a short paid discovery, and score the bids on evidence rather than day rate. Ask each one for a reference client with a named outcome, the named delivery team, and a written support model for the months after go-live. A cheap rate that produces rework is the most expensive option on the table.

How do you choose a Salesforce implementation partner, step by step?

Six steps, most of which take a day or two each:

1. Write down the outcome before you talk to anyone. Which clouds, which integrations, which data has to move, and the one business number the project must change. Partners quote against the brief you give them, so a vague brief buys a vague price.
2. Build a shortlist of three. Every registered partner has a public AppExchange listing showing its tier, customer satisfaction score, reviews and competencies (ABSYZ). Filter on the competency that matches your scope, not on overall size.
3. Ask for delivery proof. A reference project, a redacted solution design and their deployment method. The full list is below.
4. Verify the named team. Check individual certifications yourself with Salesforce's credential verification tool.
5. Run a short paid discovery with your front-runner. It turns an estimate into a plan and shows you how the partner actually works.
6. Score and contract on evidence. Weight delivery proof and team seniority above rate, and name the delivery team in the statement of work.

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, and later as the kind of technical debt someone else has to pay down.
• 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?

More than they used to, because the rules changed in 2026. In March Salesforce overhauled its consulting partner program: the four tiers of Base, Ridge, Crest and Summit collapsed into two, Select and Summit, and 170 legacy badges became 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 sales volume. Three consequences:

• A tier quoted in a deck or case study from before March 2026 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.
• Summit now leans heavily on AI delivery: partners that cannot show Agentforce competency are placed in Select by default (ABSYZ). If your project has no AI scope, a strong Select partner may be the better fit.

Should you pick a boutique partner or a global SI?

Neither is safer by default. They trade different risks:

• Global systems integrators buy you coverage, continuity and round-the-clock capacity. The risk is that the senior people who pitched hand over to a junior-heavy team.
• Boutique partners usually put senior people on your actual project and decide faster. The risk is depth: holidays, attrition and a skill they do not have in-house.

Match the partner to the shape of the work. A multi-country rollout across five clouds needs bench depth. A focused Service Cloud or Field Service build usually needs seniority more than headcount.

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 data migration plan. How they profile, cleanse, map and reconcile your data, and who signs it off. A partner who has run a successful Salesforce data migration will describe the rehearsal loads before you ask.
4. 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.
5. 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, Agentforce, 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: the Trailhead verification page looks people up by name or email, provided they have opted in to being searchable. 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.

How do you judge a partner's Agentforce and AI readiness?

Almost every partner now claims AI experience, so ask questions only real delivery can answer:

• Which agent do they have in production, for which client, and what does it resolve without a human?
• What did the data have to look like before the agent could work, and who fixed it?
• How do they test an agent before release, and how do they monitor it afterwards?
• Where does the agent hand over to a person, and who decided that boundary?

A partner who answers with a live demo on a sandbox and no production story is selling a roadmap, not a track record.

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 seasonal releases a year, typically Spring in February, Summer in June and Winter in October, so "done" is not a state your org gets to occupy. Ask how the partner will help you build the internal ownership that outlasts them, for example a Salesforce Center of Excellence. 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.
• A partner tier quoted from before the 2026 program change.
• AI claims with no production agent behind them.
• Custom code proposed where configuration would do, or the reverse, with no stated reason.

Tekunda is a certified Salesforce SI, ISV, PDO and Agentforce partner with 20+ 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. You can see what we deliver as a Salesforce partner and how we engage from discovery to post-launch support.

FAQ

What questions should I ask a Salesforce implementation partner?

Ask for a reference client in your industry, the named delivery team with their certifications, their data migration and deployment methods, and a written post-launch support model.

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.