编辑导语：搭建B端业务系统不容易。如何设计CRM系统，实现CRM系统的建立和落地？在本章中，作者总结了客户关系管理系统销售领域的设计和操作过程。我们来看看，也许对你有启发。
在系统状态调查、代码逻辑梳理、业务调查、老板意图调查等一系列“软工作”告一段落之后，我们终于可以开始产品设计的“硬工作”了，这是很难思考的，带着枷锁跳舞，哈哈。
难回，这就是产品经理的价值。
在CRM销售领域的整体设计过程中，我使用了三个工具：
# 1.工具1:用户体验的五个要素
在《用户体验元素》这本书里，定义了从上到下有五层逻辑关系，我把它们翻译成更符合我语境的内容，具体如下：
*战略层面：可以理解为这个体系的定位和最终目标；
*范围层：基于战略层总结的功能点和业务流程；
*结构层：基于功能点和业务流程，设计页面流程；
*框架层：各流程节点上页面的内容布局；
*表示层：每页的视觉设计。
作者又强调了两个点让我受益匪浅：
关于第（2）点,我是在踩坑之后才发现的。之前学习的时候没看懂，就是下图中下半部分的波浪图。
如果你没有用过或者不理解，我可以举个例子来理解。
比如在范围层的时候你设计了一套销售代下单的流程，步骤A-B-.
C-D，然后你正常设计结构层页面的页面之间的跳转流程，然后你根据页面流程快速设计页面中的跳转条目。
相当于从范围层开始，你不间断地干通了结构层，框架层，共3层。
这时，老板突然说在范围层的流程要改
(日常操作.)，你答应下来之后，会发现不仅流程变了，后面结构层的页面跳转逻辑也变了，下一帧层的跳转入口更变了，有的入口没了，有的内容凭空出现.
如果你跟随第（2）点.
需求，完成范围层的业务流程图后，可以设计结构层的页面流程图，但是不能继续做。您必须确保范围层的流程图是正确的，然后继续对框架层进行操作。
这看起来很麻烦，但实际上这是项目最节省时间的方法。如果老板想看到最后的结果，从根源上否定，就要和老板好好提前，告知时间损失。不然基本过程中会有大佬反复横跳，对应的细节涉及几十页，真的吐了。
# 2.工具2:用户故事图
在战略层面，我使用了用户故事图，这是一套描述敏捷开发需求的工具，可以帮助描述更清晰的业务场景和业务需求。
用法也很简单。在顶部，划分用户历史的主要阶段，然后分解到各个业务部门，再分解到部门下的行动和目标，最后在底部整理需求点。
这种方式会很清楚，尤其是当过程很长的时候。图片可能不太清楚，不过没关系，看懂就好。
# 3.工具3: UML工具
正如我在关于UML的文章中提到的，UML的范围可以放在范围层和结构层。如下图所示。
真的是利器，可以清晰的理清思路。而且复工后发现配送组没有单独抽象，造成了一些业务上的麻烦，但很快都解决了。
没有UML，交流和讨论可能需要更多的时间。下图就是CRM系统设计中我整理的整套架构逻辑，已经脱敏（有点干）。
上图是UML的类图，这里不是流程图，而是类图，代表了系统中各种业务概念之间的关系。
#四。系统结构说明
基于上面的类图，我们将逐一解释每个类代表的含义。考虑到篇幅的限制，我就介绍一下核心模块，剩下的模块大家可以大局观。
## 1\
. 名片&商机业务中收集到的客户联系方式，一般为手机号
名片和商机的转化，在我做的CRM业务语境下，名片即为一个单独的手机号，商机是基于名片的手机号再附加一个“业务属性1”来生成的（如下图）。
这个逻辑下，就意味着一个名片可以有多个商机，便于销售跟进。
其实这里也暗含一个理念，即客户和商机是独立的，一个客户可有多个商机，有的同学在设计的时候会把商机和客户概念统一，数据也只有一份，造成了浪费。
然后商机也有对应的状态，用来判定是否被销售跟进。
再引申个行业栗子――大家可以讨论。
某电商平台，针对店铺的运营，把店家老板的手机号作为唯一名片标识，然后业务体系中一个老板的手机号会关联多个店铺。此时的商机应该以哪个实体为准？
这个问题属于开放问题了，如果是店铺业务体量都较小，可能以老板粒度为线索更合适，防止不同的销售跟进店铺导致撞单。
但如果是店铺体量很大，小型集团级别，可能就是需要把集团下不同的采购组作为线索了。
针对这个问题，大家可以在评论区里交流，我想会有很多新的收获。
## 2\. 流转规则
因为业务条线多，每个销售适合打的商机种类不同，通过自定义规则的分发，可以让销售更高效的转化。此处的规则积累到一定量级后，可以运用算法来协助，并且逐步替代。
流转规则，是根据商机上的业务属性来判断，通过选定不同的属性组合作为特征，把某个特征的商机，分到某个目标的分配组，让分配组内对应的销售进行转化。业务属性举例如下：
其实这部分市面上有成熟的方案， 叫做“工作流引擎” ，甚至可以找到开源代码。
这类工作流引擎也做过调研，灵活度可以满足要求，但是批量管理工作流时会遇到实例结构不统一的问题，而且想做统计的时候，之前已有工作流会在流程结束时把日志清除，等等原因，改动已有的方案需要的成本更高，所以我们决定自研了一套类似引擎的解决方式，更贴合业务现实现状。
此处会涉及到一个问题，即商机上的业务属性如何标记？不要着急，我后面会单独出一篇文章来讲解。
Tips：这里也总结出一个系统设计经验。在设计具体的逻辑限制时，这个逻辑限制总可以继续向上抽象成类，然后把抽象的类做成功能，就能提高系统的可维护性
## 3\. 角色权限控制
此处的角色控制，是 基于RBAC理论 来设计的，后面也会单独出一篇文章讲解。
RBAC直观解释，就是系统用户的权限，可以拆成两个层面，一个是页面的权限，一个是数据的权限。
页面权限控制这个用户能访问到那个页面；
数据权限是此用户能通过查询看到的数据范围，有行权限控制也有列权限控制，看具体业务需求。
把页面和数据分开，可以很好的提高配置的灵活性。比如销售类角色，必须包含工作台，但是不同的销售，他们每个人看到的销售数据只能限制在他们自己的销售组内，更细化的是只有组长能看到组内的，普通销售只能看到自己的。
通过角色授权，让“销售”的角色页面范围包含工作台。然后每个销售员工在自己的用户下有单独的数据范围选择，这样就实现了最大的灵活程度，最小的配置工作量。
## 4\. 订单的多重绩效判定
整个类图中，应该是下面这里看起来绕一些了，先后展示了多种订单的类，这里的作用其实是要设计一种完整的判定机制。
在一个未来要迭代成自动化营销和销售的CRM方案里，销售并不是成单唯一的因素，未来肯定还会有其他成单的归因点，此处要做到系统上有预留准备。
销售的成单是从订单系统的基础订单上同步的，在成单时通过关联查询成单手机号&跟进记录&跟进时刻&销售坐席来判定是销售成单，可视为销售归因的成单。这是第一层。
在第二层，及时判定为销售成单了，但这个成单的钱不一定会算到销售的绩效里，这个比较好理解，举个不恰当的例子，一个卖鸭梨的档口，在结算的时候突然出现了猪肉，这就是不合业务规范的。
所以就会有这层限制，不过也看业务的管理理念，如果放开，不配置即可，如果收紧，再开启就好，灵活性很高。此处的功能点也和研发评估过，成本很低，为了防止业务的不确定性，这算是一个很好的兜底。
以上，就是我设计的CRM销售域的系统结构，这里还有很多细节，比如和大数据的打通，和人力系统的打通等等，以及具体页面设计，更上层的数据营销方法论，有很多内容可以分享的，只不过想分享的实在点，就需要拿结果验证这个方法可行，不过涉及到业务数据，内容略敏感，就没写，还请见谅~
看到这里，也希望对你有帮助，如果有其他问题，欢迎私信。
接下来，就来讲解下系统的实施。
# 五、系统的实施
经过紧张的研发和测试之后，就涉及到系统上线后的实施工作了。对于一个B端的系统，在事后总结经验，实施阶段要做如下方面的准备。
## 1\. 系统准备
1. 数据库环境的打通兼容；
2. 回滚方案的准备；
3. 业务新老数据的切割。
## 2\. 业务准备
1）是否有实施的核心决策人？如果有的话最好是BOSS，如果BOSS躲在后面，又没有业务的人上前，只能说难度会很大。考验组织，也考验决策者。
2）是否有业务侧的实施指挥与培训人员，在实施遇到问题后及时跟进反馈。
3）是否有试点小组？可以尽量让业务的冲击降到最小。
4）提前准备新系统的配置方案。
5）提前准备新系统的申请相关机制，做到有序处理。
## 3\. 产研侧准备
1. 产研在实施当天的现场值班，节假日值班安排；
2. 产研侧的应急联系人；
3. 实施期间的需求迭代工作节奏，便于快速反馈问题，迭代上线，降低业务情绪阻力；
4. 运维侧服务器的应急方案，回滚方案。
# 六、写到最后
对于B端的业务而言，新产品的开发，决策者多少带些试试看的心理因素。
一方面想突破困局，另一方面也想避免风险，这个是非常合理的考量。能做的，就是保持信心，时刻权衡改革的初心还有现实的困难，如果确定无法承担，就及时止损，如果发现有明显的优势，就要继续坚持，哪怕反对的呼声很高也是暂时的，只要体现在了业绩上，大家就都没话说了。
感谢各位朋友的阅读，CRM的系统结构与实施工作的内容就告一段落，后面会针对本文提到的《业务属性的标记》《基于RBAC的权限体系设计》再出两篇文章。
大家如果有相关的想法，或者有问题，欢迎评论区留言交流，平时工作较忙，我会集中回复。
作者：罗文正雄；公众号：罗文正雄
本文由 @罗文正雄 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Pexels，基于 CC0 协议
