1、
最近遇到一个to B业务谈崩的故事。
一家to B的互联网SaaS服务供应商（简称“阿Sa”），阿Sa想向一家同是做to B业务的金服公司（简称“阿B”）卖一套互联网营销客服平台，而阿Sa过去正好成功服务过一家to C的金服公司（简称“阿C”），阿B、阿C算是同业，只是服务客群不一样。
阿B是靠线下经纪人模式起家的，后来转型做批量平台业务，目前计划转型到互联网营销模式，并希望提升智能客服能力，所以，互联网营销系统和智能客服系统都是他家的需求。
阿B很想知道阿Sa到底给阿C提供过哪些服务，以及阿C是怎么用的，业绩提升多少。
怎么谈崩了呢？
阿Sa全程简单一笔带过了阿C案例的信息，只表达出“我有这个那个功能，你们想怎么用就怎么用”，就崩了。
问题是因为没有提到阿C的案例么？
是，又不全是。
2、
梁宁在《产品思维30讲》里提到过两套客户画像的模型，其中一套正好可以解释一下“到底为什么谈崩了”。
这个客户画像模型是——大明、笨笨和小闲。
大明，非常清楚自己需要什么，只需要找到那个东西，比价格就好。
笨笨，有个大概需求，但又不太明确，想要多看多对比多了解再做决定。
小闲，没有消费需求，纯属打发时间。
阿B就是笨笨。
一家企业的发展与它的出生基因有着非常紧密的联系，阿B做线下业务起家、发展10年，又是一家to B的公司，所以，互联网的玩法在这里并没有优势，反而是一项需要建设的能力。
阿Sa做得不够的是，想当然地以为客户理所应该懂互联网的玩法，理所应该有基础IT设施，业务规模理所应该上了多少量级，可能事实不是那样的。
这一次，阿Sa的客户调研做得非常不足，阿Sa不知道阿B真的不知道怎么用。
3、
阿Sa或许还忽略掉一个很关键的问题。
阿Sa知道阿B家来参会的有多个部门的代表，IT的、业务的、客服的，相信也非常清楚每个部门有不同的需求，屁股决定脑袋，各有各的小99，但还是忽略了某些细节。
每个部门需求不同，但是不是必须要满足每个部门的需求？是不是必须要满足某个部门的所有需求？谁是决策者？
刘润的《为什么我们常说做to C 的人比较难去做to B？》中提到，to B 的难点是企业购买决策不是由一个人决定，而是由流程决定。这是B端决策的长度问题，而在这个谈崩的案例中，还反映出了B端决策的宽度问题。
容易理解的是，业务部门提出要做互联网营销，客服部门提出要做智能化服务，IT部门需要同时满足他们的系统需求，部门与部门之间有交叉诉求和割裂诉求，对公司整体而言，如果一个产品能同时满足多个部门的需要，当然只想付一次钱喂饱。
问题就出在阿Sa不知道自己的产品是否满足客户需求？不知道客户自己也说不清楚自己的需求是什么? 不清楚需求优先级？不知道谁是决策者？
从阿B家的角度来看，自己关上门，各部门间好好商谈，能凑一起买就凑一起买，实在不行，各买各的。
从阿Sa家的角度来看，还需要深入沟通、了解客户的真实情况，能凑一起卖就凑一起卖，实在不行就拆开卖，谁喜欢自己的产品谁就是决策者。
4、
总有一天，我们也会作为乙方去跟客户谈判，或者就像写作一样，需要理解读者需求再去创造作品，这个谈崩的故事很有借鉴意义。
读过梁宁《产品思维30讲》的朋友会有更深的体会，她的课程结构设计，不是一开始就讲“产品怎么设计”，而是花了很多章节和篇幅去讲情绪、人性，再引申到机会、痛点和需求上去。
对商务谈判、作品创作、人际沟通等都是同理，理解对方的情绪、痛点、需求，是商业的第一步。
我们面对的是谁？他们的境遇如何？在想什么？担心什么？利益是什么？损失是什么？他们与周遭之间的利弊关系是什么？
或许，我们在企业里工作，需要面对B端或C端的客户。或许，我们在创业，也需要面对B端或C端的客户。多费心思了解一下客户，分析一下客户的语言与反馈，对客户真实需求会有更多理解。
多理解一点“人”，为了不谈崩。
- End -
