微电SCRM平台之一起玩转电销系统
导读 电销是什么？就是坐席拿着电话给客户打电话吗？这样的理解过于简单，本文将带领读者们一起走进微电平台之电销系统。微电平台2020年初开始建设，过去的两年多的时间里，经历了跌宕起伏，有经验、有教训，整体来说平台经历了人工、自动化阶段，目前处于初步智能化阶段，将一些心路历程分享给读者们，希望可以共同交流、共同进步。
01
平台介绍
在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！
微电平台是集电销、企业微信等于一体的综合智能SCRM SAAS化系统，支持多渠道管理、全客户生命周期管理、私域营销运营等主要功能，目前已经有60+京东各业务线入驻，专注于为职场提供一站式的客户管理及一体化的私域运营服务。
图1 平台图
平台功能矩阵覆盖了内部运营、量化、产品以及外部的职场管理、作业坐席的各种场景诉求，因覆盖用户及角色较广，平台各类功能具备通用化、可配置化的普适特点，例如基于规则引擎的客户筛选、客户回收、频控量控，基于业务线个性化的客户视图、客户筛选条件等。
1.1 业务架构
微电平台主要包括电销和企微两类业务流程，为京东各业务线提供了营销获客->客户管理->跟进培育->量控频控->交易促成->客户触达->交易转化->业绩核算等能力，通过全流程的闭环功能让客户营销变得更简单更高效，使用自动化、智能化能力矩阵打造更懂用户的营销一体化平台。
图2 业务架构图
平台抽象出高度抽象、标准的作业流程，尽可能的提高面向各业务线的通用性以及降低新业务线接入成本，新业务线只需要完成差异化配置即可完成入驻。
1.2 能力地图
电销系统主要由营销获客能力、客户管理能力、跟进培育能力、量控频控能力、交易促成能力、客户触达能力、业绩匹配能力七大能力矩阵组成，七大能力串联、组合出可应用于各场景通用组件，例如人群筛选、人群分发、人群获客等客群类组件，短信触达、外呼触达等通信类组件，在提供稳定服务的同时兼容各类相似场景，提升系统组件化程度进而提升敏捷迭代质量及速度。
图3 能力地图
1.3 核心流程介绍
下面将一起看下电销系统具体是如何获客，又是如何进行客户管理、如何进行风险管控、外呼功能矩阵以及关键技术架构是怎么样的。
1. 营销获客
营销获客又分成两大类：一是客户主动联系产生的获客，此类获客渠道的客户价值及转化率极高，但量级较低；二是客户行为或是平台行为产生的获客，此类获取渠道产生的客户量级较大，包括app获客、业务自有获客、客户浏览行为等获客方式，是平台主要获客来源。
图4 营销获客
2. 客户管理
获客后，结合系统自动及人工手动识别客户意向，将客户分配至合适的坐席，以此来提高潜在转化率，期间若客户意向或是坐席职责发生变更，可以将客户动态的分配至更适合的坐席，也可以将为客户提供更好的服务。
图5 客户管理
3. 外呼作业
微电系统为了帮助各业务线降本增效，面向不同业务场景提供不同的外呼作业方式，例如催收场景的一句话外呼，人工场景的预测式外呼，智能化场景的三段一体外呼。
一句话外呼：例如白条到期需要简短的一句话提醒用户还款，可以将用户的脱敏信息方到语音中进而提升用户信赖度。
预测式外呼：系统自动化的对客户进行外呼，当客户接通后系统再按预先配置好的规则将客户通话转接到人工坐席，经实际数据统计分析，每单通话平均振铃等待时间为26.7秒，每天预测式外呼作业可以节省大量人工等待时长。
三段一体外呼：三段一体外呼在预测式外呼的基础上增加了机器人坐席与客户沟通，在识别到客户有意向后再转接到人工坐席，增加此步骤目的是进一步过滤掉接通了但无意向的客户，从而将人工坐席的价值最大化，三段一体外呼操作流程如下：
??图6 外呼作业
??4. 量控频控
量控频控是微电平台安全运营的重要保障，包括事前防控、事中管控、事后监控三部分，基于规则引擎覆盖了拨打、通用配置化人群等场景，20+细分子类的量控频控规则，并支持面向不同业务线提供个性化、可定制的营销量控频控规则，顶层设计上，平台将安全生产视为第一红线，通过第一优先级的平台级量控频控策略进行宏观防控，规避营销过程中产生的各种风险；
图7 量控频控
02 关键架构设计
理解，首先MCube会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到
2.1 数据存储架构
微电平台虽然是toB系统，但也面临着比较常见的挑战：数据量大、数据操作及更新频繁，数据存储架构经历了单一mysql主从、单一mysql主从备、垂直拆分mysql主从、垂直及水平拆分mysql+elasticsearch为主的混合数据架构模式，不同数据存储面向不同场景提供服务。mysql数据存储拆分示意图如下：
图8 mysql数据存储
用于支持各类场景信息筛选的elasticsearch数据模型示意图如下：
图9 elasticsearch数据模型
2.2 数据异构架构
上面描述了mysql+elasticsearch为主的混合存储架构面向不同业务场景提供服务，在大量数据流转压力下，会面临一些比较麻烦的问题，例如数据一致性问题，elasticsearch tps及qps压力问题，下面讲解微电如何解决这两类问题。
1. 数据一致性问题
采用最终一致性俩解决mysql到elasticsearch数据一致性问题，允许毫秒~秒级数据延迟，elasticsearch本身就是一个准实时数据架构，不适合实时场景使用。例如保存立刻查询、防重等场景不适合使用elasticsearch。
2. 数据集群压力
mysql集群：的压力采用的是比较常见的基于业务特点做了垂直及水平拆分方案， 基于数据及软硬件配置，单库可以抗住2万qps及1万tps，16个库总qps为32万，总tps为16万，按每年25%业务增长，目前的mysql架构设计可以支持3年以上长期发展。
elasticsearch集群：使用了类似mysql思想做了配置化的垂直拆分，在数据写入时按主维度对信息流做了合并，在微电的业务场景下，把一次事务的批量数据合并成一条数据写到elasticsearch，极大的降低了elasticsearch的写入频率，另外一些主键、切分键等适合mysql查询的场景优先走mysql，充分使用不同存储引擎的优点满足各类业务场景需求。
数据异构图如下：
图10 数据异构图
03 总结
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。从设计稿出发，提升页面搭建效率，亟需解决的核心问题有：
通过以上三部分，整体地介绍了微电平台发展的心路历程以及具体使用哪些能力矩阵支撑了业务高速发展，并对其中的一些关键功能及技术架构进行了详细的说明。希望通过本文，可以帮助读者们对微电SCRM平台有进一步的认识，与此同时，微电SCRM平台之企微平台的建设方案分享也在飞奔而来的路上，敬请期待。