Most Salesforce implementations don’t fail during execution. They fail before the kickoff call ends because no one paused long enough to ask the uncomfortable questions before the scope was locked.
I’ve seen it happen across projects of every size. A sponsor eager to show momentum, a consultant under pressure to start billing, a go-live date set in a leadership meeting before anyone looked at the data. The result is rarely a technical failure. It’s a discovery failure showing up later, dressed as a change request.
Get these nine questions answered before you commit to anything.
Table of Contents
Why the Discovery Phase Deserves More Than a Half-Day Meeting
There’s a particular pressure that builds early on Salesforce projects. Stakeholders want progress. Sponsors want to show the board the investment is moving. The temptation is to treat discovery as a formality before the real work starts.
But questions that feel awkward to ask in week one get expensive to ignore by week six. Misaligned stakeholders, forgotten integrations, data nobody has looked at in three years, these don’t stay hidden. They surface as scope disputes, budget renegotiations, and post-go-live cleanup nobody budgeted for.
A solid discovery phase doesn’t slow a project down. It gives everyone an honest picture of what’s actually being built.
The 9 Questions to Get Answered Before You Lock In Scope
These aren’t meant to be fired off in sequence. Think of them as the conversations that make your scoping decisions defensible.
What Business Problem Are We Actually Solving?
“We want to implement Salesforce” is a starting point, not an objective. Before any scope conversation begins, someone needs to articulate, in plain language, what’s broken today and what better actually looks like.
The “5 Whys” technique works well in a short stakeholder interview. Ask why the problem exists, then ask again. By the third or fourth answer, you usually find the real driver. Build the implementation around that, not the surface symptom.
Who Are the Key Stakeholders — and Are They Actually Aligned?
The person approving the budget and the people who’ll use Salesforce daily often have very different ideas about what’s being built. Both need a voice in discovery.
Watch for hidden stakeholders, too. Finance may have requirements around billing integrations. IT Security will care about SSO and data residency. Legal might need field-level visibility controls that nobody mentioned in the brief.
A RACI exercise before kickoff isn’t bureaucracy. It’s how you find out who needs to be in the room before decisions get made without them.
What Does the Current Data Look Like — and Is It Ready to Move?
Data migration is consistently underestimated. Not because people don’t know it’s complex. They do. It’s just because they scope the effort without first looking at the actual data.
Before any migration estimate gets finalised, get a sample export. Even 50 rows from the source system tells you more than an hour of conversation about data quality. How many duplicate Account records? Are Contact emails consistently populated? Did sales reps each invent their own picklist values for the same field?
Volume matters too, not just for migration timelines but for Salesforce storage limits and how automation behaves at scale.
What Systems Need to Connect to Salesforce?
The integration nobody mentioned in week one tends to become the blocker in week eight. It’s almost a rule.
Ask explicitly: What does the ERP look like? SAP, NetSuite, or something built in-house? Is there a marketing platform like HubSpot or Marketing Cloud Account Engagement? A billing system or customer portal? Then ask the follow-up that actually matters: Does it have a modern API, or are you dealing with a legacy system that exports flat files overnight?
An integration matrix, a simple table mapping each external system to Salesforce with sync direction, frequency, and ownership, is one of the most useful documents you can produce in discovery.
How Change-Ready Is This Organisation?
This is not a soft question. Change management determines whether an implementation delivers value, and user adoption doesn’t happen just because you built something technically sound.
Look for a named internal champion. Not just an executive sponsor, but someone who will actively promote the system to the team, using it. Find out whether training time is budgeted. Ask about previous technology changes that “never really took off.”
A short change-readiness survey sent to department heads during discovery takes less than half an hour and can surface real resistance while you can still act on it.
Who Will Own Salesforce After Go-Live?
Implementations that go live without a defined owner tend to drift fast. Fields get added without documentation. Permissions change without review. Release updates arrive, and nobody reads them.
Get specific in discovery: Who approves configuration changes? Who manages user licences? Who keeps the org healthy as the business grows?
This is a governance conversation, and it belongs in discovery. Whether the answer is an internal admin, a managed services arrangement, or a Centre of Excellence, the governance model needs to be agreed upon before go-live, not six months later, when the org is already showing strain.
What Is the Real Budget — and What Does It Cover?
The figure a client has in mind and the number that covers a complete implementation, are often different. Usually not, because no one is being dishonest. It’s because certain costs weren’t visible when the budget was originally set.
Walk through the full picture in discovery: Salesforce licences and editions, custom development, integration build and middleware, data migration effort, training, and post-go-live support. Every line item should be on the table before the scope is agreed upon.
Doing this early prevents the conversation where a client learns their budget covers about 60% of what they actually want.
What Does Success Look Like — and How Will You Measure It?
Vague success criteria don’t just make celebration difficult. They make scope disagreements almost inevitable.
Agree on three to five measurable outcomes before the first sprint. For Sales Cloud, that might be pipeline conversion rate or activity-to-opportunity ratio. For Service Cloud, the average case resolution time or first-contact resolution rate. Wherever you land, establish a baseline for each metric. You cannot demonstrate improvement without knowing where things stood when you started.
Co-creating this scorecard during discovery also builds shared accountability before the project begins.
What Happens After Go-Live?
Go-live is not the finish line. Implementations that treat it as one often unravel within 60 days.
Plan the hypercare period explicitly, typically two to four weeks of elevated support while the system settles in. Define the enhancement backlog process: who logs requests, who prioritises them, and who approves the work. Build training reinforcement into the rollout plan rather than relying on a single session the week before launch.
These conversations belong in the statement of work. Not in a late email thread after something goes wrong.
Turning These Questions Into a Real Discovery Session
These nine questions work best as the backbone of a structured 2-3 hour workshop, rather than as a series of casual conversations spread over two weeks.
Get the right people together: the executive sponsor, the department head for the primary use case, an IT representative, and whoever will manage Salesforce day-to-day after go-live. The output shouldn’t be a 40-slide deck. A one-page discovery brief covering objectives, constraints, open risks, and unresolved questions is more useful and more honest.
That document is what separates a scoped project from a scoped guess.
One Last Thing Before You Kick Off
No checklist covers every situation. A greenfield org for a 15-person startup needs a different discovery conversation than a multi-cloud rollout across four business units. The questions scale; the context always varies.
What stays constant: honest conversations in week one cost nothing. The same conversations in week six cost a lot.
Frequently Asked Questions (FAQ)
For a mid-sized implementation, two to four weeks is a reasonable target. Smaller projects can often cover what they need in three to four focused sessions. If a client is pushing to skip discovery entirely, that’s usually the clearest signal that it’s needed most.
At minimum: the executive sponsor, the department head for the primary use case, an IT or systems representative, and the person who will manage Salesforce after go-live. The right people matter more than a full room.
Yes. The specific metrics and systems change, but the core questions hold across clouds. Question 8 looks different for a Service Cloud rollout case resolution time rather than pipeline conversion, but the logic is the same.
Unanswered questions aren’t a blocker by themselves. They’re a list of open risks that need to be resolved before the scope is finalised. Document each one, agree on who owns the answer, and set a deadline.
Even a single structured hour covering these questions is better than none. Smaller implementations have less room for the errors that a good discovery conversation typically prevents.
Akanksha Shukla
Akanksha is a Content Writer at SalesforceTrail.com, contributing educational content that supports Salesforce professionals in learning, growing, and advancing their careers within the Trailblazer ecosystem.
- Akanksha Shukla
- Akanksha Shukla
- Akanksha Shukla
- Akanksha Shukla
