需求诊断通话：先理解工作，再提出方案

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

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

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

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

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

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

明确会改变提案的条件

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

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

连同边界一起复述理解

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

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

依据证据约定下一步

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

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

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

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

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