让大模型成为销售顾问：
从共性回答到基于业务上下文的建议

为什么大模型的销售建议，常常“正确却不解渴”？

很多销售人员已经开始直接使用 DeepSeek 等大模型，咨询日常销售中遇到的问题：

• “客户说价格太高，我该如何应对？”

• “项目迟迟没有进展，下一步应该怎么推进？”

• “我准备拜访客户，请帮我列一份沟通提纲。”

但实际使用中，回答经常停留在“进一步挖掘需求”“突出产品价值”“建立客户信任”“加强关键人沟通”等共性建议上。这些建议可能合理，却难以告诉销售：今天应该联系谁、先确认什么、拿出什么证据，以及争取客户作出什么承诺。

销售问：“客户觉得报价贵，应该怎么办？”

如果没有更多背景，模型只能围绕价格异议的一般处理方法作答。它不知道你卖的是标准产品还是复杂解决方案，不知道你能否降价，也不知道说这句话的人是否有采购决定权。

同样一句“太贵了”，可能意味着预算不够、比较口径不同、价值尚未得到认可，也可能只是采购人员例行议价。不同原因对应不同动作。缺少背景时，模型难以区分这些情况。

因此，改善回答质量，不能只靠把问题写得更长，或要求模型“扮演顶级销售专家”。还需要让模型获得足够的业务上下文。

业务上下文：让通用知识适用于眼前的销售任务

业务上下文，是指与当前销售任务有关的业务背景、事实、规则和限制，供模型在分析与回答时使用。它的作用，是帮助模型在多种可能的建议之间作出更贴合实际的选择，并说明判断依据。

销售对话需要两类互相配合的上下文：

特有销售场景描述的是你的企业、业务或产品线通常怎样开展销售，包括客户为什么购买、如何争取业务、如何逐步推进。它相对稳定，可以在多个项目中复用。

具体项目情况描述的是某个客户的某次采购：真实需求是什么、有哪些联系人、谁参与决策、谈到了哪里、最近发生了什么。它随着项目推进持续变化。

只有销售场景，模型容易给出适合这一类业务、但还不够贴合当前客户的建议；只有项目记录，模型又可能不了解你的优势、权限和交付边界。两类信息共同存在，才更有利于形成可执行的判断。上下文能够改善建议的针对性，但不能替代销售对事实和行动可行性的核实。

项目情况：用一个持续会话，不断补充与校正

对于个人销售或小团队，项目上下文可以先通过固定会话积累。建议一个商机维持一个会话：在开始时介绍客户、采购项目、联系人及其角色、当前需求和进展；每次沟通后继续补充新情况。

同一个客户的不同采购项目，可能有不同的预算、决策人和时间表，适合分别维护会话；同一项目中的多个联系人，则应放在同一个项目背景下分析。

补充“发生了什么”，也补充“哪些信息变了”

11 月 3 日，与采购经理王经理沟通。客户认为报价偏高，但没有说明比较对象。王经理负责方案比较，最终由李总审批。此前提到的 20 万元只是初步估计，尚未确认预算。双方约定周五进一步核对采购范围。

请更新项目判断，并建议下一次沟通优先确认的三个问题。

这样的记录明确了时间、人物、信息来源和待确认事项，也避免模型把早期估计当成确定事实。客户的原话、销售的判断和双方已经作出的承诺，最好分别说明。

持续会话需要配合一份最新项目摘要

固定会话可以帮助模型利用已有记录，但并不意味着它会永久、完整地记住全部历史。对话过长时，受上下文容量和平台处理方式影响，早期内容可能被省略或压缩。

每次重要沟通后，可以要求模型更新“项目摘要”：列出已确认事实、联系人角色、需求与预算、关键障碍、待验证判断、双方承诺和下一步。销售核对后另行保存；必要时把最新摘要重新提供给模型。同一会话解决的是项目信息的持续积累，摘要和人工核对帮助维持信息的一致性。

如果建议有效，只是对话上下文压缩成为问题，或者使用过于繁琐，甚至需要进一步扩展 AI 在你的销售中的应用，你可以升级为 AICRM。

特有销售场景：归纳为三个方面

项目记录可以随着日常对话逐步积累，但模型不会仅凭这些记录就完整理解企业的销售方法。企业需要主动梳理一份可复用的销售场景说明，核心包括：解决方案价值主张、销售策略和销售流程。

一、解决方案价值主张：客户为什么购买？

价值主张要把“我们提供什么”与“客户为什么愿意为此付费”联系起来。除了产品功能，还要说明适用客户、典型问题、业务影响、解决方式、独特价值，以及能够支持这些说法的案例或验证方法。

需要梳理的问题包括：我们的方案适合谁？解决什么重要问题？何时问题会出现或更大？客户的购买动机是什么？客户可以获得什么收益？相比现有做法或其他方案，有哪些差异？哪些收益有证据，哪些需要结合客户数据验证？方案有什么适用条件和能力边界？

这些信息帮助模型围绕客户关心的结果表达价值，筛选相关案例，并避免承诺企业无法交付的能力。

示例：销售设备管理系统，价值可以表述为“帮助存在设备停机问题的制造企业，改善故障发现与维修协同”。具体能减少多少损失，需要依据客户的停机数据和试点结果评估，不能仅凭功能介绍承诺收益。

二、销售策略：这类业务通常如何赢？

销售策略决定机会选择、竞争策略和资源优先投入。需要说明优先从哪里入手，通常从哪个角色切入，如何接触决策人，面对竞争时如何建立优势，以及哪些情况下值得继续投入或应该退出。

延续前面的示例：先从设备负责人了解问题，再用停机损失及改善方案争取工厂负责人支持；必要时开展小范围试点。是否投入工程师陪访，应结合问题的明确程度、客户配合意愿和资源安排判断。

企业提供的是常用打法和约束。面对具体项目，模型仍应根据客户事实判断策略是否适用，并说明需要调整的理由。

三、销售流程：现在处于哪一步，怎样才算推进？

销售流程把项目推进拆成可以判断的阶段。判断目前处于哪个阶段，赢率多少，每个阶段的明确目标、需要获取的信息、关键动作，以及进入下一阶段的条件。

其中最重要的是：阶段推进要有客户行为或确认作为证据。仅凭“销售发了资料”“做了演示”“提交了报价”，很难判断客户是否真的向采购迈进。

有了这些标准，模型就能检查当前阶段是否有依据，指出缺少的关键信息，并把下一步建议落在“争取客户确认什么”上。不同业务应有自己的阶段设置，不能机械套用同一条流程。

把两类上下文放进同一次判断

实际使用时，可以先在项目会话中提供销售场景说明，再加入项目资料。之后每次提问，只需补充新的沟通记录和本次希望解决的问题；当产品能力、销售政策或资源条件变化时，再更新场景说明。

例如，沿用设备管理系统的假设场景，销售补充：“设备负责人看完演示很认可，但说采购觉得价格高。我们还没有确认停机损失，也没有接触最终审批人。”

结合两类上下文，模型就可以给出更聚焦的建议：

当前判断：使用部门表现出兴趣，但价值尚未经过量化验证，也缺少明确的采购决策信息。采购提出价格异议的具体原因仍需确认。

下一步：先与设备负责人核实停机问题和可用数据，了解谁批准项目、依据什么批准；同时确认采购比较的方案与服务范围。根据结果判断是否安排试点或调整方案。

推进标准：客户愿意提供必要数据，并共同确定下一次方案评审或试点讨论的参与人和时间。

这里，价值主张帮助确定需要证明的业务收益；销售策略帮助选择沟通对象与资源；销售流程帮助识别距离下一阶段还缺什么；项目事实则决定这些方法此刻如何使用。

可以要求模型每次按“事实与依据—待验证判断—优先行动—沟通话术—推进标准”的顺序回答。行动执行后，再反馈实际结果，持续修正判断。

通过三个辅导入口，萃取文档并提交给大模型

把销售经验转化为大模型可以使用的上下文，可以分三步完成：在三个专用网页中接受辅导，分别萃取并导出文档；核对三份文档的内容与适用范围；将它们一起提交给大模型，再补充具体项目情况。

第一步：分别梳理，形成三份上下文文档

先选择要梳理的解决方案和目标客户细分，带上已有的产品介绍、客户案例、销售经验和流程资料，依次使用下面三个入口。根据网页的引导补充信息、检查生成结果，将实际做法与适用边界写清楚。

1. 解决方案价值主张
   进入价值主张画布辅导 ↗
   www.xksky.com.cn/vp

   梳理目标客户的问题、业务影响、解决方式、预期价值、差异化优势及证据，明确方案的适用条件和能力边界。核对后导出一份《解决方案价值主张》Word 文档。

2. 销售策略
   进入销售策略辅导 ↗
   www.xksky.com.cn/strategy

   围绕一个明确的客户细分和一个解决方案，梳理客户选择、关键角色、切入方式、竞争打法和资源投入。导出的《销售策略》Word 文档应清晰描述适用的客户细分、解决方案及其范围，避免把不同业务的打法混在一起。

3. 销售流程
   进入销售流程梳理 ↗
   www.xksky.com.cn/salesprocess

   以我们提供的标准销售流程为起点，通过“流程 → 阶段 → 活动”的树状结构核对并调整销售步骤，补充阶段目标、关键活动和客户推进标准。完成后导出一份《销售流程》Word 文档。

第二步：核对文档，一起提交给大模型

检查三份文档是否对应同一套业务场景，尤其确认价值主张中的能力、销售策略中的承诺和流程中的动作相互一致。

在支持文档上传与解析的大模型中，新建一个具体商机的会话，将三份 Word 文档一起上传。先要求模型分别概括三份文档的适用范围与关键约束，列出遗漏或冲突，核对理解后再咨询项目问题。如果当前工具不支持读取 Word 文件，可以将文档正文分别粘贴到同一会话中。

三个网页用于辅导萃取销售场景；导出的三份文档用于向大模型提供上下文。应提交文档内容，而不只是把三个网页地址发给模型。

第三步：补充项目情况，持续获得推进建议

在同一个会话里补充客户、商机、联系人角色、最新沟通和本次目标。三份文档提供销售方法与边界，项目记录提供实时事实；后续每次沟通后继续更新项目情况。会话过长时，用最新文档和经核对的项目摘要重新建立上下文。

上传三份文档后，可以直接发送以下指令：

我已提交以下三份文档，请将它们作为本会话的销售场景上下文：
1.《解决方案价值主张》：理解客户价值、差异化、证据和能力边界。
2.《销售策略》：理解适用的客户细分与解决方案、关键角色、竞争打法及资源约束。
3.《销售流程》：理解阶段目标、关键活动和客户推进标准。

请先确认你实际读取到了哪些文档，分别概括其适用范围和关键约束。
如果文档缺失、无法读取，或内容之间存在冲突，请明确指出并向我确认，不要自行补全。

以下是当前项目情况：
客户与采购项目：
对应的客户细分和解决方案：
联系人、角色及已知决策关系：
已确认需求、预算与采购时间：
当前进展、竞争情况及判断依据：
最新沟通记录（注明日期与客户原话）：
我的权限与当前可调用的资源：
双方承诺、待办事项和本次希望解决的问题：

请结合三份文档和项目事实，帮助我推进商机：
- 区分已知事实、推测和未知信息，说明所依据的文档内容与项目记录。
- 信息不足时，先问最多三个影响下一步选择的问题。
- 给出最多三项优先行动，明确找谁、做什么、争取什么结果。
- 提供自然的沟通话术，以及判断是否推进的客户行为标准。
- 不编造预算、决策关系、收益或成交概率，不超出我的权限和交付边界。
- 收到新记录后，更新项目摘要，标明变化及待确认事项。

三份文档可以在适用的项目之间复用；每个商机分别维护自己的项目情况。产品能力、客户细分、销售策略或流程发生变化时，更新对应文档，并把新版本提交给模型，说明替代哪一份旧版本。

本文案例均为方法说明，不代表真实客户项目或效果承诺。录入客户资料时，应遵守企业的数据使用要求，只提供分析所需的信息。