作者：京东科技 李良文
一、前言
电销是什么？就是坐席拿着电话给客户打电话吗？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 平台之企微平台的建设计划分享也在飞奔而来的路上，敬请期待。