潜在客户期待一个并不存在的功能：如何回应 AI 造成的承诺

把真实需求与编造的细节分开

设想一家销售项目平台的公司。有人预约演示，因为某个助手告诉他，这套系统可以起草并签署合同。如果团队只想证明究竟是谁弄错了，沟通很容易偏离目标。更有用的问题是：对方需要管理哪种文件，谁来批准，以及希望改善哪一段工作。即使所描述的功能不存在，背后仍可能有一个真实的协作需求。

诚实的回答可以很简洁：该功能目前不包含在产品中；产品实际能做的是这些；我们一起看看是否符合你的需要。不要为了维持兴趣而暗示功能很快就会上线。如果集成或额外开发可能有帮助，应把它说明为需要评估、范围尚待约定的选项。清楚说明能够保护双方时间，也让客户决定是否继续。

了解背景，但不要要求客户替你调查

不要让潜在客户负责诊断你的线上形象。如果他能提供文字、链接或截图，就用来确定具体说法。如果什么都没有保留，应把他的解释记录为个人感受，而不是某个系统回答过什么的证据。也不要因为客户记得使用过某个知名工具，就把问题直接归因于那个引擎。

销售可以记录客户期待的功能、它对采购决定的影响，以及客户记得的信息来源。将这些观察与已经确认的产品信息分开，避免把虚构功能继续写进提案、会议纪要或 CRM 记录。在向其他部门分享之前，删除审查这件事并不需要的个人信息。

判断需要修改页面、沟通方式，还是两者

一次事件不能证明所有公开信息都有问题。检查产品页面和销售常发的文件：是否使用了含糊的动词，是否把可选集成与已包含功能放在一起，或者是否在没有条件说明的情况下描述了某个特定案例。也可能网站已经很清楚，而 AI 回答在缺少依据时扩大了原意。

围绕能够导向具体决定的问题组织审查。你不必重建一条无法观察的技术链路；需要找到的是哪些公开说法值得进一步明确。如果唯一证据是一个潜在客户的解释，就先改善销售沟通。如果多个联系人都带着同一期待，并指出同一个含糊页面，就有了更充分的内容调整理由。

• 这个功能是已包含、单独配置，还是需要另行报价的开发？
• 示例是否只属于特定案例，页面有没有说明？
• 销售材料是否与当前产品页面一致？
• 由谁负责批准更新后的描述？

准备可以复用、但不显得防御性的回答

销售、营销和产品部门需要对范围有共同解释。一份简短参考材料可以放在一起：客户的问题、已确认的回答，以及产品说明链接。目的不是让大家背诵脚本，而是避免每个销售临时作出不同承诺。也应加入一个问题，帮助区分某项功能究竟是采购必需条件，还是次要偏好。

例如：“你需要工具直接签署合同，还是需要团队协调审批？”这个区别会改变讨论和适合的解决方案。保持参考材料为当前版本，并明确谁可以处理疑问。如果一句话需要技术确认，最好发送前就确认范围，而不是让安抚客户的解释又变成一个难以实现的期待。

观察误解是否再次影响采购决定

AI Visibility 审查可以帮助团队检查同一说法是否出现在相关提问中，并查看回答展示的来源。Wiwo.MetriQ 支持在分析范围内审阅回答及其依据。这些观察有助于团队围绕证据讨论，但不能单独证明有多少人见过错误，或因此损失了多少销售。

调整材料之后，同时回看观察到的回答与后续销售沟通。寻找适度且有用的迹象：关于该功能的澄清减少、提案范围更一致，或者团队更理解某项异议。保留尚未解决的问题。理想结果是下一个买家能够评估你真正提供的产品，而不是让网上所有回答逐字重复你的文案。