如何理解并设计CRM系统?(从Salesforce看看)

qinzhiqiang 07-15 15:51 648次浏览

如何理解并设计CRM系统?(从Salesforce看看)

本文笔者将通过分析Salesforce的设计逻辑和思路,从其中总结出CRM系统的设计逻辑,以及在设计中应该注意的一些问题。

从Salesforce看,如何理解并设计CRM系统?

最近由于工作所需,为公司的销售团队设计了一套内部使用的CRM销售管理系统。

为了设计好该类型的产品,特地去研究并分析了该领域的巨头产品——Salesforce,通过分析该产品的设计逻辑和思路,对自己的产品产生一起启发和思考,并且在实际设计过程中面临的一些问题也同时分享出来,以期给大家一些启发。

为什么是Salesforce

对B端产品接触较少的人可能对Salesforce不太了解,但是只要涉及到B端,一定会提到Salesforce这个B端领域的巨头,特别是国内的B端产品或多或少都收到Salesforce的影响。

根据互联网女皇玛丽·米克尔最新发布的2019年互联网趋势报告:Salesforce公司以1250亿美元市值牢牢占据B端领域市值第一的地位,并且在全球互联网企业市值中排名第11位,力压我们熟知的Uber、Booking、美团、百度等公司。

从Salesforce看,如何理解并设计CRM系统?

是什么支撑起了Salesforce如此高的市值?

抱着研究和为自己产品找想法的目的,试用了Salesforce的免费试用版,顺便说一句Salesforce提供长达30天的免费试用期,并且开放所有的功能,足以看出Salesforce的自信和开放程度。

Salesforce总体的设计逻辑

由于Salesforce已经是一个非常完整的生态,涉及到企业的方方面面,因此本文只分析Salesforce的CRM,及销售管理系统。Salesforce整个产品的设计是任务和目标导向的,从主页的设计就可以看出,Salesforce在分析公司时,采用如下的公式:

业务流=目标+任务

先制定整体的业绩目标,然后目标通过时间段拆解成每个阶段甚至每天的任务,任务则可以拆解成具体的客户,而客户又来源于漏斗:潜在客户→业务机会→联系人→客户。

如下图所示:

从Salesforce看,如何理解并设计CRM系统?

通过这种方式,Salesforce将不同公司的销售业务都抽象出共通的模型,从而设计更加通用的形式。不得不说,Salesforce对业务的拆解比国内大多数同类型公司更加细致和用心。

从菜单导航看Salesforce对销售进程的理解

首先看菜单栏,和一般同类型的产品相比,采用比较少见的横向菜单布局,从视觉上对用户更加友好。

并且,每个模块下拉菜单都只有新建或者历史记录两栏。对比国内的CRM产品会在下拉菜单中加入很多子栏目,Salesforce设计更加简洁,尽量把功能都放在一个页面里,通过合理的布局让用户减少点击的操作步骤。并且,当用户习惯了该产品之后,会发现想要新增内容会非常方便快捷。因为新增对于销售是一个比较高频的需求,不管是新增客户还是任务等。

从菜单导航设置来看,Salesforce对整个销售的各个进程考虑的非常全面。

从客户设置就可以看出,Salesforce将客户分成客户、联系人、潜在客户。

从功能设计可以看出,三者的区别是:客户是已经确定有交易关系的主体,而一个客户会对应多个联系人——即一家公司会派出多个员工和其他公司接触。比如会从一般的业务人员到部门领导甚至到公司高管,Salesforce充分考虑到现实商业接触中多层级的接触模式,因此这方面考虑的还是非常细致的。

如下图所示:

从Salesforce看,如何理解并设计CRM系统?

潜在客户则是和公司没有确定正式的合作关系,但是已经有初步接触有发展成客户前景的其他公司。

由于公司刚接触的时候往往只会派一个人进行初步接触,所以这里没有设计多个联系人情况。当和潜在用户接触时,Salesforce对该类型事件主要抽象成两个模块:进程状态和任务事件,这也符合绝大多数公司做市场时候的需求。

从Salesforce看,如何理解并设计CRM系统?

Salesforce提供仪表板的功能来监控业务指标和分析销售进程,这也是国内CRM产品比较少使用的形式。

在仪表板中,Salesforce关注的数据指标主要包括:每个阶段的销售额;salesforce定义的销售阶段包括:qualification(可以理解成接触阶段)、need analysis(评估阶段)、negotiation(协议阶段)、closed won和closed fail(交易成功和交易失败),以及交易成功和交易失败的客户来源和具体客户。可以看到,也是以完成业绩目标为导向,来分析完成和失败的原因。

从Salesforce看,如何理解并设计CRM系统?

总结

总结一下:Salesforce在设计CRM产品时,首先从大的维度定义产品要实现的目的,在这里就是完成业绩目标,然后通过将目标拆成每阶段的任务——就是获得足够多的客户数量。

而客户则来源于层层的转化,通过这种方式,产品的逻辑和架构逐渐清晰,也为接下来设计自己的产品提供了思路。

设计自己的CRM产品

1. 如何分析并找到核心需求?

既然分析完了Salesforce产品,为什么要先分析需求?

首先,上述的Salesforce产品,是分析了大量公司真实的业务需求,包括其他产品的思路,从而提炼出最核心的需求设计成这种形式。因此,设计产品的核心还是要从需求出发,分析并找到核心的需求,才能找到真正的高效的业务流转方式。

B端产品需要和大量的一线业务人员沟通需求,确定他们的痛点和难点,而由于这些业务人员大多是从自己的视角出发,一碰到问题就容易产生新的想法,因此这种需求往往是“拍脑袋的”。

而作为产品经理,需要根据业务人员所说的需求抽丝剥茧,找到需求的共同点,从而提炼出核心需求。B端产品面临的难点往往是定制化和通用性的取舍,一方面是要根据业务人员的实际需求设计产品,另一方面则需要抽象出通用和共同的东西,形成一定的通用性组件,从而实现产品的良好的可拓展性。

这里推荐需求分析的PSP方法:即P(Person,角色)、S(Scenes,场景)、P(Paths,路径),下面通过一条具体的需求来说明如何进行分析。

首先,这条需求非常不明确,主要体现在没有说明如何录入和查看哪些信息,这时候就需要和一线业务人员进一步明确,查看的是哪些客户信息。

当明确完之后,需要确定录入的方式是通过手动录入,还是其他接口来自己导入,后续和小李沟通细化发现是通过上一步筛选出来的用户。因此,可以通过对接上一步产品的数据库,来实现数据的自动导入,并且增加手动录入和修改的功能,防止数据有错误。

因此,该需求的核心点是:快速确定客户信息,因此通过自动导入比手工录入和批量录入都更能解决问题。

同时,通过PSP方法,需要明确不同角色的使用场景和路径。在该需求中,主要涉及到管理员、销售两种角色,录入功能应该只针对销售,因为他们是距离客户最近的人员,第一时间会了解到客户的新的信息。而修改功能应该只针对管理员,因为他们负责管理销售,因此他们有权修改客户的进程等相关信息。

2. 设计产品的过程中需要注意的三个问题

在确定完核心需求并确定了产品的基本架构和框架之后,接下来再具体设计过程中还需要时刻注意以下几个问题,从而设计的产品有更大的合理性和可拓展性。

1)数据从哪里来,到哪里去?

乍一看很像哲学家苏格拉底所说的“从哪里来,到哪里去”的哲学问题,但是这其实也是设计该类型产品的一个底层逻辑。

C端的产品数据是明确的来自用户,而B端产品的数据往往来源于其他和系统和产品的传输,因此明确清楚系统的数据从哪里来,以及如何流转是设计该产品的第一步也是最基础的一步。

拿自己设计的系统为例:由于本系统是针对客户设计的销售管理系统,因此最重要的客户数据来自于H5和小程序收集的客户信息,包括客户自己填写的手机号和其他基本资料。

因此,首先要和技术确定开发相关的接口去接收和传递数据到系统中。当数据进入到系统中后,要确定数据的流转规则,也就是先后顺序和对应关系,本系统采用的是三级分配的原则,也就是数据到最终的销售和经过三层的分配,如下所示:

从Salesforce看,如何理解并设计CRM系统?

这种分配方式确实不够快速简洁,但是好处有一下两点:

  1. 方便组织管理以及职级分工,每个角色都有自己明确的数据边界和范围。
  2. 方便客户数据和销售的1对多匹配。不同公司对客户的跟进有不同的规则,比如有些公司规定是1个客户对应1个固定销售,单独负责整个流程的转化,而很多公司往往是1个客户对应多个销售,也就是当1个销售转化不顺时往往会换一个销售跟进,因此,这样设计有利于客户对应销售的快速调整。

2)权限角色问题

权限与角色往往是该类型产品的一个重点,不过在设计权限角色之前,首先需要确定:权限角色实现的目标是什么?

本质上来说,设计权限角色是为了让不同的角色有不同的功能权限和数据权限,而两者的区别如下所示:

从Salesforce看,如何理解并设计CRM系统?

因此,确定好不同角色对应的功能权限和数据权限后,会对不同角色的菜单设计和页面设计产生影响。

举例来说,上图中的角色1是偏管理员的角色,因此展示给他的菜单栏包括了人员配置的功能,而其他角色就不应该展示该功能,如下图所示:

从Salesforce看,如何理解并设计CRM系统?

(角色1)

从Salesforce看,如何理解并设计CRM系统?

(其他角色)

3)哪些部分应该模块化?

最后,在具体设计功能时,需要考虑如何把关联性较强的功能或需求放在一起,从而实现系统的模块化,达到“松散耦合”:各模块内部的功能紧密联系,同时各模块直接既有一定的关联又保证一定的独立性,从而有利于未来系统的扩展。

拿自己做的系统举例:

在做的过程中碰到的一个问题是:数据统计功能应该放到各个模块中,还是单独用一个模块整体展示?

因为很多模块都有数据统计的需求,并且统计的时间维度和字段都有不同,因此比较纠结到底采用什么形式。最后,还是从系统可拓展性的角度,把数据统计单独做成一个模块,方便未来在模块展示更多的数据分析相关功能。而对于不同模块的数据统计如何统一?

这需要对整个业务抽象出更底层的信息,找到最关注的几个数据指标,最后进行整合,整合前如下图所示,数据指标较多并且比较零散。

从Salesforce看,如何理解并设计CRM系统?

整合之后,把总体数据和时间维度的数据通过一个时间筛选器进行筛选,使得数据的灵活性大大增加,更加聚焦于核心指标,如下图所示:

从Salesforce看,如何理解并设计CRM系统?

最后,整个系统的模块大致是如下形式,便于后期更加灵活的拓展。