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