销售、售前、客户调研和跟进

销售最怕的不是没客户，是方案建立在猜测上

销售和售前的难点不在写方案，而在“客户到底要什么”。很多方案写得很漂亮，一到客户那里就被问住——因为方案建立在推测上，不是建立在已确认的需求上。把推测写进事实表，方案越详细，错得越远。

正确做法是把资料分成三张表：事实（有来源的客观信息）、假设（推测，需访谈验证）、待确认问题（需要在访谈中问清楚的）。事实有来源，假设要验证，承诺必须人工审批。

主案例：会前调研到售前方案草稿

场景：下周要拜访一家企业客户，目标是摸清对方需求和预算，形成一份能推进的售前方案草稿。

第一步：整理公开资料，分三张表

把客户官网、公开新闻、招聘信息、已有沟通记录和我方产品资料放进工作目录。区分有合法权限使用的资料和外部公开信息，分三张表：

整理客户公开资料与我方产品资料，分三张表：
1. 事实表：客户业务、组织、近期事件、公开需求信号，每条附来源；
2. 假设表：基于事实的推测，标注需要访谈验证的假设；
3. 待确认问题：方案必需但资料里没有的。
约束：不得推断未公开经营数据，不承诺未核验功能和价格。
输出 one-page-brief.docx、hypothesis-list.md、questions.md。

ps：不要把推测写进事实表，否则方案会建立在猜测上。

第二步：生成按角色组织的调研提纲

围绕业务目标、现有流程、数据、系统、安全和采购设计 30 分钟访谈提纲，每个问题写明希望验证的假设。访谈提纲不是产品推销清单：

准备一次企业客户需求访谈，30 分钟。
输入：客户官网、公开新闻、已知联系人角色、产品资料。
动作：整理事实，提出业务、流程、数据、安全和采购问题。
约束：不得推断未公开经营数据，不承诺未核验功能和价格。
输出：一页客户简报、30 分钟访谈提纲、风险清单。
验收：每个事实有来源，每个问题说明希望验证的假设。

问题方向	希望验证的假设
业务目标	客户今年核心增长指标是什么
现有流程	当前用什么工具、卡在哪一步
数据	数据在哪、口径是否统一
系统	已部署哪些系统、是否要集成
安全	数据分级、合规要求
采购	预算周期、决策链、拍板人

第三步：把访谈记录转成需求与机会清单

访谈后把记录转成结构化清单，区分已确认需求和待确认需求：

把访谈记录转成需求与机会清单。
已确认需求：客户明确表达过的，附访谈原文位置；
待确认需求：推测或间接提到的，标记待确认；
机会清单：我方产品能覆盖的痛点，标注匹配度。
不把假设写成已确认需求。输出 needs.xlsx 和 opportunity.md。

第四步：基于已确认需求制作方案草稿

基于已确认需求制作方案草稿：方案大纲、澄清问题、PPT 草稿。未确认的需求写成“待确认”，不写成承诺：

基于已确认需求制作售前方案草稿。
包括：客户背景、痛点分析、推荐场景、实施路径、预期收益、演示流程。
功能、价格、效果、交付周期承诺必须由人工审批后才能写入，未确认的标为待确认。
输出 proposal-outline.md 和 proposal-draft.pptx。
验收：每个推荐场景能对应到客户痛点或需求信号。

ps：所有功能、价格、效果、交付周期承诺必须由人工审批后才能对外。不编造客户经营数据，不承诺未核验的功能。

延伸：根据产品资料形成异议处理

客户常问“和某某产品比有什么优势”“能不能保证效果”。把产品资料和历史异议整理成异议处理库，每个异议对应一句话回应和证据来源，不能保证的效果明确说“待确认”。

销售售前常见错误

常见错误	为什么会发生	更好的写法
把推测写进事实表	想让简报好看	事实有来源，假设单独成表待验证
访谈提纲变成产品推销	急于展示	每个问题写明希望验证的假设
未确认需求写成承诺	想让方案有吸引力	未确认的标“待确认”，承诺必须人工审批
编造客户经营数据	资料不够就猜	不得推断未公开数据，缺的列入待确认
功能效果数字不核验	信任 AI 输出	功能、价格、效果留待产品资料核验