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.
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.
