After this lesson you will be able to
- Separate the stated request ("we need a new CRM") from the business problem that will fund the project.
- Map the people involved: who feels the pain, who owns the budget, who can block, and who will do the work.
- Capture the current systems and data picture well enough to scope realistically and avoid surprises.
- Close every discovery call with a dated, shared plan instead of "we'll be in touch".
Prepare for 20 minutes so you can listen for 40
Discovery goes wrong before the call starts when you arrive with nothing but a deck. Spend 20 minutes on preparation and you can spend the call asking second and third questions instead of first ones.
Read what the customer already owns. Check their current Salesforce products and editions in your org, open cases, renewal dates and any prior opportunities that closed lost. A prior loss is not a reason to avoid the topic. It is the first thing you should ask about.
Write down three hypotheses about why they took the meeting. For example, a 200-person distributor that just added a second warehouse may be struggling with quoting accuracy, inventory visibility for reps, or service case volume. You are not going to pitch these. You are going to test them, and you will probably be wrong about at least one.
- Current products, editions, user counts and renewal date
- Prior opportunities, especially closed lost, and why
- Recent company news: acquisitions, new locations, leadership changes
- Who accepted the meeting and what their role actually controls
- Three hypotheses to test, written down before the call
Find the business problem behind the software request
Customers rarely open with a business problem. They open with a request: "we need better reporting," "we want Agentforce," "our CRM is a mess." The request is a symptom. Your job is to walk it back to something the business measures.
Use a simple ladder. Ask what happens today, then what that costs, then who notices. "Reporting is bad" becomes "the VP of Sales rebuilds the forecast in a spreadsheet every Monday" becomes "the board saw two different pipeline numbers last quarter." Now you have a problem with an owner and a consequence.
Stop laddering when you reach something that shows up in a leadership meeting: revenue, margin, cash, customer retention, headcount, risk or compliance. If you cannot get there, the project will struggle to get funded no matter how much the user likes the demo.
Map the people before you map the process
A Salesforce project touches more people than the one who took your call. Sales leaders, service leaders, finance, IT, an internal admin if they have one, and often a security reviewer. Each has a different definition of success.
Ask about people by role, not by name, early in the call. "Who else would be affected if this changed?" feels safer to a new contact than "who is the decision maker?" Then ask how the last significant software purchase was approved. Past behavior is the most reliable guide to the buying process you will actually face.
Pay attention to who will do the work. Implementation needs a business owner with real hours, not a sponsor who checks in monthly. If nobody can name that person, write it down as a risk now.
- Pain owner: the person whose week gets better if this works
- Budget owner: who signs, and what threshold triggers more approvals
- Blockers: IT, security, legal, procurement, or a competing internal project
- Doers: the admin, the project lead, the subject matter experts
- Users: who logs in daily, and whether they were asked
Get the systems and data picture without turning it into an audit
Scope surprises usually come from systems and data, not features. You do not need an architecture diagram on the first call. You need enough to know what you are walking into.
Ask what system is the source of truth for customers, products, pricing and orders. Ask where the data lives today and how it moves: integrations, nightly files, or a person copying and pasting. Ask how many records, roughly, and how confident they are in them. "Our data is a mess" is useful information, not an objection.
Listen for the ERP, the marketing platform, the phone system and any homegrown tools. Each one is a possible integration and a possible delay. If the picture is complicated, this is the moment to bring a delivery partner into a follow-up call so the estimate is grounded. If you want Abstrakt in that conversation, ask through the deal desk at /salesforce-account-executives/deal-desk/.
Find the date that matters and the reason it matters
"We'd like to be live by Q2" is a wish. "Our current contract ends June 30 and we lose access to the old system" is a timeline. Your job is to find out which one you have.
Ask what happens if nothing changes for six months. If the honest answer is "not much," the timeline is soft and your forecast should reflect that. If the answer involves a renewal, a hiring wave, a new product launch, an audit or a seasonal peak, you have a real date.
Then work backward with the customer. Implementation needs time, and so does their approval process. Point them to a realistic view of implementation length at /resources/how-long-does-salesforce-implementation-take/ rather than promising a date you have not tested.
Turn discovery into a mutual plan before you hang up
The last ten minutes of the call matter more than the first fifty. Play back what you heard in three sentences: the problem, the consequence, the date. Ask them to correct you. Corrections are good. They mean the customer is engaged and you are about to get more accurate.
Then propose a short written plan with dates and owners on both sides: who you need to meet next, what information they will share, when you will bring a scoped estimate, and when a decision is expected. Send it the same day as a simple shared document, not a slide.
A mutual plan is not a closing tactic. It is a test. If the customer will not commit to a next step with a date, you have learned something important about priority, and you learned it early.
If the customer is new to Salesforce projects, send them our buyer-side guide at /resources/how-to-prepare-for-salesforce-discovery/ so they arrive at the next meeting with the right people and data.
Talk tracks
Opening the call
“Before I share anything, I'd like to understand what made this worth an hour of your time right now. What changed recently that put this on your list?”
It surfaces the trigger event, which usually points straight at the business problem and the timeline.
When the customer leads with a feature request
“That makes sense. Help me understand what happens today without it. Who feels that, and how often?”
It moves the conversation from a feature to a problem with an owner.
When you need to learn the buying process
“Think about the last time your team bought software in this price range. Who got involved, and what slowed it down?”
Past behavior predicts the approval path better than an org chart does.
When the customer says their data is a mess
“Thanks for being straight about that. Most teams say the same thing. Which data do you trust least today, and what decisions does it affect?”
It normalizes the problem and turns it into scoping information instead of a reason to delay.
When the timeline sounds soft
“If we did nothing for the next six months, what would that cost you, or would it be fine?”
It tests urgency without pressure, and an honest "it would be fine" saves you a quarter.
Closing the call
“Let me play back what I heard, and please correct me. Then I'd like to put the next three steps and dates in a short shared document so we're both working from the same plan.”
It checks your understanding and converts the conversation into commitments on both sides.
Discovery call capture sheet
Use it on a live deal. Tick items off as you go; nothing you tick leaves this page.
Common mistakes
Demoing in discovery
Showing the product before you understand the problem turns the call into a feature review. The customer evaluates screens instead of telling you what hurts.
Accepting the first answer
"We need better visibility" is the start of discovery, not the finding. Ask at least two follow-up questions before you write anything down as the problem.
Single-threading
Building the whole deal on one friendly contact leaves you exposed when budget owners and IT appear late. Ask about other roles in the first call.
Skipping systems and data
Integration and data work drives cost and timeline. Leaving it for later produces an estimate that grows after signature and damages trust.
Ending with "I'll follow up"
Without a dated next step, deals drift. Every call should end with a specific meeting, owner and date.
How you will know it is working
- The customer corrects your playback with new details instead of just agreeing.
- You can state the business problem, its owner and its deadline in one sentence.
- Your mutual plan has names and dates on the customer's side, and they meet them.
- Scope estimates change less between first proposal and signature.
Questions
How many discovery calls should a Salesforce deal need?
It depends on scope, not a fixed number. A small Sales Cloud expansion may need one call. A multi-cloud project with integrations often needs separate sessions with the business owner, IT and finance. Plan for as many as it takes to fill the capture sheet honestly.
What if the customer will not share budget?
Do not force it on the first call. Ask how similar purchases were approved and what range would need extra approval. Once you have a business problem with a cost attached, budget conversations get easier because you are discussing return, not price.
Should I bring a partner to the first call?
Usually not to the very first call, which is about the customer's problem. Bring a delivery partner once systems, data or integrations come up, so the estimate reflects reality before you put a number in front of the customer.
How is this different from the buyer-side discovery guide?
This lesson is for you as the seller. The buyer-side guide at /resources/how-to-prepare-for-salesforce-discovery/ helps the customer prepare their people and data. Sending it ahead of your second meeting makes that meeting more productive.