最近销售谈了好几个项目都让我很是郁闷，明显感觉到C端的销售和B端的销售有着明显的差别。在B端，大家都是综合来看整个项目，了解项目的规模，项目的预期，项目的关键角色，根据项目的大小提供产品的弹性，以便于能够实现双方的共赢。在C端，就是谈产品单价，至于你卖给谁，卖了多少钱，我不管，但是不能乱我的价格。

举个最简答的例子，如果是B端的一个销售：

我们的产品软硬件的成本在20W左右，一个100W的企业巡检项目，B端销售首先会了解甲方巡检的目的，项目的预算100W的分配和构成，主体是甲方发起巡检项目，集成商作为乙方承接实施安装，我们作为丙方提供产品。然后开展谈判和溢价，最终的结果我们50万给集成商，集成商100W给客户报价，并返点30W。在这个过程中，不断的试探和谈判，最终期望到一个共赢的状态。

如果是C端的销售，那么结果是：

集成商找上来们来告诉有个项目需要软硬件，需要报个价格。C端销售按照60%毛利报50W，最后被集成商压到30W，最后谈到35W。C端的逻辑是我出货给你，这事就算是完了，你卖给谁，我不关心，我只赚我赚的钱。

C端的做法，还是百货走量的思维，量大管饱有优势。但是要详细经营一个B端项目，这个玩法我觉得是不对的。正好分享一些我在B端项目的经验，请记住：
==B端的项目核心是在于人，而不是在于产品==。

1. 梳理关系，找到关键的人

B端是一个复杂的项目，他的复杂性主要体现在系统的复杂和组织的复杂。一个大的项目涉及到的部门有很多，一方面就会导致大家的诉求很多，有可能其组织内部也有一定的利益冲突；另一方面也会导致整体的决策链条很长，从商务、法务、产品、项目都有一定的决策权。但是B端其实也相对比较简单，一般一个项目的发起肯定有一个关键人物的推动。因此首次开会，除了了解项目的需求和背景，一定要弄明白各方的人物关系，了解谁是项目的主导者，辅助者，对以后会有很大的帮助。
举个地产业务项目的例子：

某个地产物业项目，共计全国有800多个地产小区，需要安装我们的产品进行视频巡检，检测其保安、客服、厨师是否符合公司规范操作。这个项目有2个关键人物，一个人物是项目的主导者，副总，也是这个项目的发起者。他的作用是可以整合内部资源，在IT、运维、行政之间协调，完成整体项目的推动。另外一个是项目对接的项目经理，他需要对项目进行选型，提供给内部使用。
所以这个项目关键人物有2个，一个是项目经理，和他打好关系；多沟通，多走动，包括但不限于送礼等不可描述的事情，要把项目经理和自己拉到一条船上来，一起想办法来共同应对项目的危机和项目的需求。起搞明白副总想要什么。满足了副总的核心诉求，说的不好听的，就算产品再烂，实际使用者使用有再多麻烦，这个项目也依旧可以拿得下。

再举一个例子我们拿下400W的一个金融项目的例子，看如何在拖了6个月交付的情况下成功拿下项目：

项目时间在2021年，因为疫情的原因，公司整个B端业务几十号人被裁，当时该团队一个价值50W左右的一个汽车金融项目移交到我的团队（后来确认大概每年400W左右）；这个项目内部问题重重，原有的B端项目代码已经无人维护，我的团队和原有B端项目系统不互通，需要把原有项目的功能都迁移到新的项目里；而公司内部对B端有阻力，团队只有四五个人，研发资源严重不足。外部问题也不少，我们的系统需要依赖于硬件设备，因为疫情和美国制裁，我们的设备一直处于无货状态（最后差不多从3月份到9月份整整9个月一直都是无货状态）；如果要搞定这个项目，既要进行系统迁移和重新开发，同步要等设备到货，如何搞定客户预期，是当时最急迫的问题。
首先进行项目梳理。这个项目有2个关键人物，第一个人物是项目的拍板人马总，他主导整个项目，需要满足主导人的核心诉求。第二个人是对应的项目经理林总，他有建议权。
绑定项目经理的核心利益，追加他的沉默成本。由于项目前期已经投入了几十万的资金，做了几百家的试点，一方面需要多加强联系，在权限范围内给予对方一定的方便；另外也沟通看是否有其他供应商的介入，多增加对已有方案材料的内部汇报，加强在他们公司内部我司方案的影响力，让他感觉到如果换一家供应商，前期的投入会打水漂，自己的上升渠道也会受阻，我们和他是一条船上的人，一起把这个事情做好（事实是在过程中微软确实也介入提供了方案，并且提出了可以无缝替代的方案，其中的斗智斗勇再另说）。
不断更新看的见的进度，隐藏看不见的进度。由于疫情和芯片缺货，我们的硬件迟迟没货，原有的几十家试点其实满足不了客户的发展诉求。不过讲事实，摆道理，疫情和芯片的问题是实实在在的，一方面对于疫情和芯片问题要放大，降低客户的预期；一方面做好功能开发排期，同步对系统迁移，对于客户的核心功能进行拆解，每两周能看到有进展，能让用户看到我们实际有在动作，在积极配合。
满足关键人的核心诉求。什么意思呢，其实一开始我是按照功能实现不断迭代更新软件功能的，但是因为没有硬件，好多功能其实没有办法完成，导致项目其实实质进展已经有3个月没有进展了。在多次沟通以后，其实发现当前最紧急的事情是马总要向美国汇报信息化建设的诉求。内部的进度都好把控，但是向上汇报是企业的特点，满足关键领导向上汇报的需求是重中之重。
在了解到事情的核心以后，我赶紧和甲方林总一起整理他们内部向上的材料，专门买了3台服务器，分别在河北、云南、广西三个地方用服务器模拟我们的设备运行。功能上因为用了服务器，能力大大增强，为了满足汇报，做了很多花里胡哨的AI功能，最终又因为汇报出色和呈现良好又拖了3个月，到了9月份才开始按照计划进行交付，拿下了整体项目。
（最终因为当时使用服务器来模拟的功能，导致实际使用我们的设备的时候，当时演示的功能没法实现，最终妥协了很多的不完美的方案，这个又是技术的另外一个话题了）。

整体说来，在项目中梳理关键的人，找到能决策的人，满足决策人的需求;找到推动的人，把他拉到一条船上来，是重中之重。事实证明，在B端的项目中，就算是前期的产品功能再烂，只要决策人认可，这些都不是问题。

2. 了解预算，共赢才是核心

很多时候，C端销售拿到某个项目的时候，总是很兴奋的说整体的项目有多大多大，今年能赚多少多少钱，如何判断当前是否能拿钱呢？
B端和C端有个最大的不同，是B端的大项目花钱，是需要有预算的。今年要花的钱都是去年规划好的。很少有超过50W的项目是说有钱就立马有钱开干的。而且预算一般是年底进行申请，弄明白整体预算的逻辑，很多流程其实就解释得通了，也知道为啥B端项目周期一般都是按照年计算了。
在拿到一个项目的时候，第一要看时间，第二一定要问清楚，整体的预算大概有多少。一般项目都是年初或者年中开始试点，等到年底确认开始申请预算第二年开工，所以如果遇到年底开启的项目，要不就是去年已经申请过预算的，要警惕自己是陪跑，要不要催甲方申请预算，避免到了第三年才能启动。

2.1 关键节点打通，警惕被陪跑

讲一个曾经被陪跑的例子：

在河北有个钢铁厂的项目，大概80多万，在2月份的时候C端销售把我拉进去，了解到想做AI安全识别，识别工厂里工人的危险操作。这里的甲方是河北某工厂，中国电信作为乙方进行集成，我们作为丙方提供方案，而对手乙方是中国联通，丙方是阿里。当时已经2月份了，该申请的预算已经申请了。我为此特地去了几趟河北和乙方多次沟通，再三确认预算的情况和甲方情况，了解到阿里已经在去年11月份开始测试，甲方觉得价格太高，想试试平替。
当时我就给预警可能是一个陪跑项目，甲方希望把我们的报价被拿出去作为压价的筹码。乙方说他们河北电信副总裁亲自出马要跟联通掰掰手腕，绝无陪跑可能。随后就开始长达3个月的试点测试。在试点测试过程中，产品功能都满足需求，剩下就是不断的压价，不断调整报价，在报价过程中我还一直问乙方甲方关键是谁，能否提供有效的信息，对手的报价和项目进度是咋样了。好家伙，一直告诉我还在测试，突然有一天着急让我配合写项目书，才知道对方项目书已经递交了2周了，但是没有人通知他。最终在不断的比价、填写材料中，我们沦为了比价的工具，陪跑而不自知，在6月份通知联通中标。

上面的例子就是一个经典的陪跑例子，发生这种事情其实很早就有端倪，项目介入时间是否正确，关键人物的连接通道是否顺畅其实就能出部分问题。

2.2 利益清晰，合作共赢

另外还要弄明白的是，项目中的主体究竟有哪些，大家的利益如何分配，一起实现最大化共赢。
这块和C端就是最大的不同，C端只要关心我和集成商的关系，整体预算是多少？集成商和甲方的关系是什么样的，我不关心，我只赚我毛利以内的钱。这个是最让人头疼的事情，如果是按照C端的逻辑，可能一个400W的项目，能够按照100W成本，200W的出货直接给到甲方，白白少赚了200W。
要明确项目中的主体有哪些？有些是直接面向甲方的，那么就是乙方和甲方之间的关系，多少的预算，产品毛利，甲方关键人员是否需要回扣，都是整体化的考虑。如果是通过集成商的关系，那么是甲方、乙方、丙方的关系，作为丙方，需要看谁来作为主体。比如甲方是看中的丙方的品牌优势，只是乙方作为集成，那么可以对于甲方关键人员、乙方、和丙方按照营收的30%，20%，50%(50%包含乙方的成本，实际利率可能在20%)划分。如果是乙方作为主要投标人，承保给乙方，那么很有可能丙方只有40%的毛利（20%的成本和20%的利润）。在整体的项目中，有些内容有可能参与不了，但是一定内心要清楚项目主体之间的利益分配关系，这样在整体报价的时候做到弹性。
这部分有很多利益关系，个中关联就不展开说了。

3. 学会报价，谈判技巧很重要

在整个项目中，报价和谈判技巧是非常重要的。项目的报价一般是和项目预算一起的。B端项目报价的逻辑，不是像C端报价一样是成本报价，因为产品销售价格非常弹性，整体应该在满足产品毛利的情况下，根据项目预算和竞品价格来整体报价，而非进行成本定价。

这里举一个例子。甲方这边使用万店掌的方案，一年费用大概在80W左右，而整体我们做的成本大概在10W左右。C端的逻辑是按照成本定价，直接报价30W，66%的毛利，底价40%毛利；而B端的逻辑是甲方目前费用是80W左右，其实50W-60W已经是符合客户的预期，40W就是我们的底价，其中10W-20W可以作为活动经费；
看出来思维部分思维的差异么？C端销售不关注甲方的预算；习惯了C端产品的走量模式，不清楚，拿不到是经常的说辞，最后一个本来我预估可以50W的项目，直接到了20W。

这里其实还有一种情况，很多时候项目预算其实是不清晰，项目本身也是要根据项目规模来反推项目预算；那么恭喜你，你进入了首批试点名单。陪甲方跑风险很大，但是收益也很高，这里的学问很多，找到关键的人物，一般不管是企业和政府，对于某个项目可能没有具体的规模预算，但是会有一个模糊的预算。了解整体的项目预期。

3.1 首次报价不要怕报高

上面有隐晦点出，B端项目的报价逻辑其实是围绕甲方预算、竞品方案、己方成本来进行报价。C端的销售面向的终端客户有个特点，一般都是喜欢有性价比的产品；围绕着成本和毛利报价，不敢报太高是很多C端销售在B端项目中表现出的问题。
其实在B端项目中，首次报价不要害怕报的太高吓跑客户。在了解甲方预算和竞品类似方案的情况下，首次报价可以比甲方预算高些一些，如果不知道甲方预算，那可以比竞品方案价格略微高一些。这样在后续的谈判中可以有更多的筹码。B端的项目的核心是可以谈，可以走动。多走动，多沟通，在走动和沟通中动态的调整。
请牢记，B端的核心是在于人，而不是在于产品。

3.2 谈判的目的是相互的妥协

首先要明确的是商业谈判的目的是为了相互利益的妥协，能够得到一个相互相对满意的结果（也叫做共赢）。如果一个谈判本身就奔着不可能去谈的，那么谈判本身就没有什么意义，也就没有谈判的必要了。
整个谈判本身其实就像是打牌，核心其实是要透过你的关系网，了解甲方的底牌是什么？然后自己手里握着有哪些底牌。这就是为了一开始不要报价太实在的原因，太过早的暴露自己的底牌，是一件非常不明智的事情。
还是以河北被陪跑的80W项目为例，虽然最后失败了，但是其中很多策略是值得参考的，这里最主要的是没有关键人，白白陪跑。

河北工厂这个项目当时能够拿到的信息是项目整体预算在80W左右，我们的成本是在20W左右，但是我们至少需要20W的利润，乙方差不多需要10-20W的利润，所以50W左右是最终的底牌。我们经过了多轮报价，依次打出的牌如下：
第一轮：整体报价90W，甲方不太满意，要求降价。
第二轮：调整为两种方式，买断制和订阅制，买断制大概85W左右，订阅制首年50W，每年10W左右，经过1个月的拉扯，甲方还是决定买断制，但是嫌弃价格比较高，并开始打出第一张牌，比对手公司的价格高，并着重提出了安装实施部分我们的太高。
第三轮：重新把硬件部分做了优化，尽量使用已有线路，报价70W左右，核心提出我司对于产品安全、网络安全的专业，核心产品功能准确率可以根据用户持续优化的优势，领导部分满意，经过2周后重新打出第二张牌，软件部分功能比对手公司高。
第四轮：实际猜测对手公司的方案成本应该不会比我们便宜，但是没有关键人物的提点，我们核心压缩了利润，报价到了60W，客户不满意，要求持续优化。
第五轮：如果这个时候持续压缩利润，这个时候其实已经很被动了，所以我提出60W基础上，我们除了甲方感兴趣的违规区域闯入提醒，还可以赠送甲方感兴趣的安全帽佩戴提醒、口罩提醒等一系列AI功能。因为买断制本身是在本地有服务器的，所以这些AI的功能其实是没有成本的，无非是授权的问题。对此，甲方开始试用安全帽佩戴、口罩提醒、违规操作提醒等功能。
第六轮：甲方还是要求降价，这个时候我再打出的牌是增长设备维保期，可以免费维保已有的监控设备。我们正常的摄像机和服务器都是一年质保，一年内设备损坏我们是包安装的，一年以后就需要花钱维修。我们的服务器都依赖于监控摄像机来进行数据采集的，第一轮报价的时候我们要求是换上我们自己的设备，第二轮报价以后我们除了关键节点，其实用的是工厂原有的200多个监控设备。当时算了一笔账，这200多个监控设备相对比较稳定，就算是损坏换修+人力也就几千块撑死了。
第七轮：多轮沟通后，甲方还是要求降价，我的诉求是我的产品要保证毛利，这个时候乙方也就是集成商决定降低自己的毛利，一定要跟联通掰掰手腕，在保证13%税的情况下，出价50W，甚至可以更低。
最终成功完成陪跑使命，压价对手公司，在6月份的时候通知我们没有中标。

这个项目是失败的，不过确实在多轮报价中不断打出手里的牌，这个参考借鉴一下。在出牌的过程中，涉及到敏感价格线后，要保持价格线，在不减价格的情况下，不断打出可以增加附加价值的牌。以上项目都是正规项目，不涉及违规操作。

4. 深度挖掘，了解用户核心诉求

B端的项目在大多数的时候，甲方和你沟通的时候，是带着方案来的而不是带着需求来的，这个时候不要被甲方的方案所迷惑，需要挖掘甲方的核心诉求是什么。
举个我面试的时候，一个产品小萌新分享一个他引以为傲的反面案例：

小萌新的团队给政府做了一个数据大屏的项目，就是在政府的IT大厅里有个电视墙，上面显示整个城市的3D建模图，领导可以在上面随时把控整个城市的运行状况。在交付的第二天正好下雨，领导提出需求：希望下雨的时候，在数据大屏上显示水波汹涌的翻滚效果，并实时展示各区域的水位。因为各区域的水位其实是有传感器的，所以在画面中增加水位显示是已有设计。但是要增加水波汹涌的效果，重新再开发组件需要3-4天左右，没法完成第二天交付的需求，所以他拉通各方研发人员，灵机一动可以通过一个浮层放在整个数据大屏上，验证这个方案1天左右就上线，最后按照这个方案进行了上线。
这里我说是个反例并不是说最后的实现方案不好，而是应该深度挖掘领导的核心诉求，为什么要波涛汹涌的效果？也许可以会引出其他需求，也许也不用实现这个需求都有可能。

在实际的项目过程中，我们遇到很多很多类似的甲方需求，都是直接提出方案，问可不可以完成；首先要时刻提醒自己，你自己才是最懂自己的产品的人，你是知道自己产品边界的人；甲方的需求提了就提了，不要理，要深度挖掘甲方究竟通过这个方案想要干什么，并且有时候在一层需求里，还有更深层次的需求。
举个接手的一个全国连锁巡检的例子：

上面有提到，2021年组织架构调整整个B端项目被裁，当时还接手了另外一个全国连锁店铺的项目，通过摄像机来进行店铺巡检。因为受疫情影响，甲方预算吃紧，整个项目一直在停摆；另一方面由于在忙汽车金融项目，一直也支持浅浅支持。直到有一天，甲方提出，前团队答应在页面中可以有数据报表下载的功能，按每个摄像机在每个时间点是否有事件上报，大概类似：
| 摄像机 | 00:00 | 01:00 | 02:00 | …… | 23:00 |
| 设备A | 1 | 0 | 1 | …… | 1 |
| 设备B | 2 | 0 | 9 | …… | 1 |
由于当时我们的设备没有对事件做合并统计，这个功能其实是有一定的开发量的，而且除了这个项目，其他项目目前看也不会用到，不具备通用性，所以和甲方进行了深度沟通，了解其核心目的：
乙方：您好，这个报表非常合理，也相对比较简单（先要肯定甲方的需求，表示功能可以完成）,但是这个报表看起来就是一份普通的统计，您希望通过这份报表解决什么问题呢？
甲方：我知道你们目前项目开发资源比较紧张，不过摄像机的数据都是现成的，你们合并统计一下就行。我们每天巡检的时候发现有很多店铺为了逃避远程巡检，把设备对着墙壁，如果对着墙壁一般就没有任何事件的上报；或者对着马路，那么呈现的就是每天事件比较多；如果早上没有事件上报，那肯定是有异常的。（这是一个非常典型的甲方方案型需求，在部分了解我们产品的基础上，结合自身业务，直接提出方案，并且还“贴心”考虑了我们研发资源的困境）
乙方：了解，看的出来龚总您对数据是非常的敏感，这些细微的差异您都能快速捕捉到。刚刚听到您提到，希望通过这些数据来筛查异常的店铺；其实我们有很多异常检测的算法，可以检测是否遮挡、是否白墙；有没有正常上班我们也可以在每天10点左右对画面进行人形的检测，看是否有人在；这方面可以给您演示一下。（肯定甲方的数据敏感性，抓住甲方的核心诉求，数据报表只是第一层需求，甲方的诉求其实是：异常行为识别。要时刻牢记自己才是对产品理解最深的人，了解客户的需求，提供己方和甲方最有利的方案）
甲方：那太好了，我们可以试试。不过目前因为疫情原因我们预算有限，这些功能工作量怎么算(担心价格问题)？
乙方：龚总您哪里的话，我们和贵司合作了这么久，费用这块都好说；我们可以拿几个店铺当试点先试用，同步报价；对了，刚刚听您大概介绍了一下需要巡店，您这块目前的巡店方式是什么样子的呢？（先不要谈死价格，先试用，把甲方参与进来；价格不是明面上的谈判，都是私下的交易出了解当前甲方的业务方式）
甲方：目前我们的模式是这样的，以前是神秘人冒充顾客全国巡检，后来发现人力成本太高了；后来就改成了线上巡检，我们的巡检小组会每天对所有摄像机都人工点开看视频，并且截图保存；但是这个工作量也比较高，所以想通过数据分析先筛查一部分店铺，减少人力成本（甲方的需求是想通过数据报表对目前工作量减少，跟进一步挖掘核心，其实是企业降本的需求）
乙方：了解了。看的出来龚总是企业信息化领域的专家，贵司在企业信息化建设中也是走在了前列。对于店铺的巡检，其实我们有合作的方案商，可以提供自动化巡检、异常问题分发、问题待办处理等核心功能，我司可以提供AI的异常行为检测，店铺人形检测这些功能。（了解甲方降本的需求以后，可以直接推翻现有的巡检模式，拉入合作伙伴，使用新的巡检方式，我司开发的功能标准化，降低我司开发难度）。而且龚总您看，我司除了巡检以外，还有资产统计、客流统计等功能，也可以给您演示一下（了解客户的企业降本需求以后，也可以推公司兄弟部门的资产统计方案和其他可以增效的方案）
甲方：可以的，我们可以先试试新的巡检方案，同步试点看看你们新功能。

通过沟通可以看到，客户的需求在一直被挖掘，从：数据报表->异常行为识别->降低人工操作成本->当前人工巡检的痛点->本质是企业降本的需求。在了解到客户的核心诉求以后，我们提供了智能巡检的新方案，并且还推荐了其他人工降本和增效的新功能。
其实B端和C端总结下来，B端的商业属性清晰，核心诉求其实就是降本增效。我花100块钱，能够帮我省1000块钱，我就买；我花100块钱，可以帮我赚到1000块钱，我也买；反而C端因为群体的多样性，核心诉求反而不好归一。

5. 时刻警惕，关注项目风险

B端的项目说来复杂，其实也很简单，主要还是人的关系。搞定关键人物，其实就大差不多。但是成也萧何败萧何，其中的风险其实也是人的关系。
首先要时刻警惕就是关键人物的变化。前面也提过，甲方一般有至少2个关键人物，一个是对接人，一个是发起人，任何一个人发生变动都有可能对项目产生蝴蝶效应；对接的人变动，有可能引入新方案商形成竞争关系，而发起人的变动，直接有可能导致项目作废。
还是举个上面说的地产项目的例子，说一说发起人变动引起的影响：

还是前面第一点说的地产物业关键人物案例，当时发起人是副总，他可以内部推动运维、IT、行政等多个部门进行协调，完成整个项目的交付；在第三年以后，由于内部组织变动关系，甲方的副总离职，该项目由原来的业务部门负责，改为了统一交由甲方信息化部门负责，由于前期投入了大量沉默成本，项目还是继续维持，但是我和甲方的项目经理沟通，项目经理表示他们业务部门的这部分预算是公司信息化部门来申请和审批，我需要找信息化部门的领导。然后我找信息化部门的领导多次沟通，也无法有进一步扩展，核心在于信息化部门和其业务部门本身就是2个不同部门，业务部门的预算在信息化部门肯定是在缩减的，以维持信息化部门的投入，至此，该项目就由原来的可能有进一步合作关系变成了缩减关系，所幸前期有大量投入成本，因此项目年年都在进行缩减。
B端项目在组织上的复杂性就体现出来了，如果预算和项目是一个部门，还有可能公关一下，这种分离项目，很难完成公关。

在举个对接人引起的影响：

在3.1节其实举过一个报价的例子，其实就是很典型的对接人更换的案例。企业要进行店铺巡检，是企业内部信息化的需求，以前使用的是万店掌进行巡检，成本在80W左右，而对接人更换以后，新的对接人新官上任，开始对现有方案进行改革，第一步就是降本，调研以后预期可以降到50W以内，这就是很实在的对接人更换的例子。

在组织内部，对接人和发起人的离职、升迁、轮岗都会对项目造成巨大的影响，因此在对接的时候，要实时关注甲方组织内部的变动关系，提前完成对接。
其他风险还有回款难、回礼等诸多问题，就不一一展开说明。