作者：京東科技 李良文

一、前言

電銷是什麼？就是坐席拿著電話給客戶打電話嗎？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平臺之企微平臺的建設方案分享也在飛奔而來的路上，敬請期待。