求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
 

客户和用户要区别对待

 

2011-2-25 来源:网络

 

  客户和用户根据产品的定位有时候是一致的,有时候则是分离的,这个大家都很清楚,通常来说,做企业级消费产品的客户和用户通常是分离的,做大众级消费产品的客户和用户通常是一致的,但也不是绝对,例如公务用轿车,应该是大众消费类产品,但是它多所面对的客户和用户通常是分离的,客户是各类政府公务部门,用户则是具体的操作者,也就是这些单位的工作人员。
具体什么是客户,什么是用户,我就不花很大的篇幅来介绍了,我想大家肯定都非常熟悉他们之间的区别的,其实简单一句话就可以概括:客户一定是掏钱的,用户不一定是掏钱的。

  作为产品经理,其实在规划一个产品的时候,需要重点考虑的就是基于产品而要面对的这两类人群(其实还有一类,叫buyer,可以翻译成购买者,看了一些这方面的资料,感觉国内是把客户和购买者合为一体了,这样做其实也有好处,就是可以把抽象的客户概念在营销过程中具体成一个实际的人)。

  04年的时候,我在一家为企业提供信息化服务的公司,负责企业信息化产品的管理,一次,我们的一个销售谈了一家半官方性质的公益组织,他们找到我们想用我们的产品搭建一套企业信息系统,包含内部信息管理和外部信息发布,但是那个销售人员只会拉单,对于具体的产品则不是很熟悉,因此,在确定了基本意向和他们的大致需求后,我就陪同这个销售人员一起去见这个准客户。

  和政府客户谈单与企业谈单就是不一样,企业客户会直入主题,深入了解你产品的方方面面,但是政府客户就不一样了,本来想着花半天时间和客户沟通一下就可以了,结果一上午过去了,都没谈到实质的内容,客户倒是挺热情,中午的时又是他买单(呵呵,其实都是公家的钱)请客吃饭,搞的我们都觉得要是这单子不给对方优惠,我们都对不住人家。

  下午继续聊呗,下午的时候他才找了一个他们单位里负责硬件维护的人和我们谈,离开的时候,热情的拉着我的手,对我们说“你们谈吧,具体的我就不管了,XX(维护硬件的那个人),你好好和小X(我的姓)他们了解一下,以后这个系统就是你的工作了”,说完,端着茶杯就到自己的屋子里醒酒去了。

  具体和接下来这个哥们怎么谈的就不说了,但是因为这也是我第一次和政府类客户打交道,还真感觉有些不适应,但是通过这次谈单也给了我一些新的启发。

  1、客户是客户,用户是用户,他们的关注点是完全不一样的。

  就拿这个客户来说,之所以要上信息系统,目的就是为了响应国家政府机关上网的号召,说的直白一些,基本属于完成上级任务,做好政绩工程的动机,至于系统上去以后怎么用,怎么才能用好就不是他们要考虑的,而用户(也就是具体和我们谈的人)对于领导为什么要上这个系统就不会关注太多了,反正我就是一个一般工作人员,领导安排什么就做什么就行了,因此,在那天接下来的交流中,这个人就非常仔细地了解我们的产品到底是什么情况,都有那些功能,甚至都可以了解应该如何具体使用了,因为对于他来说,最关键的怎么能够用好这个产品,不要出意外而引起领导的不满。

  2、关注点的不同,决定了我们在拉单,谈单,签单的时候要用不同的策略。

  如果是企业客户,或许他们最关注的是价格和效果,因此,后来我在培训销售的时候,就告诉他们,对于企业客户,主要要突出咱们产品的性价比和售后服务,如果是政府客户,他们恰恰关注的不是价格和效果,而是购买了这个产品后,能够突出多少自己的政绩,有一次,我们又去一家政府客户,他们的领导上来就问我“你知道XXXX(他们同一个系统的同级单位),他们买这个系统花了XXXX(一个对我来说几乎是天文数字的价格)元,我们决定了我们的系统不能比他们差,价格不用担心”。

  但是做过企业级产品的朋友都知道,政府类客户是最难伺候的,因此,到后来,一般遇到这样的客户,就安排其他人去应付了。

  3、对于产品经理来说,如果说客户是销售要搞定的话,那么,用户就是我们要搞定的。

  刚才那个例子中,到了下午具体谈的时候才轮到我发挥,上午的谈话对我来说就是一种煎熬,下午,我好好地和那个人谈了谈我们的产品,我们产品能够提供那些应用,能够为一个组织带来什么样的价值,并且也了解了他对于我们的产品有什么样的想法,他们希望能够解决什么问题,我们的产品有那些已经实现,那些没有实现。

  对于下午的交流,我感觉双方都是非常满意的,因为我让他充分了解了我们的产品,也解决了他许多心中的问题,至少在向领导汇报的时候不至于稀里糊涂了,而他则让知道了他们更为具体的关于产品的需求,知道我们的产品应该如何改进才能更符合他们的要求。

  因此,这也是需求分析原则四的第一点:产品为最终用户设计,需求的功能转换为最终用户的使用要求而确定。

  那么,刚才说到了,企业级的产品,最终的决定权并不是在具体使用者手里,而是在这个组织的决策人手里(前面提到的购买者有时候也是决策人),在企业客户里,如果这个企业比较规范,那么,在决定购买一个大型产品的时候,往往会经过这样的一个流程,首先是对评估预算,然后是评估产品,最后是产品购买决策。

  在这个过程里,可能会出现两类角色,一类就是购买者,通常又分为技术购买者和业务购买者,他们会分别评估这个产品的技术价值和业务价值,并且会把评估报告提交给决策层(可能是一个人,也可能是一个组织),为最终的决定提供参考。

  而那些不够规范的企业,往往这些角色可能就是一个人,也就是企业或者政府中某个人就有完全决定权,无需什么评估和讨论。

  从上面简单的介绍中可以看出,技术购买者和业务购买者通常既不属于决策者,也不属于最终的使用者,并且有些大型的企业也会采用第三方评估的形式来避嫌,因此,本篇文章中暂不讨论购买者的特征都有那些,我们应该如何应对他们。

  关于产品能够给最终用户带来什么价值,在前面也提到了,其实一句话就可以概括:无论是企业组织还是政府组织,把这个产品用的能够达到领导的期望就可以了。

  这一方面给这个组织中的最终用户带来了很大的压力,另一方面也给我们这些产品经理带来了压力,大家可以回忆一下,面对这类客户,我们要应付的事情是不是要比普通用户多的多呢?

  而对于客户(决策者)来说,我们的产品又带给他们什么价值呢?

  前面也提到了一些,这里总结一下,用我们专业的术语来说,就是要知道他们购买我们产品的真正动机是什么。

  动机是内心的真实想法,而需求则是基于动机的外在表现,有时候是一致的,有时候是不一致的。

  还拿刚才那个例子来说,这个组织购买我们产品的动机(其实就是决策者的动机)是什么呢?很简单,就是为了完成上级要求的政府信息化任务,并且通过完成,最好是出色的完成这个任务来增加自己的政绩。

  至于这个产品到底是什么样子,有什么应用,能够真正为他们带来什么,这并不是他要关心的,会有下属为他打理好这一切的。

  因此,这个产品对于他来说,价值就在于“能够为他带来政绩的提升”。

  因此,这个产品在他眼里就成了一个介质,什么介质呢,提升政绩的介质。

  因此,我们在知道了他的真正动机后,只要基于这个价值点去和他交流,往往都是能够打动他的,例如可以这么说“通过这个系统的对外信息发布平台,可以让你们的政务更加透明和公开”(符合国家提出的政务透明化的要求),还可以这么说“这个系统能够降低你们单位系统的沟通成本,并且提升办公效率”(符合国家提出的政府机关高效廉洁的作风要求),其实,打政府类的单子也不是太难办,主要就是摸清他们的真实动机,而这个动机往往是和国家对机关部门的规定要求,文件指示结合在一起的,因此,如果你是一个做企业级产品的产品经理,尤其主要客户集中在政府部门,那么,了解一些国家的制度规定是非常重要的。

  这也就是需求分析原则四中第二点强调的:为客户寻找价值上的需求。

  通过以上内容的说明,我们可以得出这样一个结论:

  一个产品能够延伸出来的价值是多元化的,产品作为企业综合资源的市场载体,要面对不同动机的人的选择,不同的动机就决定了消费者价值导向的不同,而这正是产品经理在制定产品策略时核心的关注点。

  产品经理依赖产品团队的工作而实现产品策略,针对不同价值导向的消费者需要不同的团队来完成。

  在一开始的时候就说过了,当客户和用户一致的时候,那就是产品经理的焦点所在,例如针对大众用户产品的产品经理应该深有体会,需要考虑的因素应该是最全面的,当客户和用户分离的时候,产品经理关注的焦点就是用户。

  这也就是需求分析原则四中强调的第三点:用户的利益高于一切。

  总结一下需求分析第四个原则的中心思想:

  1、需求分析第四个原则:客户和用户要区别对待。 客户是客户,用户是用户,有时候一致,有时候分离,这是我们首先要搞清楚的。

  2、原则第一点:产品为最终用户设计,需求的功能转换为最终用户的使用要求而确定。 用户决定产品,我们需求工作基于用户,始于用户,归于用户。

  3、原则第二点:为客户寻找价值上的需求。 客户是多样的,价值导向也是多样的,我们的产品能否承载多样化的客户价值决定了产品能否实现最终的交换。

  4、原则第三点:用户的利益高于一切。 产品的最终价值是通过用户来体现的,脱离了用户的产品,就是“皮之不存,毛将焉附”。



需求分析方法—把测试流程图表化
敏捷需求分析五大关键因素
写好市场需求文档的10种技巧
需求分析中减少客户摩擦的法则
软件项目需求管理复杂性分析
EPC-事件驱动的流程链
更多...   


软件需求分析与管理实践
业务建模与业务分析
软件需求分析与管理
软件需求分析师
面向产品的需求分析与管理
IT规划体系与实践


北京 软件需求分析与管理
某知名基金 软件需求分析
联想 业务需求分析与建模
财税领域某IT服务商 测试需求分析
医疗行业 面向产品的需求管理
某知名IT服务商 测试需求分析>
某高新技术公司 测试架构、需求分析
更多...