La llamada de diagnóstico: entiende el trabajo antes de proponerlo

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.

准备假设，不要提前下诊断

阅读相关公开资料，以及对方已经分享的信息。记下你认为理解的部分、需要询问的问题与未知事项。“商品目录过时”可能是假设，但页面看起来陈旧本身不能证明它。

Salesforce 把需求诊断通话放在销售早期，用于理解需求与动机。这说明沟通的位置，不保证一定应该销售某个方案。我们的建议是先明确目的与可用时间，例如：“我想了解你们怎样更新目录，以及哪里处理起来困难。”

询问最近发生的一次具体过程

在虚构案例中，一家店希望重新设计网站。不要只问是否想要“更多转化”，而是请对方回顾上一次商品更新：改了什么、谁收集资料、在哪里批准、还有什么没解决。具体事件能揭示一般目标中隐藏的细节。

继续用开放问题，例如“缺少照片时怎么办？”或“谁发现价格已经变了？”避免把方案塞进问题：“自动化不是更好吗？”会让对方在你理解流程之前就赞同想法。回答含糊时，请对方举例，不要直接当成确认。

明确会改变提案的条件

• 结果：结束后团队应该能够做什么。
• 信息：已有材料、维护者与缺口。
• 参与者：谁审核、决定并使用交付物。
• 条件：可用时间、期望日期与共享资源限制。
• 评估：对方需要什么才能判断范围是否合适。

不必机械地问完整份清单。选择会影响实际范围的问题，并说明为什么要问。暂时不适合分享的数据，就记为待确认。不要把第一次沟通变成索要密码、敏感文件或全面系统权限。

连同边界一起复述理解

虚构摘要可以是：“页面本身可以编辑，但商品信息来自多个聊天。你们希望先统一资料表和审核人，再改设计。还需要确认现有目录能否导出。”这样区分观察、偏好与问题，不把询价当作成交。

请对方确认摘要是否准确，并一起修正。不要承诺重新设计就能解决尚未检查的信息问题。记录后续情况时，本站客户下一步指南帮助区分背景、状态与约定。

依据证据约定下一步

范围清楚时，可以准备提案；缺少样本时，约定谁发送获准分享的文件、何时检查；问题不在服务范围时，直接说明，并判断有没有合理替代方案。如果书面澄清就能解决，不必再安排会议。

写明行动、负责人和时间，区分建议日期与已同意日期。Salesforce 的销售流程资料把理解需求放在后续步骤之前；我们的具体应用是避免把友善回答当作接受。提案发出之后，可参考本站跟进指南。

留下别人也能继续处理的记录

采用五项记录：描述的情境、希望达到的结果、确认条件、开放问题与下一步行动。只在获准位置保存必要信息。若日后发表案例，应去除身份信息，也不要把虚构故事归给真实客户。

报价前检查记录：范围的哪些部分来自回答，哪些只是自己的假设？本站验证指南帮助保留这种区分。用获得的清晰程度评价沟通，不要声称未经衡量的成交率。