B端/G端产品经理兼售前早已是常态，但真正做好售前远不止念PPT。本文从实战出发，拆解售前准备、需求挖掘、现场答疑与决策边界，教你如何听懂客户潜台词、接住突发问题，避免“什么都答应”或“什么都不知道”的坑，把每一次交流变成项目推进的契机。

不是所有公司都会把售前、产品、运营、运维分得清清楚楚。

尤其是做B端、G端的，产品经理兼售前、市场、商务、运维、培训、项目管理，实在不是什么新鲜事。

之前写《国企产品经理=全能ACE》的时候，我记录过自己一周的工作。上午看外包写的需求，下午给领导准备汇报材料；今天出差做系统培训，明天联系客户准备产品宣讲；刚讨论完报价，回来还得协调开发排期。

那你看看我干的都是些什么？

虽然名字叫产品经理，实际上只要跟这个产品或者项目相关的事儿你都得盯着。

“产品经理”只是个名号而已。

所以我之前总说，产品经理看着入行门槛很低，但对综合素质要求极高，不然你没办法处理这么多类型和这么多线条的事儿。

扯回来。上篇我们聊了产品经理需要了解的一些项目知识，这篇接着说售前。

这里主要讨论的是B端、G端项目里，产品经理自己对接客户、介绍产品、讨论方案、演示系统，以及参与报价和交付评估的情况。

很多人对售前的理解，就是做个PPT，去客户那开着演讲者模式念一遍。

真正做过就知道，PPT可能是里面最容易准备的东西。因为它是确定的，可提前准备的。

难的是，对方随时会问出一个你没准备过的问题，而你需要马上听懂、判断，再给出一个合适的回答。

不能什么都答应，也不能什么都不知道。

01 去之前，先弄清楚这次要谈什么

售前工作经常开始得很突然。

领导转过来一个联系方式，让你去了解一下；客户发来几份资料，希望下周听听方案；或者之前聊过的一个意向，突然说可以安排见面了。

然后你就急着打开那份用了很多次的产品宣讲PPT。

但你先别急。

至少要提前了解：对方是什么单位，主要做什么业务，为什么想看这个产品，这次有哪些人参加，希望重点聊什么。

第一次接触，和已经准备采购，需要谈的内容是不一样的。

第一次交流，对方自己可能都没想清楚，你需要多留时间听。

要是已经看过几家供应商，开始进行方案比较的时候，再花半小时介绍公司发展历程，人家可能就有点坐不住了。

参会的人也很重要。

给领导讲，要说明能解决什么问题、需要投入什么、准备怎么推进。业务人员更关心自己的工作能不能顺利完成，会不会给自己增加负担。信息部门可能会追问部署环境、数据安全性、账号体系、数据来源和接口。

提前知道谁来，才能准备对应的内容。

如果信息不全，就先打个电话或者发消息沟通一下。没必要等见面了才发现，对方想了解的是资金监管，你准备的却是一整套财务核算介绍。

当然，如果对方无法提前确定，那就尽可能多准备一些资料，到了现场总能确定吧，再见机行事，挑他们感兴趣的讲。

预算和时间也要尽量了解。

前几次接触一般是比较难问到具体预算的，除非你跟人家已经很熟了。

但至少要知道，这大概是个多大量级的工作，几十万和几百万，差别还是很大的，方案也是天差地别；

还有，对方是在了解市场、准备内部立项，还是已经有了预算和明确的建设节点。

不同阶段的应对方式也是不一样的。

有的客户还在初步了解阶段，你就组织研发评估、做定制原型、写几十页方案，忙了一个星期，人家最后来一句：我先看看。你都不知道该怎么跟项目组交代。

工作很饱满，项目还没影儿。

02 介绍产品，要顺着客户的关注点讲

产品经理介绍自己的产品，很容易陷入一种状态：这个功能也挺好，那个模块也不错，恨不得全部展示一遍。

打开系统，从首页讲到系统管理，菜单挨个点。

讲了四十分钟，自己口干舌燥，对方也很配合地点头。

最后客户问，那我们现在这个事情，到底能不能做？

好家伙，白讲了。

客户更关心的是，自己的需求放进这套系统里，准备怎么处理。

比如给劳务公司介绍薪酬产品，对方可能更关注：员工在不同用工单位，工资数据怎么收；有些按月薪，有些按工时或计件，怎么计算；算完之后怎么审核、怎么发出去。

那就沿着这件事讲。

先看员工和用工单位怎么管理，再看岗位和计薪方式怎么配置，工作量怎么进来、工资怎么核算，最后怎么进入代发。

组织设置、角色配置、报表模板，有必要涉及的时候再展开。

不要把产品宣讲和产品培训搞混了，第一次见面就想把客户培训成系统管理员。

也别只顾着自己讲，要留意对方在哪里开始有表情、讨论，要停下来听听对方的想法。

同一个环节反复问了几次，可能就是他们现在最头疼的地方。这个时候就要停下来，让对方说说目前怎么处理，哪里不方便，想达到什么效果。

如果方便，看看脱敏后的表格、单据或者现有系统，比干对着PPT念有用得多。

有嘀咕是好事儿，代表有戏；很多时候一言不发才可怕，很可能等你讲完就再一言不发把你送走了。

产品优势也应该结合这些问题讲。

原来需要反复整理的材料，现在怎么能自动归整起来；原来靠人工核对的内容，系统能检查哪些；原来几个人来回传的表，现在可以怎样协作。

什么降本增效这些黑话，可以说，但不能干说，要有佐证。到底省了谁的什么工作，提了谁的效率，降了哪里的本，得说得出来。

03 现场能不能接住问题，非常考验经验

我觉得，这是产品经理做售前特别重要的一项能力。

你准备得再充分，客户也不会按照你的PPT顺序提问。

讲到报表，对方突然问能不能增加几个统计维度；讲到付款，又问能不能跟他们现有的ERP打通；刚讨论完一个流程，另一位负责人又补充了一个特殊情况。

你需要在很短的时间里判断：对方真正想问什么，产品现在能支持到哪里，还缺哪些信息，哪些可以当场回答。

这也是为什么有新员工进来的时候，我会让他们跟着老员工去售前现场听一听。

不是说让他们马上就能讲。

先听客户会问什么，听老员工怎么接，怎么追问，怎么把一个模糊的需求逐渐聊清楚。

比如客户问，报表能不能加。

有经验的人通常不会立刻说需要回去评估，也不会直接承诺所有报表都能做。

基本判断是，基础数据有了，报表大多都好做，先看看具体想统计什么。

然后再往下问：这些数据现在有没有，存在我们系统里还是其他地方，统计口径是什么，需要按什么时间和范围来看。

如果只是把现有数据换几个维度汇总，通常就可以先给出可行的判断。

如果客户想看的数据压根不在自己现有系统里，那就要说明，这件事还涉及前面的数据来源和采集工作。

再比如客户说，要跟他们某个ERP打通。

听到这里，脑子里应该马上冒出几个问题：对方有没有开放接口，有没有接口文档，想同步什么数据，由哪边发起，谁能配合对接。

如果连对方系统是否支持对接都不知道，就不能直接承诺。

但也不能只回一句，接口问题我要问问开发。

一些基础的技术知识产品经理也要懂，你不可能每次出去开会都找个开发跟着。

如果实在涉及到比较深入的技术问题无法解答，至少应该先把能问的信息问出来，知道回来具体需要找研发评估什么。否则研发追问一句，你还得再去找客户，一来一回，信息越传越碎，人家也会觉得你很不专业。

这些现场反应没有书本会教你，都是一个个项目、一个个客户磨出来的。这就是经验，是老产品经理的价值所在。

听得多了，遇到的问题多了，你才会逐渐知道，对方说出一句话，背后可能的考量是什么；哪些问题继续追问两句就能判断，哪些确实超出了自己的能力范围。

产品经理这个岗位发展时间不算长，实际工作的差异又很大，它不是一个学院派的东西。至少我接触到的很多产品经理，都是“干中学”，在具体项目里一点点练出来的。

书可以帮你建立一些基本认识，但最好的成长，都是在实践中实现的。

跟着去几次现场，回来把没听懂的地方弄清楚，再慢慢接过一部分介绍和答疑，才会形成自己的反应能力。

当然，跟着去不是让你去充人头显得我们阵容很隆重的，哪些问题自己答不上来，老员工为什么这样问，最好回来再复盘一下。

不然出差了很多次，只熟悉了去客户公司的路。

04 能决定的现场决定，不确定的再评估

售前现场最怕两种产品经理。

一种是客户问什么都可以，先答应再说。

另一种是客户问什么都不知道，要回去评估。

前一种给后面挖坑，后一种让客户觉得，你对自己的产品到底熟不熟？

能判断、能决定的，就应该现场判断掉。

现有产品明确支持的，直接回答，能演示就演示。

通过配置能够实现的，说明配置方式和限制。

现有功能不能完全满足，但有替代方案的，可以当场跟客户讨论是否接受。

不要为了显得谨慎，就说每个问题都要带回去讨论一下。一个售前交流结束，客户一个确定性结论都没得到，只收到一长串待确认事项，那确实会让人怀疑，这公司到底靠不靠谱。

但是注意，一定要把可行、工作量、价格和上线时间这些概念澄清清楚，这都不是一回事儿。

比如一个功能从业务和产品层面判断可以做，不代表你已经能够承诺两周完成，更不代表它包含在原来的报价里。

涉及新增开发、外部系统、特殊部署环境，或者超出自己权限的价格和时间承诺，就要回去组织评估。

这时也应该说具体一点。

当前判断能做到哪一步，还需要确认什么，谁来确认，预计什么时候回复。能确定的先确定，不能确定的留下来。

还有，尽量不要把需要开发的能力，讲成现在就有了。

客户看到支付列表里有一个已支付状态，可能以为系统已经能自动完成银行付款。但现有功能也许只是登记付款结果，实际转账还在线下。

这几个字在页面上差别不大，做起来工作量还是很大的。

产品经理对自己产品的了解，至少要具体到这个程度。

有时候为了卖产品，适当的吹嘘大家都默认，回去稍微补补能赶上就行；但如果涉及到动辄一两个月开发量的，你说有了，回去要补，那这部分成本谁承担？

少给自己挖点坑。

05 方案和演示，要能帮助客户继续往下推进

沟通之后，通常需要补方案、再次安排演示，有些还要做试用或者POC验证。

方案最容易写成什么样？

复制之前的材料，改客户名称，加几页行业背景，再把功能清单放进去。

看起来挺完整，放到另一家客户那里好像也能用。

但实际上，一份有用的方案，应该让客户知道：现在的问题准备怎么解决，第一期具体做哪些内容，哪些沿用现有产品，哪些需要调整，需要他们提供什么，大致怎么推进，做完之后能达成什么效果。

背景要写，但不是重点，点到即止即可，别把大部分篇幅都花在证明数字化很重要上。

对接人可能还要拿着方案回去汇报。为什么推荐这个范围，为什么建议分期，为什么有些功能暂时不做，这些才要在材料里讲清楚。

不然你在现场说了很多，对方回去只记得功能挺全，价格待定。

演示则要提前准备。

要开环境的提前开环境，账号能不能登录，对应角色有没有权限，列表里有没有数据，主要流程能不能走通，外部服务当前是否可用，都要自己试一遍。

涉及审批，就确认审批账号能登录；涉及报表，就准备有意义的数据。别演示的时候，所有页面都是暂无数据，然后靠嘴给客户想象。

截图和录屏可以作为备用，但要说清楚。原型、演示环境和正式产品的区别，也不能含糊。

如果要安排试用或者POC，先确认这次重点验证什么、谁来操作、需要什么数据，以及怎样判断是否满足要求。

不然试用很容易变成免费的定制开发。原来的功能还没验证完，下一版需求已经收了一大堆。

06 报价和工期，不能只算功能开发

我之前提过一个场景。比如，领导甩来一张表，问这种产品能不能做，要求马上答复。我看完之后的判断是，能做，但成本可能上百万，还得看客户能不能承担。

很多时候，第一轮可行性判断就是这么现实。能开发出来，不代表这个项目就一定能成。

到了正式评估阶段，就要把范围拆清楚，再找研发、测试、实施等相关人员评估。公司没有那么细的分工，就跟项目经理或者技术经理一起把这些事情逐项过一遍。

除了功能开发，还有部署、接口、历史数据整理迁移、第三方服务、培训、驻场和后续维护。当然，还有需求对接和需求方案撰写，别把自己本职的工作忘了，你自己也是算成本的，包括你因为这个项目一次次的出差。

同样说接一个接口，有完整文档、测试环境和标准接口，跟连接口能不能开放都不知道，这不是一个工作量。

同样说迁历史数据，客户给一份规范的表格，跟给一堆格式不同、内容还打架的文件，也不是一回事。

这些都要进入评估。

客户觉得贵，要能够说清楚成本都在哪里。可以讨论分期、缩小范围、减少定制，或者先用现有能力满足最主要的需求。

别价格降了，时间缩了，功能和服务却一样没少，最后做成赔本买卖。

至于公司愿不愿意为了某个重要客户承担更多投入，那是另一项经营判断。产品经理需要把成本、条件和后续影响说清楚，再由有权限的人决定。

07 会开完了，不代表事情结束了

客户在会上说产品不错，不代表这个事情就稳了，你就可以高枕无忧等签约了。

沟通结束后，要把已经确定的内容、还要核实的问题、需要双方提供的材料，以及下一步安排整理出来。

客户等我们补方案，还是我们等客户给现有流程？下一次需要业务人员参加，还是先安排测试账号？哪些问题由谁确认，什么时候回复？

这些都要有明确的安排。

特别是现场说了回去评估的事情，要记得真的评估、真的回复。

不能客户不问，你就默认忘了。下一次见面，对方把同一个问题再问一遍，多少有点尴尬。或者人家得不到反馈，觉得你不积极，直接给pass掉了。

项目进入交付以后，前期材料也要跟着交过去。

客户关注什么，演示过哪些功能，哪些已经承诺，哪些还在讨论，哪些依赖外部条件，都要让后面接手的人知道。

如果售前和后续产品都是自己，那就更要记录。

同时跟着几个项目，隔了两个月，谁也不能保证还记得某次会议上到底答应过什么。

售前做得好，需要对业务和产品足够熟悉，也需要在现场不断听、不断判断、不断积累。

刚开始接不住问题很正常，可以先跟着听，接着讲自己熟悉的部分，再慢慢承担完整的交流。每次回来，把当时没回答好的问题弄明白，下次再遇到，心里就会多一点底。

毕竟，产品经理前面介绍出去的东西，后面大概率还要自己写需求、跟上线、去培训。

现场少想一步，可能过两个月，就得自己多跑一趟。

前面多做一点，后面自己就少点麻烦，横竖都是自己的活儿，能稳则稳吧。