4

用明道云搭建一个简易的线索分配应用

 2 years ago
source link: https://blog.mingdao.com/19791.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

1-1.jpg

文/明道云实施顾问 况育军

编辑/邵可歆

CRM系统应该算是很常见的一类企业管理系统了。在CRM系统中,线索的分配是很重要的一个环节,那怎么通过明道云去搭建这样一个应用呢?刚好最近我接触到一个有相关需求的客户,今天就以这个客户的需求为例,教大家如何用明道云搭建一个简易的线索分配应用吧。

梳理需求场景

A公司未来打算在公众号、百度、头条等平台上投放广告来获取潜在客户线索。获取线索之后,会把这些线索给到销售人员去电话跟进。公司希望线索能够自动地分配到销售人员,且每个销售人员分配到的线索数量都尽量均匀。销售电话通过电话初步识别线索有效性,将无效的线索放入公海,识别有效的线索可以继续跟进。如果最后没有成交,还是把线索放回公海。公海有专门的人员再次处理这些无效线索,二次识别之后,可选择彻底关闭或再次激活。

基于这个场景,我们可以画一个简单的流程图。

2-4.jpg

提取业务对象

其中比较明显的业务对象是:线索、机会、订单、销售人员、跟进记录、公海、公海管理员。这里需要考虑两个问题,销售人员和公海管理员是否需要分别建两张表?线索和公海是否要分别建两张表?

这两个问题可以这样拆解,先判断这个业务对象是否需要建立表单,再判断这个对象能否和其他对象共用一张表。在明道云的表单设置里,有一个成员字段,直接对应到个人账号,而我们的用户权限设置是基于RBAC(Role-Based Access Control)模型的,把系统权限赋予给预设的角色,再把人员账号添加到角色下面,这样人员便有了角色对应的权限。

基于这样的设计,我们来看第一个问题,“销售人员和公海管理员是否需要建两张表?”假如这两个对象只需要区分操作权限,那直接通过角色就可以实现,二者不需要建表单去记录。

但是,整个场景中有这么一个需求,线索需要均匀地自动分配给每个销售人员。在这一步,销售人员不仅是一个拥有权限的角色,而且承载了业务规则;在自动化流程里,可能还会涉及到对销售人员的逻辑判断。于是,我们可以回答第一个问题,销售人员需要单独建一张表,公海管理员可以设置专门的用户角色,不用记录在表单里。

再来看第二个问题,“线索和公海是否需要建两张表?”

首先,线索和公海都有业务操作和逻辑判断,都是要建表单,再判断他们能不能共用一张表。我的方法是假设代入:假设线索和公海共用一张表,现有的业务流程能否顺畅跑通?线索是由销售人员负责,公海由公海管理员负责,我一下子想到了明道云独特的权限控制,可以把同一个表按不同的筛选条件切分视图,给不同的角色以不同的视图权限。

在当前这个场景里,线索和公海用同一张表,以不同视图切分,这个假设理论上是成立的。如果考虑系统拓展性,比如公海未来可能需要和外部系统进行对接,做一些社交软件的客户触达,那么公海就有了相对独立的业务属性和功能属性,所以应该和线索独立开来,分别建表。

其实业务对象还有很大的拓展空间,远不止上面提到的这些,比如客户、联系人、产品等基础信息,或者与订单相关的报价信息、订单明细等,这里不就展开了。

开始应用搭建

构建表单

根据上一步提取的业务对象,只需线索表、机会表、订单表、销售人员表、跟进记录表。这5张表就能实现一个流程闭环,真的“简易”到了极致。

先建一张线索表,设置一个状态字段,根据这个状态字段切分视图。我们可以把已失效状态的线索作为筛选条件,添加一个公海视图;再到用户角色里新建一个公海管理员角色,把这个角色赋予公海视图的操作权限。

这一步完成之后,我们就实现了通过一张表分别管理线索和公海。再分别添加一个彻底关闭视图和我的线索视图。“彻底关闭”视图用于存放从公海里彻底关闭的线索,“我的线索”视图可以限制每个销售人员在这个视图下,只能看到他自己所拥有的线索。

3-4.jpg4-5.jpg

线索表建好之后,我们需要考虑数据来源的问题,再回顾一下需求场景,“A公司未来打算在公众号、百度、头条等平台上投放广告来获取潜在客户线索”。

有三种方案可以获取数据:

一是通过api接口,从各大平台的后台系统直接传输数据到明道云明道云的api是免费开放的,每张工作表建立之后,系统就会自动生成对应的api开发文档(如下图)。但这个方案要求对方系统有对外开放的api接口,而且涉及系统对接的话,就不是一般业务人员能够搞得定的,不符合本文“简易”的主题。

第二种方案是从投放平台的后台系统把线索数据导出为Excel,再导入线索表。这种方案难度相对较低,但是比较耗费人力,而且对客户线索的响应不够及时。

第三种方案是通过明道云自带的公开表单获取数据.由外部用户填写表单后直接把数据写入系统,并可以触发自动化工作流,分配销售人员及时跟进。

5-5.jpg

综合考虑下来,在这种简单的场景中,第三种方案比较合适,下面我们来看下是怎么设置的。首先,在编辑表单界面,点击公开发布sheet页,设置表单。在这里,可以设置哪些字段需要让外部用户去填写,比如最基础的姓名和手机号。

6-4.jpg

我们也可以设置不同的来源参数,比如百度、头条、抖音等,生成不同的链接和二维码地址,把这些链接分别放到对应的投放平台。用户填写该链接之后,线索表里线索来源这个文本字段会自动地填上来源参数,后续可以根据线索来源区分不同的投放平台,做进一步的流程处理和数据分析。比如统计各个平台线索的转化率,分析各个平台投放的成本效益比,来决定后续是加大还是减少投入。

7-4.jpg

线索表建立完成,其他表单的建立比较简单,直接添加所需字段即可。其中销售人员表涉及分配逻辑,需要增加几个用于工作流判定的字段,分别是:每轮应分线索数量、本轮已分线索数量、本轮剩余应分线索数量,具体用途会在设置工作流时详细说明。

字段设置完成后,再根据实际需要添加关联关系。需要注意:关联关系是一对一还是一对多,比如线索和机会,应该是一条线索关联多个机会。因为如果机会关闭,机会关联的线索会失效进入公海,再次激活这条线索后,它应该生成新的机会。

8-3.jpg

设置工作流

上述场景的工作流里,稍微有一点难度的是线索的平均分配,但是了解原理之后其实也非常简单。这里要用到上文提到的销售人员表的三个字段:每轮应分线索数量、本轮已分线索数量、本轮剩余应分线索数量。其中本轮剩余应分线索数量=每轮应分线索数量-本轮已分线索数量,它是一个公式字段,会跟随前两个字段动态变化。

工作流的设置逻辑是这样的:如果是平均分配,每个销售每轮应分1条线索,每轮应分线索数量=1,本轮已分线索数量初始值为0,因此本轮剩余应分线索数量的初始值=1-0=1。

每当有线索新增时(即外部人员提交表单之后)会触发工作流,随机查找一名剩余应分线索数量>0且为最大的销售人员,线索分给他,该销售人员本轮已分线索数量+1,本轮剩余应分线索数量=1-1=0,即该销售本轮不用再分线索了。

当一轮走完,所有销售都分到了1条线索,系统查找不到本轮剩余应分>0的销售人员时,则把所有人本轮已分线索更新为0,本轮剩余应分都=1-0=1,重新开始下一轮分配。

这个逻辑,其实不仅仅可以由平均分配实现,还可以按不同权重分配实现平均分配的时候,每人每轮应分数量都设置=1,按权重分配的时候,能力突出的销售每轮应分数量可以设置=2,其他人设置=1,那他就能分到其他人两倍的线索。

系统流程图如下:

9-3.jpg

工作流设置如下:

10-3.jpg11-3.jpg12-2.jpg13-%E8%BF%85%E6%8D%B7PDF%E8%BD%AC%E6%8D%A2%E5%99%A8.jpg

OK,一个线索分配的应用做好了,是不是很简单,快去动手试一试吧!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK