在销售流程中，KA的管理是非常重要的一环，特别是在以中小企业和销售为主的公司中，更是重中之重。这篇文章，作者分享了在此类公司，如何管理产出KA的业务团队的方法，供大家参考。
这是一个基于过去的经验有感而发的，以及在现阶段接触了一些公司之后，发现有一些共性的话题，所以，想把自己的观察和思考分享出来，略长。
核心观点是：以SMB客群和销售场景为主的公司，如何高效的产出KA的业务团队并拿到结果。
所适用的行业，是为企业、机构、组织提供信息化技术、服务、产品的IT公司，包括但不限于传统IT企业、平台服务或云业务、SaaS业务等。
实上碰到的场景和问题可以抽象出一些供参考：
相信这些场景还有很多，但是抽象一下就会发现，其中最明显的冲突体现在以下几个方面：【我们不考虑市场和品牌层面的客户预期打造，他是另一个话题，在此核心是销售及组织运营场景】
导致这些冲突的底层原因，我的观察是，我们并没有深度的思考SMB和KA到底有什么样的差异，以及从底层差异入手，结合公司的资源储备情况和预期的业务目标进行设计，多数都是仓促上马、快速落地，出了问题在反复调整，既没有结果又折腾团队。
后面，我会尝试从底层、采购流程以及销售流程三个维度去尝试分析其差异性，并基于差异讨论一些可能的解决原则。
任何业务设计都存在一个底层的基本假设，就像经济学一样，缺少了稀缺性、边际成本、边际收益、需求曲线、供给曲线等基本假设，我们就缺少了去理解和抽象经济现象的方法，也就无从验证路径和行为的正确性，所以，首先我们要解读或设定一下SMB与KA业务场景的底层假设。
SMB，是英文Small and Medium-sized Business的简称，就是我们俗称的中小规模企业，这类企业经营规模不大，人员、资金有限，在营销领域对这类客群基本假设是：潜在客户数量足够大、客户生命周期较短、客户通用型需求显著、客户付费意愿差异性较大
基于这些基本假设，我们在销售场景中对于该客群常规会使用的销售原则包括：
需要用“简单”的产品满足大部分客户需求的“基本面”，在部分产品能力上建立比较优势，通过销售渠道的快速覆盖和基于“交易”的销售模型组建并持续迭代优化销售团队
KA，是英文Key Account的简称，就是我们常说的重点客户，在百科上对于KA的解释是“指在自身产品的销售中占据重要份额的少数零售客户”，翻译成人话就是这一个客户贡献的业绩占你整体业绩收入的比例很高，他就是你的KA客户。但这是一个内部视角，是不足以准确描述外部潜客画像，我们需要画出一个咱们心目中的KA客户画像：
基于这些画像描述，我们可以抽象及定义出这类客群的基本假设：
潜在客户数量少、客户生命周期长、客户个性化需求显著、客户具有较好的付费意愿
基于这样的基本假设，我们在销售场景中对于该客群常规会使用的销售原则包括：
需要基于客户需求洞察的综合解决方案，解决方案需要能够说明我们的产品或服务与客户的价值链条、业务链路、组织形态、上下游协同方的关系，并且阐述能够带给客户的价值增值，需要有明确的营销、售前、销售资源投入，需要与客户建立稳定、长期、面对面的客户关系；
这两个业务的底层是有巨大差异的，当然这其中还涉及了很多客户洞察、客户理解以及不同行业的经营模型和信息化需求之间的关系，我们不做过多赘述，只是将其中的通用性部分进行抽象并描述出来，作为理解后面两个差异性的前置信息。
B端客户的采购行为底层模型是什么呢？SMB有一些小微商家，他们的采购行为是否和C端采购行为有相似性？是否可以使用C端销售的很多策略和玩法覆盖B端客户的场景，并且影响或者改变他们的采购模型呢？
首先，我们要理解一下B端客户采购场景。
经济学告诉我们，我们愿意买任何东西的前提是我们从这个东西上获得的价值大于我们支出的成本，而成本有可能是一笔金钱，也包括了时间成本、学习成本、状态改变的成本，以及替代品的成本。
在我们作为一个C端客户的时候，我们所获得的价值大部分都是基于个人情感、心理、便利性、外部认可等产生的非经济性价值，一切以我为主，最多兼顾一下身边人的情绪，但是当我们作为一个B端客户的时候，我们经常会做的就是去算算这个采购行为能够为自己带来多少收入的增长，或者是成本的降低，你会发现，采购的核心就是算账，算一笔将对清晰和完整的经济账。
正因为会这样，B端客户采购很少会出现冲动消费，绝大多数情况下都是理性消费，以及货比三家的同时，还需要要更多的折扣、附加价值和周边资源，同时，B端客户采购不能只满足一个人的好恶，还必须兼顾公司股东、出资人、管理人、执行人等多个角色，因为他们都出了钱，他们需要对花出去的钱以及能够收回来的价值负责，同时他们也可能被采购带来的改变所影响，不管是好还是不好，他们总有权利做自己的选择。【我们说的小微企业，这些角色基本上产生了重合，就是老板或者老板娘，这就是一个最小的B端采购组织，以及KP和关键意见人】
基于此，我们基本上就能够理解SMB和KA客户采购差异，就是这些利益相关方角色是合一的还是分开的。
大部分SMB的客户，他的利益相关方角色是合一的，或者就是KP和关键意见人两个角色，这样的采购，首先流程基本上是不需要的，其次，你也不需要去兼顾多方利益，还要解决他们的冲突和问题，你只需要解决了关键KP所关心的问题，就解决了整个采购流程，唯一需要担心的，是如果你解决不了他的问题，那你也基本上和这个客户在没啥合作可能了。
而KA的客户是截然不同的。
首先，人多了就有利益，有利益就有冲突，有冲突就需要平衡，在平衡的情况下，流程正义的重要性就会凸显出来。你不但要解决人的问题，还需要解决流程的问题。
其次，在有流程的情况下，KA客户最常用的流程正义就是让所有的相关方都出现在流程中，有可能是流程的审批节点，也有可能只是流程的告知节点，也有可能他都不在流程里，但却是关键意见人。
最后，为了让自己的流程中显得有价值，你就不得不去向这些人阐述你的产品和服务，而且还不能仅仅描述你想描述的，你需要描述对方感兴趣的，或者需要知道的。
举个例子，当你向一个集团公司推荐一套财务报销系统的时候，你以为你需要的仅仅是搞定CFO么，当然不是，你需要首先搞定行政部，让他们相信你的系统可以关联机票预订、酒店预订等系统，而且可以设置不同的审批流，其次需要给各团队大佬演示我们现在提供了手机、电脑、平板三位一体的票据上传能力，而且支持前置填报预约上传，支持发起人随时撤回，发起人中途添加票据等方式，再次，还需要告知风控和内审，系统能够最大限度的前置审核并有辅助VI可以对票据进行验真，自动关联人员填报的时间和项目，最后才是告诉猜我，我们这个系统可以自动生成报表，并通过系统手动设定自动归类会计科目，生成电脑台账，进行报销人归类，降低会计核账、归集，出纳报销、付款所需要时间，提升作业效率，让他们在更需要的事情上投入精力~~~~最后，再聊聊费用~~~和大礼包。
具体的流程场景我就不赘述了，这样抽象出来的场景，应该足以让大家对两个客群的差异有足够的了解了，并因此，我们在做销售流程和业务设计的时候，就已经从先天上走了不同的修炼之路。
销售流程，是需要完全匹配客户流程去做设计和迭代的，基于上文聊到的客户流程，SMB的销售流程就变得相对清晰了：
标准化、SOP化、可复制、可量产、确保所有人照章执行，客户转化率可以稳定在15%左右；
而同时，KA的销售流程也已经显现出来：
客户视角、非标化、行业专业能力、商务谈判能力、业务咨询能力，对销售进行支撑赋能，包括培训、售前、售后、技术支持等，确保项目成功率不低于50%；
我们在实际的业务操作中，可能会发现部分SMB的销售，在行业里做了5年以上的，具备甚至比某些新入行的KA销售要更优秀，这是正常的，但是这并不意味着鸠摩智用小无相功催动的少林72绝技真的就是少林72绝技，这里面差的东西可多了。正因为这种差别，当我们判断SMB的业务体系转型KA的时候，总会出现各种不适应：
了解了底层，我们才能透过现阶段看起来似乎万事具备的表象，发现其实还存在很多漏洞的现实，因为万变不离其宗，搞清楚了基础动力学，铁坨也能飞上天啊。
建议可以采取的解决方案包括以下四个步骤：
这个环节因为太过于稀松平常，就像吃饭要拿筷子，所以经常被遗忘，启动的需求多事来自于管理层的决定或者转瞬即逝的市场机会，或者某份数据报告，但是我们到底要解决的是什么问题呢，没搞清楚这个，后面的都是缘木求鱼。
找到客户样本很重要，在之前的某次会议中，我们有聊到客户样本，销售的同学罗列了一堆客户的名称，告诉与会者这个客户的行业、营业额、管理层姓甚名谁、公司里错综复杂的关系和八卦，我觉得挺好的，就下意识问了一句：他们谁负责采购这个产品，他们内部的采购流程是啥？
一段时间的沉默后，反馈给大家的是这个公司的老板我都很熟，没问题的，肯定搞定！结果倒也没有出乎意料，没搞定~~~
我觉的这个多说无疑，客户样本的逻辑说穿了就是客户视角的采购链路，举个例子：
eg：作为一个集团公司的销售管理部，打算采购一个CRM软件，我是销售管理部负责人。
我们至少需要构建所有主营类目、行业、规模公司的采购体量、采购流程和相关影响方，因为公司很少变，而且有很大的同质性，这种事情搞一次就能顶很长时间。
这里最重要的，是不要画我们现在的销售流程，因为大部分人的作业习惯在画好了现在的流程图后，就会变成，来来来，我们改一改，这里改一改，哪里改一改，改成一个四不像最终还不如推倒重来，但是时间又不允许，怎么办，那就将就着吧~~~
所以，重要的事情说三遍：
按照客户的采购流程去规划自己的销售流程，在白纸上，以客户视角重新画！
按照客户的采购流程去规划自己的销售流程，在白纸上，以客户视角重新画！
按照客户的采购流程去规划自己的销售流程，在白纸上，以客户视角重新画！
画好以后，你自然就知道，现在的销售团队能不能承载新的销售流程和业务了。
PS：流程里面至少要包括销售动作、信息交互、系统支持、销售能力画像、协同支持团队，至于产品、解决方案和服务，嗯~~~到时可以放一放，毕竟没卖出去，想了也是白想。
这里的三个方法，是基于上文确认的整体销售链路卡点和适配性做出的决定。
好啦，还有很多的执行细节和运营场景，写出来就太多了，先起个头吧，看看后面还有没有机会可以用真实的案例来做拆解，虽说是纸上谈兵，但好歹有实战经验支撑，感觉不会太离谱~~~
本文由 @运营的不惑屋 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。