How long does it typically take to thoroughly compare several integrators at this level?

Allow approximately three to four weeks for a serious evaluation process: one week for joint scope preparation, one to two weeks for meetings and written responses, and one week for comparison and reference checks. A quicker process often relies on first impressions and misses critical gaps in assumptions.

What if a vendor refuses to provide written answers to some questions?

This is a significant red flag, not a minor technicality. Verbal answers are easily forgotten or denied later. If a vendor states the answer 'depends on the project,' request a range or an explicit working assumption. Outright refusal warrants considering other proposals.

Are these questions applicable to an existing vendor when renewing a contract?

Yes, and sometimes it's even more critical. An existing vendor who has accumulated internal knowledge may stop documenting and self-auditing over time. Re-evaluating every 12-18 months can uncover team attrition, documentation gaps, or slow response times before they escalate into dangerous dependency.

What relative weight should be given to each of the six topics during the decision-making process?

There's no one-size-fits-all formula. However, for a first-time project with extensive data sources, dedicating about 45% of the score to Team and Data combined is advisable, 35% to Methodology and Architecture, and the remainder to Commercial Terms and Continuity. For existing contract renewals, the weight shifts significantly towards Continuity and Commercial Terms.

What's better – a low-cost vendor with generic answers or a more expensive vendor with detailed responses?

Detailed answers are almost always more valuable. A 15-20% price difference is minor compared to the cost of rework due to incorrect assumptions about data or permissions. A low price with an ambiguous scope often signifies the same work, plus an unpleasant surprise down the line.

15 Questions to Vet Salesforce Integrators Before Signing

The Short Answer

Proposals from different Salesforce integrators almost always look similar. They use the same buzzwords like Discovery, Agile, Best Practice, and promise "close support." The real difference only emerges when you evaluate each proposal against concrete questions that reveal how the vendor thinks, not just what they propose to deliver. The purpose of the following 15 questions is to identify gaps before signing, not after the project is already stuck.

The questions are divided into six topics: Team, Methodology, Architecture, Data, Commercial Terms, and Continuity. Each question includes a short explanation of why it's important and a description of what a weak answer sounds like—making it easy to identify in real-time, whether in a meeting or a proposal document.

We've detailed the practical implications of selection on the entire implementation process separately in Choosing a Salesforce Implementation Company.

Why 15 Questions and Not a Technical Requirements List

A technical requirements list—how many Sandboxes, what licenses, SLA times—is important but insufficient. It checks what the vendor says they will do, not how they will handle situations where the original plan turns out to be inaccurate. The questions here were chosen because they reveal working patterns: how the team documents decisions, how it handles dirty data, and what happens when something doesn't go according to plan.

Summary Table: Strong vs. Weak Answer

Topic	A strong answer sounds like this	A weak answer sounds like this
Team	"Consultant X leads architecture, developer Y executes; we'll share CVs and allow a brief interview."	"We have an experienced team; we'll assign the right people during Kickoff."
Methodology	"Two-week sprints, a real demo at the end of each sprint, shared backlog in Jira."	"We work Agile; it's flexible and suitable for any project."
Architecture	"We'll build an ADR for every key decision, including rejected alternatives and reasons."	"We'll choose the best solution based on our experience."
Data	"We'll run Data Profiling before the final proposal, and clarify the quality of your sources."	"We'll handle data cleaning during development."
Commercial	"Fixed price for a defined Scope, additional hours per documented Change Request."	"Flexible T&M to avoid limiting you."
Continuity	"Handover document, internal Admin training, two weeks of Hypercare after Go Live."	"We're always here for you; no need for a separation protocol."

Team: Who Will Actually Work on the Project

1. Who will actually support the project, not just in the proposal?

This question is critical because many proposals feature senior team members in sales meetings but replace them with junior consultants after signing. A strong answer includes names, roles, and allocated percentage of time. A weak answer sounds like, "We'll choose the most suitable person based on availability"—meaning no genuine allocation until the last minute.

2. How many concurrent projects does each consultant manage at the same time?

A consultant managing five projects simultaneously cannot pay attention to detail. A strong answer will acknowledge this limitation and present a reasonable number (typically two to three projects). A weak answer evades or says, "It depends on the workload," without a concrete number.

3. What happens if the lead consultant leaves mid-project?

A strong answer describes a documented handover process, a two-week overlap, and ongoing documentation that allows for replacement without knowledge loss. A weak answer claims, "This hardly ever happens with us," without a contingency plan. You can read more about a proper working structure with a Salesforce Consultant.

Methodology: How the Work Actually Proceeds

4. What does a typical sprint look like—what happens if something isn't ready on time?

A strong answer describes Sprint Planning, a short Daily Scrum, a Demo, and a Retrospective, as well as what happens when a task gets stuck—whether it's transparently deferred to the next sprint. A weak answer merely states, "We work Agile," without detailing any concrete ceremonies.

5. What does ongoing communication look like—channel, frequency, and responsible party?

A strong answer specifies a channel (Slack, Teams), a regular weekly status meeting, and a single point of contact for escalation. A weak answer "We'll always be available by email," which in practice means there's no SLA for response.

6. How is work tested before it's presented to the client as complete?

A strong answer describes internal QA, an acceptance checklist, and accessibility and permissions testing before a demo. A weak answer implicitly admits that the first client demo is also the first test.

Architecture: How Decisions Are Made

7. How are architectural decisions documented, and who approves them?

A strong answer presents a concise decision template—problem, alternatives, choice, and reason—that is saved and accessible to the client. A weak answer says, "We choose the right solution," without documenting why other alternatives were rejected.

8. How will the solution handle load and growth in two to three years?

A strong answer addresses Governor Limits, expected data volume, and scalability planning. A weak answer says, "Salesforce is inherently scalable," without connecting it to the specific use case.

9. What happens when a new requirement conflicts with a previous decision?

A strong answer describes a Change Request process that assesses the impact on what's already built. A weak answer simply promises, "We'll adapt to any change," which usually results in accumulating technical debt in the background.

Data: Where Most Projects Get Stuck

10. How is data quality checked before starting to build?

A strong answer includes an early profiling stage—duplicates, empty fields, inconsistent formats—and a timeline for correction. A weak answer defers this to, "We'll handle it during migration," which almost always extends the project.

11. What is the source of truth for each data type, and how are redundancies between systems handled?

A strong answer identifies in advance which systems "win" in a conflict (e.g., ERP vs. Salesforce for existing customers) and documents the rule. A weak answer says, "Salesforce will be the source of truth" across the board without checking if this is true for every object.

12. What is the backup and recovery plan, and who is responsible for it after implementation?

A strong answer details backup tools, frequency, and who performs recovery in practice if needed. A weak answer assumes Salesforce "already takes care of it" without distinguishing between platform backup and organizational-level backup.

Commercial and Continuity: What Happens After Signing

13. How is the price structured—fixed, T&M, or hybrid, and what is actually included?

A strong answer breaks down the price into workstreams with estimated hours for each and defines what constitutes a Change Request with additional payment. A weak answer gives a single global number without a breakdown, making it difficult to compare proposals.

14. What happens if the project runs over time—who absorbs the cost?

A strong answer distinguishes between delays caused by the vendor (at their expense) and delays caused by changes in client requirements (paid by the client). A weak answer uses ambiguous phrasing that allows the vendor to pass any delay costs onto the client.

15. What happens at project completion—what support, for how long, and at what rate?

A strong answer includes a defined Hypercare period (typically two to four weeks), a handover document, and internal Admin training. A weak answer promises "ongoing support" without a clear rate, scope, or end date. More on correctly drafting such contract clauses appears in Salesforce Project SOW Contract Clauses.

Organizational Case Study

A financial services company received three proposals to merge two old CRM systems into a single Salesforce instance. Two of the proposals were 20%-25% lower in price than the third. When the CIO asked question 10 (early data quality check), the two cheaper vendors replied, "We'll handle it as part of the migration"—while the more expensive vendor presented a one-week profiling plan before the final amount was signed.

The organization chose the more expensive vendor. The one-week profiling revealed about 12,000 duplicate records and a date field in an inconsistent format across 3 data sources. This early correction was included in the original pricing; with the other two vendors, it would have been discovered during migration as a scope change with additional payment.

The lesson here isn't "cheap is always bad"—but that the gap between a detailed answer and a general one is worth real money, and it can only be revealed with targeted questions before signing, not afterward.

Proposal Comparison Checklist

☐ We received names and allocated percentages of the proposed team, not just a general description.
☐ We checked how architectural decisions are documented by each vendor.
☐ We requested a data profiling plan before signing.
☐ We broke down the price into workstreams with estimated hours.
☐ We clarified who absorbs the cost of delays not attributable to the client.
☐ We received an explicit description of the Hypercare period and its terms.
☐ We checked references from clients with similar project scopes.
☐ We verified that the consultant presented in the meeting is the one who will actually work on the project.
☐ We checked how many concurrent projects each lead consultant manages.
☐ We defined in advance what evidence will demonstrate project success at completion.

Concluding Remark: The Questions are a Tool, Not a Ceremony

The purpose of these 15 questions is not to embarrass a vendor or unnecessarily prolong the selection process. It is to reveal in advance where the proposal relies on an unwritten assumption. A good vendor will not be offended by the questions—they will be happy to answer them because it reduces risk for them later. A vendor who evades them, or gives consistently general answers, is thereby providing an answer in itself.

When internal capacity is lacking to run such a comparison process yourself, Consulting and Discovery services are the practical path forward—including building a weighted scorecard, support in meetings with proposers, and comparing answers against objective criteria.

Professional Resources

HPI Pro – Consulting and Discovery — https://hpi.pro/consulting-discovery
Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
HPI Pro – Salesforce Services — https://hpi.pro/services

15 Critical Questions Before Choosing a Salesforce Integrator