作者：京東科技李良文

一、前言

電銷是什么？就是坐席拿著電話給客戶打電話嗎？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，充分使用不同存盤引擎的優點滿足各類業務場景需求，

資料異構圖如下：