作者：京东科技 李良文

电销是什么？就是坐席拿着电话给客户打电话吗？no no no，让我们一起走进京音平台之电销系统。

京音平台2020年初开始建设，过去的两年多的时间里，经历了跌宕起伏，有经验、有教训，整体来说平台经历了人工、自动化阶段，目前处于初步智能化阶段，希望可以将过去的一些心路历程分享给大家，共同交流、共同进步。

京音平台是集电销、企业微信等于一体的综合智能SCRM SAAS化系统，支持多渠道管理、全客户生命周期管理、私域营销运营等主要功能，目前已经有60+京东各业务线入驻，专注于为职场提供一站式的客户管理及一体化的私域运营服务。

1、业务架构

京音平台主要包括电销和企微两类业务流程，为京东各业务线提供了营销获客->客户管理->跟进培育->量控频控->交易促成->客户触达->交易转化->业绩核算等能力，通过全流程的闭环功能让客户营销变得更简单更高效，使用自动化、智能化能力矩阵打造更懂用户的营销一体化平台。

2、能力地图

电销系统主要由营销获客能力、客户管理能力、跟进培育能力、量控频控能力、交易促成能力、客户触达能力、业绩匹配能力七大能力矩阵组成，七大能力串联、组合出可应用于各场景通用组件，例如人群筛选、人群分发、人群获客等客群类组件，短信触达、外呼触达等通信类组件，在提供稳定服务的同时兼容各类相似场景，提升系统组件化程度进而提升敏捷迭代质量及速度。

3、核心流程介绍

下面让我们一起看下电销系统具体是如何获客，又是如何进行客户管理、如何进行风险管控、外呼功能矩阵以及关键技术架构是怎么样的。

•营销获客

营销获客又分成两大类：一是客户主动联系产生的获客，此类获客渠道的客户价值及转化率极高，但量级较低；二是客户行为或是平台行为产生的获客，此类获取渠道产生的客户量级较大，包括app获客、业务自有获客、客户浏览行为等获客方式，是平台主要获客来源。

•客户管理

获客后，结合系统自动及人工手动识别客户意向，将客户分配至合适的坐席，以此来提高潜在转化率，期间若客户意向或是坐席职责发生变更，可以将客户动态的分配至更适合的坐席，也可以将为客户提供更好的服务。

• 外呼作业

京音系统为了帮助各业务线降本增效，面向不同业务场景提供不同的外呼作业方式，例如催收场景的一句话外呼，人工场景的预测式外呼，智能化场景的三段一体外呼。

一句话外呼：例如白条到期需要简短的一句话提醒用户还款，可以将用户的脱敏信息方到语音中进而提升用户信赖度。

预测式外呼：系统自动化的对客户进行外呼，当客户接通后系统再按预先配置好的规则将客户通话转接到人工坐席，经实际数据统计分析，每单通话平均振铃等待时间为26.7秒，每天预测式外呼作业可以节省大量人工等待时长。

三段一体外呼：三段一体外呼在预测式外呼的基础上增加了机器人坐席与客户沟通，在识别到客户有意向后再转接到人工坐席，增加此步骤目的是进一步过滤掉接通了但无意向的客户，从而将人工坐席的价值最大化，三段一体外呼操作流程如下：

• 量控频控

量控频控是京音平台安全运营的重要保障，包括事前防控、事中管控、事后监控三部分，基于规则引擎覆盖了拨打、通用配置化人群等场景，20+细分子类的量控频控规则，并支持面向不同业务线提供个性化、可定制的营销量控频控规则，顶层设计上，平台将安全生产视为第一红线，通过第一优先级的平台级量控频控策略进行宏观防控，规避营销过程中产生的各种风险；

1、数据存储架构

京音平台虽然是to b系统，但也面临着比较常见的挑战：数据量大、数据操作及更新频繁，数据存储架构经历了单一mysql主从、单一mysql主从备、垂直拆分mysql主从、垂直及水平拆分mysql+elasticsearch为主的混合数据架构模式，不同数据存储面向不同场景提供服务。mysql数据存储拆分示意图如下：

用于支持各类场景信息筛选的elasticsearch数据模型示意图如下：

2、数据异构架构

上面描述了mysql+elasticsearch为主的混合存储架构面向不同业务场景提供服务，在大量数据流转压力下，会面临一些比较麻烦的问题，例如数据一致性问题，elasticsearch tps及qps压力问题，下面聊聊京音如何解决这两类问题。

• 数据一致性问题

我们采用最终一致性俩解决mysql到elasticsearch数据一致性问题，允许毫秒~秒级数据延迟，elasticsearch本身就是一个准实时数据架构，不适合实时场景使用。例如保存立刻查询、防重等场景不适合使用elasticsearch。

• 集群压力

mysql的压力采用的是比较常见的基于业务特点做了垂直及水平拆分方案， 基于我们的数据及软硬件配置，单库可以抗住2万qps及1万tps，16个库总qps为32万，总tps为16万，按每年25%业务增长，目前的mysql架构设计可以支持3年以上长期发展。

elasticsearch集群也使用了类似mysql思想做了配置化的垂直拆分，在数据写入时按主维度对信息流做了合并，在京音的业务场景下，把一次事务的批量数据合并成一条数据写到elasticsearch，极大的降低了elasticsearch的写入频率，另外一些主键、切分键等适合mysql查询的场景优先走mysql，充分使用不同存储引擎的优点满足各类业务场景需求。

数据异构图如下： 

通过以上三部分，整体的介绍了京音平台发展的心路历程以及具体使用哪些能力矩阵支撑了业务高速发展，并对其中的一些关键功能及技术架构进行了详细的说明。希望通过本文，可以帮助大家对京音SCRM平台有进一步的认识，与此同时，京音SCRM平台之企微平台的建设方案分享也在飞奔而来的路上，敬请期待。