销售实战：客户角色分析
2020-07-09 11:58:47
Chapter1.小伙伴的分享
上周，一个销售的小伙伴跟我说了他的一段经历。
他之前跟进一个客户管理系统（CRM）的项目，客户的销售总监非常支持，深入组织了几轮需求沟通，销售部门上上下下都觉得小伙伴所在的公司很棒、很专业，也很认可他本人。
小伙伴觉得这次十拿九稳了。
然而，就如这一刻大家心里的猜测的一样，故事的后半段出现了转折。
果不其然，客户IT部门借着与ERP系统整合的技术考虑，以及出于对系统安全性的担忧，有些不太认可小伙伴公司提供的解决方案，而倾向另外一家国外企业。
最终，这张单输了。
这样的故事在软件行业天天都在上演。
复盘起来，原因不外乎：
-- 只搞定一个角色不够，要多搞定几个。
-- 企业文化不一样，要看企业哪个部门更加强势，要充分做该部门的工作。
-- 有时候即便下面都达成一致，也可能被领导一棍子打死。
-- 即便搞定了决策层，也不意味着项目没有风险，毕竟领导的态度也不能太有偏向性，意外随时可能发生。
......
这些原因都对，而作为销售人员，要怎么避免呢？
有没有结构化的方法论可以供我们参考？
Chapter2.四种角色
综合了国内外销前辈的著作，诸如Keith M.Eades、Mack Hanan、Neil Rackham、孙路弘、夏凯等。
销售科学流总结了“客户4角色模型”：
我们简单介绍下：
UR：用户／业务角色
就是使用者，或者叫业务角色，例如在IT行业，CRM系统的用户是销售部门，HR系统的用户是HR部门。
一般而言，用户部门也是项目的发起方，他们在工作过程中遇到问题，需要通过外部提供解决方案予以帮助。
除非是介乎于用户角色和决策角色之间的用户部门领导，否则跟他们讲宏观和抽象的概念一般没啥意义。
用户主要关注系统的功能、体验，与用户的交流，一般更聚焦在需求和细节上。
TR：技术角色
技术角色，在软件项目的选型上会起到重要作用。
由于业务角色一般不懂技术，他们只能从需求出发，告诉IT公司想要什么，但是
-- 需要用什么系统来实现？
-- 系统能做什么？
-- 系统做不到什么？
-- 系统最终会长什么样？
-- 技术本身存在什么限制？
业务角色对以上问题，一般没有太具体的概念。
所以基于信息化系统的专业性特点，很多时候技术部门的话语权比用户部门更大。
所以一般情况下，即便搞定了决策层，技术部门仍然很容易左右项目选型的方向。
毕竟领导在技术方面不是专业的，如果他强行指定，一旦项目失败了，领导就很尴尬。
所以说，系统越复杂，技术部门的影响力越大。
DR：决策角色
决策角色，是本文最重要的一个议题。
决策角色是谁，取决于企业规模、决策文化、软件系统的重要程度和复杂度等因素。
如果企业规模小，决策角色一般是老板。
如果企业规模大，但系统金额不大，而且企业权力有一定程度下放，那可能业务部门领导就可以直接拍板；如果有技术部门，那他们的意见也很重要。
而如果信息化系统很重要，涉及的金额比较大，即便管理上有一定的分权，最终的决策权还是会落在最高负责人那里。
另外，我想传达一个思想：
决策，不是一个人的决定，而是多个人共同影响的结果，它体现了一种制衡关系。
所以决策角色，在软件行业会分解为三个细分角色：
最终决策人：FD（Final Decision）
业务决策人：UD（User Decision）
技术决策人：TD（technique Decision）
而决策的制衡关系与比重，取决于内部权力态势、决策文化、系统复杂性等因素。
有些企业，崇尚集权、一言堂，可能决策比重关系会极端地表现为：
在现实中，销售从业者需要关注的是：
-
很多时候FD、UD、TD的人物会重叠，例如FD和TD是同一个人，或者FD和UD是同一个人，甚至在解决IT部门的需求时（例如一个小型的IT治理咨询项目），FD、UD、TD可能直接是同一个人。
-
FD、UD、TD不一定只有一个人，例如有些项目，总经理和董事长会共同决策，甚至相互制衡，那么FD就有两个，或者在TD中，新来的CIO和老臣子IT经理两个人的意见同等重要。
-
UD、UD，不一定是部门负责人，可能只是一个经理级别的，但他们获得了充分授权。
所以销售从业者，需要搞清楚人物关系，了解决策机制，才能保证努力用在正确的点上。
这么多信息，销售从业者怎样才能收集到？
IR：内线角色
我们需要内线角色，给我们引路，给我们提供信息。
内线角色也不会只是一个人，他应该是动态的。
刚开始这个内线可能只是IT部的技术同事，或者前台的小姐姐。
随着销售从业者的努力和深入，UD、TD可能也会变成我们的内线。
Chapter3.角色与阶段
根据我的经验，不同角色在销售不同阶段，重要程度会不一样：
大概的意思就是：
-- 业务角色在一开始很重要，但随着需求的越来越清晰，在决策的后期影响力会逐步递减。
-- 技术角色一般伴随着软件项目的评估整个过程（当然也有一些是后期突然加入），在方案评估的过程影响力很大。就如开篇的小案例，很多时候技术部门可以通过一些技术指标影响选型的方向，到了后期，就会把影响力移交给决策人。
-- 在项目中前期，决策角色一般会把评估权下放，到了后期，综合UR、TR的意见，再做决策。但我的经历中，常有发生中前期很乐观，UR和TR都很认可，但后期决策人被竞争对手影响到，一下子局势大反转。
所以从上面的模型和解读中，不难发现为什么销售从业者搞定了一两个角色，但后面还是输单了。
我们不能单纯看一两个角色对我们是否支持，更要把客户角色当作一个体系来对待：
从阶段看，争取不同角色的支持；
从整体看，争取全方位角色的支持。
Chapter4.工具输出
所以，最终，我们会输出一个这样的销售工具：
根据上面的介绍，相信读者应该都能看懂这个销售工具。
唯一需要解释的，是以下3点：
1、除了搞清楚人物关系，更重要是搞清楚相关的人对我们的支持度，很多时候销售从业者都过于乐观，但是一旦量化，需要用数字进行标识，可能会发现很多关键人说不上支持，最多只是中立罢了。
2、我们特别容易过分重视决策人，而轻视影响人，因此对每一个影响人，我们试图量化其影响力程度，避免不够具体而引起的判断失误。
3、（这一点是最重要的！）很可能销售从业者会发现信息缺失度很高，根本填不上多少信息，这就意味着，我们的乐观都是盲目的。同时，这个人物工具为我们指明了努力的方向，至少让我们知道要获取哪些信息，让我们对项目的判断更加准确。
Chapter5.结束语
以上，便是我们的销售科学流的角色和人物模型，并输出了相应的销售工具。
接下来的问题是，销售从业者确实已经搞清楚了人物关系，但是怎样搞定这些角色，让他们支持我们呢？
这是我们下一篇文章将要讨论的话题，敬请关注。
