On this page (5)
Before you sign with a Salesforce consulting partner, ask about relevant experience, who will actually do the work, how they run discovery and scoping, how they handle data migration and testing, what support looks like after launch, and how changes to scope are priced. Listen for specific, evidence-backed answers rather than reassurance. Then score every partner against the same weighted criteria so the decision does not come down to whoever gave the best demo.
Why the questions matter more than the pitch
Sales presentations from Salesforce consulting companies tend to look alike: a certification count, a logo slide, a methodology diagram and a confident timeline. None of that tells you how the firm behaves when requirements are unclear, when data turns out messier than expected, or when a key consultant leaves halfway through. The questions below are designed to surface exactly that, and they work best when you ask each shortlisted firm the same ones in the same order.
Bring the people who will live with the result. A sales leader, a service manager and whoever will administer Salesforce afterward will each hear different things in the same answer. If you are still deciding whether you need a firm at all, start with our comparison of a consulting partner and an independent freelancer, then come back to this list.
The questions to ask, grouped by topic
Experience and fit:
- Which of your recent projects looked most like ours, and what was hard about it?
- Which Salesforce clouds and integrations have you delivered for companies of our size and industry?
- Can we speak to a client whose project did not go to plan, and hear how you handled it?
People and continuity:
- Who will lead our project day to day, and can we meet them before signing?
- Which roles are on the team, and is anyone subcontracted or working from another country?
- If our lead consultant leaves your firm, how is their knowledge transferred?
Approach and delivery:
- What does your discovery produce, and do we get to keep it if we part ways?
- How do you decide between configuration and custom code?
- How do you plan, test and reconcile data migration?
- How do you handle a request that falls outside the agreed scope?
- What documentation will we receive, and who is it written for?
- What happens in the weeks after go-live, and how is ongoing support priced?
Good answers vs. red flags
You are not looking for polished answers. You are looking for answers that are specific, admit trade-offs and would still hold up if you checked them with a reference.
| Question | A good answer sounds like | A red flag sounds like |
|---|---|---|
| Which project looked most like ours? | Names the industry, the clouds and a specific difficulty, then explains what they would do differently | A generic success story, or “every project is unique” with no detail |
| Who will do the work? | Names the lead and the roles, and says where each person is based | “We will assign the best available resources after signing” |
| What does discovery produce? | A written scope, process maps and design decisions that belong to you | Discovery is informal, or its output stays with the partner |
| Configuration or custom code? | Configuration by default; custom code only when a requirement cannot be met otherwise, with a maintenance plan | Custom development proposed early for problems standard features already solve |
| How do you handle data migration? | A mapping document, trial loads, record counts reconciled against the source, and a sign-off step | “Send us a spreadsheet and we will load it” |
| How do you handle out-of-scope requests? | A written change request with effort, impact on timeline and your approval before work starts | Vague reassurance that small changes are always fine |
| What happens after go-live? | A defined stabilization period, a named contact and clear options for ongoing support | Support is “as needed” with no terms, or is not discussed until the end |
Score every partner the same way
A scorecard keeps the comparison honest. Agree on the criteria and weights before the first meeting, so nobody adjusts them to fit a favorite afterward. Our free Salesforce partner evaluation scorecard does the arithmetic: set weights for nine criteria, score up to three partners from 1 to 5, and compare weighted totals. It runs in your browser and stores nothing.
Questions people also ask
What questions should I ask a Salesforce implementation partner?
Ask about relevant experience, who will actually do the work, how they run discovery and scoping, how they handle data migration and testing, what support looks like after launch, and how scope changes are priced. Listen for specific answers that admit trade-offs rather than reassurance. Ask every shortlisted firm the same questions in the same order, and score them against weighted criteria agreed before the first meeting.
How do I find out who will actually work on our project?
Ask the partner directly who will lead your project day to day, and ask to meet that person before you sign. A good answer names the lead and the roles and says where each person is based. Also ask whether anyone is subcontracted, and how knowledge is transferred if your lead consultant leaves. "We will assign the best available resources after signing" is a red flag.
How should we check a Salesforce partner's references?
Ask each partner for a reference whose project resembles yours, then ask that reference what went wrong and how the partner responded. Every project hits problems. The useful signal is whether the firm told the client early and fixed it without drama. You can also ask the partner for a client whose project did not go to plan and hear how they handled it.
Can we see samples of a partner's documentation before we hire them?
Yes, and it is worth asking. A partner that documents well can usually share an example with client details removed, such as a solution design, a data dictionary or an admin guide. Judge whether your own admin could maintain the org from it. Also ask what documentation you will receive on your project and who it is written for, and make sure the contract says you own it.
What are the biggest risks a Salesforce partner should flag in our project?
A good partner names your specific risks before you sign. The usual ones are unclear decision ownership, poor data quality, too little of your team's time, integrations with weak APIs, scope that grows after discovery and a launch date set before the work is understood. If a firm says it sees no risks, treat that as a warning. Ask how they would reduce each risk and what they need from you to do it.
Before-you-sign checklist
- You have met the person who will lead the project, not only the sales team.
- The statement of work lists what is in scope and, just as important, what is not.
- Assumptions about data volume, integrations and your team’s availability are written down.
- Ownership of documentation, code and configuration is stated in the contract.
- The change-request process is described, including who approves changes on your side.
- Post-launch support is defined, even if you decide to handle it internally.
- Your scorecard totals and evidence notes are saved with the decision.
At Abstrakt we expect to be asked all of these, and we would rather a prospect compare us carefully than sign on the strength of a demo. Our own case studies show the kind of evidence worth requesting from any firm: a cybersecurity company that consolidated sales and support tools and migrated 2,300 accounts, with core functionality live in roughly 6–8 weeks, is a concrete, checkable example rather than a promise.
