Key takeaways
- Ask about four things: the people named on your project, the decision and change process, comparable shipped proof, and the exit terms.
- Staffing after the sale predicts delivery quality more than any certification count — insist the SOW names individuals.
- Handover and data ownership are day-one questions; a partner that treats them as afterthoughts is building lock-in.
- Nine or more specific answers means shortlist; three or more evasive answers means walk away, whatever the tier badge says.
References check out. The logo wall is impressive. The certification count is high. None of that tells you who will show up on your project, how decisions get made when requirements shift, or whether you can leave without a fight. Those are the things that decide whether the implementation lands or drifts.
The questions below are the ones a partner who is confident in its delivery will answer without flinching. We publish them because we would rather you ask them of us than find out the answers after the statement of work is signed.
What questions should I ask a Salesforce implementation partner?
Ask about four things: the people (who is named on your project and their tenure), the process (how architecture decisions and scope changes are handled), the proof (comparable shipped work at your scale), and the exit (handover package and data ownership). Strong partners answer all four with specifics, not brochures.
Most published question lists stop at “check their references and certifications.” That filters out nobody. Every serious partner has references and certifications. The questions that separate a good fit from an expensive mistake probe the parts a sales deck hides: staffing after the sale, decision accountability, and what happens when you want to leave.
What is an implementation partner in Salesforce?
A Salesforce implementation partner is a certified consultancy that designs, configures, integrates and deploys Salesforce for your organization, then hands it over to your team. Partners hold a formal Salesforce Partner status and are tiered by revenue, certifications and customer satisfaction. Tucario is a Salesforce Partner and an AppExchange ISV.
The partner tier tells you about scale and certification volume. It does not tell you who does the work on your engagement or how deep the architecture review goes. That is why the tier is a starting filter, not a decision. The questions in this article are built to see past it.
How do I choose the right Salesforce implementation partner?
Judge partners on delivery predictors, not marketing signals. Weight named senior people on your project, an architect present from design through handover, comparable industry proof, a documented change process, and a clean exit standard. Discount logo walls and raw certification counts. Ask the 15 questions below and compare the answers side by side.
For the full selection framework, including the scorecard and the anti-criteria, read our companion guide to choosing a Salesforce implementation partner. This article is the interrogation half: the exact questions and what a good answer sounds like for each.
The 15 questions, grouped by what they protect
The questions fall into four groups. People questions protect you from bait-and-switch staffing. Process questions protect you from decision drift and scope disputes. Proof questions protect you from being someone’s first attempt at your problem. Exit questions protect you from lock-in. Ask all fifteen, and listen for specifics.
People: who exactly does the work
1. Who are the named individuals on my project, and what are their tenure and certifications? A good answer names people, not roles, and gives their years of Salesforce experience. Vague “we will assign a team” answers mean the team is not decided or is junior.
2. Will the people in this pitch deliver the work? A good answer confirms the architect and leads in the room stay on the engagement. If the senior faces disappear after signature and unnamed “resources” arrive, you bought a brochure.
3. Is a Salesforce architect involved from design through delivery, or only for a review? A good answer describes an architect with design authority present from first call to handover. A drive-by review at the end catches almost nothing. We run architect-led delivery on every engagement for this reason.
4. What happens if a key person leaves mid-project? A good answer describes documented decisions, shared context, and a continuity plan. Firms with 15-plus years of average senior tenure have less turnover to manage, but every partner should have an answer beyond “that will not happen.”
Process: how decisions and changes get handled
5. How are architecture decisions made and recorded? A good answer points to a written decision log with the context and trade-offs behind each call. Decisions made by default, undocumented, become the technical debt you inherit.
6. What is your change process when scope shifts? A good answer describes how a change is estimated, approved and priced before work starts, with gates rather than an open meter. Silence here predicts a dispute later.
7. How do you handle a requirement you think is wrong? A good answer includes a recent example of pushing back and why. A partner that agrees to everything in the sales phase will agree to everything that breaks in production.
8. What does your understand phase produce before build starts? A good answer names concrete artifacts: a solution design, a data model, integration contracts, acceptance criteria. “We start building in week one” is a warning, not a virtue.
Proof: shipped comparable work
9. Can you show comparable work in my industry and at my scale? A good answer describes a similar data model, integration pattern or compliance constraint, not just a matching logo. We work across 7 industry verticals, so match the pattern, not the name.
10. What have you built and shipped that you own? A good answer includes products the partner maintains to AppExchange standards. Building and running your own apps proves the partner lives with its own architecture decisions. Tucario ships FTS and Smarter Files on the AppExchange.
11. Can I speak to a reference where the project went sideways? A good answer offers one, with what went wrong and how it was recovered. Any partner can supply a happy reference. How they handle a hard one is the real signal.
Exit: handover and lock-in
12. What is in your handover package? A good answer lists an architecture decision log, configuration and metadata documentation, runbooks, an admin enablement plan and an open-risks register. If handover is an afterthought, you are being set up for a retainer.
13. Could my internal team or another partner take over in a week? A good answer is a confident yes, backed by the handover package above. Knowledge kept in one firm’s heads is a hold over you, priced into every future change.
14. Do we own the metadata, configuration and IP? A good answer is unambiguous: you own your org and everything built in it. Watch for wording that keeps rights, connectors or documentation on the partner’s side.
15. What does ongoing support look like, and is it optional? A good answer offers support as a choice, not a dependency you cannot escape. Mandatory retainers to keep your own org running are a lock-in tax.
Red flags hiding inside the answers
The words matter less than the specificity. “We will assign an experienced team” hides that no team exists yet. “We are flexible on scope” often means no change control, which becomes your cost. “Full documentation on completion” with no named artifacts usually means a thin export nobody can use.
The printable checklist
Take this into the vendor call and mark each answer as specific, vague or evasive.
- Name the individuals on my project, with tenure and certifications.
- Confirm the pitch team delivers the work.
- Architect present from design through handover, not just a review.
- Continuity plan if a key person leaves.
- Architecture decisions recorded in a written log.
- Change process with estimation and approval before work starts.
- A recent example of pushing back on a requirement.
- Named artifacts produced before build starts.
- Comparable work at my industry and scale.
- Products the partner has built and ships.
- A reference where the project went sideways.
- A defined handover package, itemized.
- A confident yes to a one-week takeover test.
- Clear ownership of metadata, configuration and IP.
- Support offered as a choice, not a dependency.
Nine or more “specific” answers is a partner worth shortlisting. Three or more “evasive” answers is a partner to walk away from, whatever the tier badge says.
How we would answer, and when you do not need us
We would answer all fifteen with names and artifacts, because architect-led delivery and a published handover standard are how we work across 50-plus enterprise engagements, most of them EU enterprises. Our lead architect holds the Certified Technical Architect credential, held by fewer than 500 people worldwide.
Here is the honest part. If your project is a single scoped configuration change with clear requirements and an in-house admin who can own it, you do not need a firm like ours, and questions 9 through 15 will matter less than cost. Bring the full list when the work spans multiple clouds, integrations or a data migration, where the exit and decision questions decide your total cost of ownership.
When the stakes are at that level, talk to an architect and hold us to every answer above.
Frequently asked questions
What is the most important question to ask a Salesforce implementation partner?
Ask who is named on your project and whether the pitch team delivers the work. Staffing after the sale predicts delivery quality more than any certification count. A partner that names senior people and keeps them on the engagement is telling you the work is accountable.
How many Salesforce implementation partners should I evaluate?
Shortlist three to five partners and ask all of them the same fifteen questions, then compare answers side by side. Fewer than three leaves no baseline for judging an answer as strong or weak. More than five spreads your evaluation time too thin to probe the answers properly.
What is an implementation partner versus a Salesforce reseller?
An implementation partner designs, configures, integrates and deploys Salesforce, then hands it to your team. A reseller focuses on selling licenses. Many firms do both, so ask which capability applies to your engagement and who owns the technical delivery once the licenses are in place.
Should I ask about handover before the project starts?
Yes. Ask about the handover package and data ownership before you sign, not at the end. A partner planning a clean exit documents decisions and configuration as it goes. One that treats handover as an afterthought is building lock-in into the engagement from day one.
Do Salesforce partner tiers tell me who is best for my project?
Tiers signal scale, revenue and certification volume, not who staffs your engagement or how deep the architecture review goes. Use the tier as a first filter, then ask the fifteen questions to see past it. A smaller partner with senior density often outperforms a higher tier on focused work.
Michał Bajdek
Co-Founder, Tucario
Co-founder of Tucario, a Salesforce consulting and product engineering firm. Works across enterprise Salesforce delivery — architecture, integrations and AppExchange products — and writes about what holds up in production.