文/明道云实施顾问 况育军
编辑/邵可歆
CRM 系统应该算是很常见的一类企业管理系统了。在 CRM 系统中，线索的分配是很重要的一个环节，那怎么通过明道云去搭建这样一个应用呢？刚好最近我接触到一个有相关需求的客户，今天就以这个客户的需求为例，教大家如何用明道云搭建一个简易的线索分配应用吧。
梳理需求场景
A 公司未来打算在公众号、百度、头条等平台上投放广告来获取潜在客户线索。获取线索之后，会把这些线索给到销售人员去电话跟进。公司希望线索能够自动地分配到销售人员，且每个销售人员分配到的线索数量都尽量均匀。销售电话通过电话初步识别线索有效性，将无效的线索放入公海，识别有效的线索可以继续跟进。如果最后没有成交，还是把线索放回公海。公海有专门的人员再次处理这些无效线索，二次识别之后，可选择彻底关闭或再次激活。
基于这个场景，我们可以画一个简单的流程图。
提取业务对象
其中比较明显的业务对象是：线索、机会、订单、销售人员、跟进记录、公海、公海管理员。这里需要考虑两个问题，销售人员和公海管理员是否需要分别建两张表？线索和公海是否要分别建两张表？
这两个问题可以这样拆解，先判断这个业务对象是否需要建立表单，再判断这个对象能否和其他对象共用一张表。在明道云的表单设置里，有一个成员字段，直接对应到个人账号，而我们的用户权限设置是基于 RBAC（Role-Based Access Control）模型的，把系统权限赋予给预设的角色，再把人员账号添加到角色下面，这样人员便有了角色对应的权限。
基于这样的设计，我们来看第一个问题，**“销售人员和公海管理员是否需要建两张表？”**假如这两个对象只需要区分操作权限，那直接通过角色就可以实现，二者不需要建表单去记录。
但是，整个场景中有这么一个需求，线索需要均匀地自动分配给每个销售人员。在这一步，销售人员不仅是一个拥有权限的角色，而且承载了业务规则；在自动化流程里，可能还会涉及到对销售人员的逻辑判断。于是，我们可以回答第一个问题，销售人员需要单独建一张表，公海管理员可以设置专门的用户角色，不用记录在表单里。
再来看第二个问题，“线索和公海是否需要建两张表？”
首先，线索和公海都有业务操作和逻辑判断，都是要建表单，再判断他们能不能共用一张表。我的方法是假设代入：假设线索和公海共用一张表，现有的业务流程能否顺畅跑通？线索是由销售人员负责，公海由公海管理员负责，我一下子想到了明道云独特的权限控制，可以把同一个表按不同的筛选条件切分视图，给不同的角色以不同的视图权限。
在当前这个场景里，线索和公海用同一张表，以不同视图切分，这个假设理论上是成立的。如果考虑系统拓展性，比如公海未来可能需要和外部系统进行对接，做一些社交软件的客户触达，那么公海就有了相对独立的业务属性和功能属性，所以应该和线索独立开来，分别建表。
其实业务对象还有很大的拓展空间，远不止上面提到的这些，比如客户、联系人、产品等基础信息，或者与订单相关的报价信息、订单明细等，这里不就展开了。
开始应用搭建
构建表单
根据上一步提取的业务对象，只需线索表、机会表、订单表、销售人员表、跟进记录表。这 5 张表就能实现一个流程闭环，真的“简易”到了极致。
先建一张线索表，设置一个状态字段，根据这个状态字段切分视图。我们可以把已失效状态的线索作为筛选条件，添加一个公海视图；再到用户角色里新建一个公海管理员角色，把这个角色赋予公海视图的操作权限。
这一步完成之后，我们就实现了通过一张表分别管理线索和公海。再分别添加一个彻底关闭视图和我的线索视图。“彻底关闭”视图用于存放从公海里彻底关闭的线索，“我的线索”视图可以限制每个销售人员在这个视图下，只能看到他自己所拥有的线索。
线索表建好之后，我们需要考虑数据来源的问题，再回顾一下需求场景，“A 公司未来打算在公众号、百度、头条等平台上投放广告来获取潜在客户线索”。
有三种方案可以获取数据：
一是通过 API 接口，从各大平台的后台系统直接传输数据到明道云。明道云的 API 是免费开放的，每张工作表建立之后，系统就会自动生成对应的 API 开发文档（如下图）。但这个方案要求对方系统有对外开放的 API 接口，而且涉及系统对接的话，就不是一般业务人员能够搞得定的，不符合本文“简易”的主题。
第二种方案是从投放平台的后台系统把线索数据导出为 Excel，再导入线索表。这种方案难度相对较低，但是比较耗费人力，而且对客户线索的响应不够及时。
第三种方案是通过明道云自带的公开表单获取数据.由外部用户填写表单后直接把数据写入系统，并可以触发自动化工作流，分配销售人员及时跟进。
综合考虑下来，在这种简单的场景中，第三种方案比较合适，下面我们来看下是怎么设置的。首先，在编辑表单界面，点击公开发布 sheet 页，设置表单。在这里，可以设置哪些字段需要让外部用户去填写，比如最基础的姓名和手机号。
我们也可以设置不同的来源参数，比如百度、头条、抖音等，生成不同的链接和二维码地址，把这些链接分别放到对应的投放平台。用户填写该链接之后，线索表里线索来源这个文本字段会自动地填上来源参数，后续可以根据线索来源区分不同的投放平台，做进一步的流程处理和数据分析。比如统计各个平台线索的转化率，分析各个平台投放的成本效益比，来决定后续是加大还是减少投入。
线索表建立完成，其他表单的建立比较简单，直接添加所需字段即可。其中销售人员表涉及分配逻辑，需要增加几个用于工作流判定的字段，分别是：每轮应分线索数量、本轮已分线索数量、本轮剩余应分线索数量，具体用途会在设置工作流时详细说明。
字段设置完成后，再根据实际需要添加关联关系。需要注意：关联关系是一对一还是一对多，比如线索和机会，应该是一条线索关联多个机会。因为如果机会关闭，机会关联的线索会失效进入公海，再次激活这条线索后，它应该生成新的机会。
设置工作流
上述场景的工作流里，稍微有一点难度的是线索的平均分配，但是了解原理之后其实也非常简单。这里要用到上文提到的销售人员表的三个字段：每轮应分线索数量、本轮已分线索数量、本轮剩余应分线索数量。其中本轮剩余应分线索数量=每轮应分线索数量-本轮已分线索数量，它是一个公式字段，会跟随前两个字段动态变化。
工作流的设置逻辑是这样的：如果是平均分配，每个销售每轮应分 1 条线索，每轮应分线索数量=1，本轮已分线索数量初始值为 0，因此本轮剩余应分线索数量的初始值=1-0=1。
每当有线索新增时（即外部人员提交表单之后）会触发工作流，随机查找一名剩余应分线索数量 >0 且为最大的销售人员，线索分给他，该销售人员本轮已分线索数量 +1，本轮剩余应分线索数量=1-1=0，即该销售本轮不用再分线索了。
当一轮走完，所有销售都分到了 1 条线索，系统查找不到本轮剩余应分 >0 的销售人员时，则把所有人本轮已分线索更新为 0，本轮剩余应分都=1-0=1，重新开始下一轮分配。
这个逻辑，其实不仅仅可以由平均分配来实现，还可以按不同权重分配实现。平均分配的时候，每人每轮应分数量都设置=1，按权重分配的时候，能力突出的销售每轮应分数量可以设置=2，其他人设置=1，那他就能分到其他人两倍的线索。
系统流程图如下：
工作流设置如下：
OK，一个线索分配的应用做好了，是不是很简单，快去动手试一试吧！