The Discovery Call: Understand the Work Before Proposing It

Prepare hypotheses, not an advance diagnosis

Review relevant public information and what the person has already shared. Note what you think you understand, what you need to ask and what remains unknown. “The catalog is outdated” may be a hypothesis; an old-looking page alone does not make it a fact.

Salesforce places discovery calls early in the sales process to understand needs and motivations. That reference explains the conversation’s place, not a guarantee that you should sell a solution. We suggest clarifying purpose and available time first: “I would like to understand how you update the catalog and what is difficult.”

Ask about a recent episode

In a fictional example, a shop requests a website redesign. Instead of asking whether it wants “more conversions,” ask about the last product update: what changed, who collected the information, where it was approved and what remained unresolved. An episode reveals details that a general objective can conceal.

Continue with open questions: “What happens when a photograph is missing?” or “Who notices that the price has changed?” Avoid inserting your solution into the question: “Would automation not be better?” asks someone to approve an idea before you understand the process. If an answer is ambiguous, request an example rather than treating it as confirmation.

Clarify conditions that change the proposal

• Outcome: what the team should be able to do afterward.
• Information: what exists, who maintains it and what is missing.
• Participants: who reviews, decides and uses the deliverable.
• Conditions: availability, desired date and limits on shared resources.
• Evaluation: what the person needs to judge whether the scope fits.

You need not complete an entire questionnaire. Select questions that affect the actual scope and explain why you ask them. If sharing a detail is premature, record it as missing. Do not turn the first conversation into a request for passwords, sensitive documents or broad systems access.

Reflect your understanding with its limits

A fictional summary might say: “The pages are editable, but product information arrives in several chats. You want a common record and reviewer before changing the design. We still need to know whether the current catalog can be exported.” This separates observations, preferences and questions without treating the request as a sale.

Ask whether the summary describes the situation correctly and amend it together. Avoid promising that a redesign will resolve information problems you have not reviewed. For the subsequent record, our customer next-step guide distinguishes context, states and agreements.

Agree a next step supported by the evidence

If scope is clear, prepare a proposal. If a sample is missing, agree who will send a permitted file and when it will be reviewed. If the problem lies outside your work, say so and identify whether there is a reasonable alternative. Another meeting is unnecessary when a written clarification resolves the issue.

Write the action, owner and timing, distinguishing a suggested date from an agreed one. Salesforce’s sales-process material places needs discovery before later steps; our practical application avoids counting a friendly response as acceptance. After sending a proposal, use our follow-up guide.

Keep a note someone else can continue from

Use five fields: described situation, desired outcome, confirmed conditions, open questions and next action. Keep only necessary information in an authorized location. If you later publish an example, remove identifying information and never attribute a fictional story to a real client.

Before quoting, review the note: which scope elements came from an answer, and which from your own assumption? Our validation guide helps keep that distinction visible. Judge the conversation by the clarity achieved without claiming close rates you have not measured.