很多同學呼喚想看實戰案例，今天它來了。全文硬核干貨，大家做好扶穩慢慢看哦。

問題場景：某互聯網大廠TOB業務線，可以向平臺商家提供SaaS/Paas類服務，但苦于銷售水平不高，溝通話術質量不佳，轉化率不足。現計劃做話術培訓，提升客戶轉化率。

一、原始模型

最簡單的做法，定義話術A，話術B，倆版本。直接看轉化率，哪個高了用哪個就好了！（如下圖）

那么，這么做有啥問題不？

二、高級建筑

最簡單的做法，可能有幾層問題：

問題1：未考慮銷售本身的影響。有可能銷售本身能力強，所以才賣得好。因此，需要針對不同層級的銷售，比如S級、A級、B級、C級，單獨分析話術效果。

問題2：未考慮客戶的影響。有可能特定客戶就是容易成交，因此需要區分客戶等級，比如VIP1，VIP2，VIP3，分別看效果。

問題3：未考慮話術實際影響大小。有可能有的客戶就是說啥都行，有的客戶不管說啥都沒用，只看價格。因此要做交叉測試，找到能受話術影響的客群（如下圖）。

最后，得到的結果可能如下圖，為每一類銷售，每一種客戶配置合理的話術，最大化產出。

三、第一層地基

問個簡單的問題:銷售的S\A\B\C級別是咋來的？

既然有分級，那么得有判定標準。

而構建判斷標準本身，就是一個大工程

比如：

1、是否業績表現好的，就是好銷售？

2、意向、簽約、回款、復購，哪個方面能證明他是好銷售？

3、以上四個方面，每個都至少有數量和金額兩個指標……

4、如果選簽約和回款，兩個指標交叉就是一個矩陣，怎么定義好？（如下圖）

5、如果是三個指標呢？如果是四個指標呢？

以上所有問題，都有的一番糾結，才有產出。

現在簡化問題，假設就考察簽約金額。簽約金額高的就是好銷售，那么問題又來了：考察多長時間內的表現？一加入時間維度，新的糾結又開始了：

比如：

考察1個月算不算數？3個月？半年？

考察1個月，這個月好，下個月不好，到底算不算好？

考察3個月，是考察總量，平均值，還是單月達標次數？

考察6個月，穩定性好，越來越好，先好后差的，要不要作區分？（如下圖）

以上所有問題的處理，都是為了得出一個簡單的業務員分級標簽。同樣的問題，在客戶那里也存在，一模一樣的糾結。

比如評定客戶等級：

1、考察哪些指標？

2、考察多長時間？

3、指標到什么水平算好？

4、考察期波動怎么處理？

5、在未簽約前要不要做預測？咋預？

6、要不要在簽約進度中修正預測？咋修正？

都分析清楚了，才能有準確的客戶評級，特別是售前評級。

正是因為以上工作太過糾結。所以衍生出3種常見的處理辦法：

1、從簡單到復雜：先做單指標分類，再慢慢加，迭代幾次。

2、先抓典型再總結：比如先讓業務方標注幾個正樣本，然后研究他們的特點。

3、從結果倒推：比如業務方KPI是簽約額，那為了達成這個目標，得做到多少。

每一種方法都有各自的工作辦法，這里先不一一展開。只是為了讓大家感受到：為了獲取一個準確的分類，需要勞民傷財的大量工作，不然你就只能做最簡單的，充滿bug的模型。

然而，就算這樣，問題解決了嗎？

四、第二層地基

問：話術A 這個分類又是怎么來的？

實際上銷售賣東西很少只說一句話。特別是toB類銷售，前前后后得說很多東西。

這里至少有四個部分：

1、開場問候：開場寒暄，引入話題

2、產品介紹：主動介紹產品特點，優勢，對客戶的好處

3、問題答疑：針對客戶的問題，解答客戶疑惑

4、促單話術：催著客戶趕緊下單

這里又衍生出來兩個問題：

第一，  這四個部分的話術如何分類，上標簽，加入到分析之中。

第二，  如何知道銷售說了什么。

針對問題一，話術本身如何打標簽，如何分類。可以做以下動作：

1、產品介紹的版本

2、客戶問題點：功能、價格、體驗、案例、系統接口

3、促單的話術分類：按項目進度、按優惠、按資源控制

總之，有了這些扎實的基礎工作，才能有最初的話術A這一個分類標簽。這是比較好處理的。問題二，更糾結。

五、第三層地基

針對問題二，核心在于：數據怎么采集。

1、如果有SCRM系統，那么交易流程可以系統化實現，可以一定程度補足數據，比如展示了哪些案例（產品介紹環節）調用了哪些資料（問答環節）查詢了哪些優惠（促單環節）

2、如果沒有系統支持，那就只能從其他行為反推，比如銷售培訓，比如銷售策略，比如申請體驗demo類型、數量，比如申請的優惠。

那么，又衍生出：

1、銷售培訓記錄，培訓類型標簽庫

2、銷售策略記錄，策略分類標簽庫

3、申請demo記錄，申請類型標簽庫

4、價格申請記錄，產品價格折扣標簽庫

沒有這些記錄和標簽，整個銷售過程處于失控狀態，一不知道干了什么，二關聯不到工作結果。根本無法深入分析。總之，一有記錄，二有標簽，這樣分析起來才得心應手。

六、經驗小結

如果孤立地看怎么找一個好的話術，似乎在地表建筑階段，就已經做得很完美了。可實際上，如果脫離了下層大量的地基建設。再華麗的地表建筑也蓋不起來。整個流程串起來，就是用一個龐大的體系，解決了一點點業務上問題。雖然工作量大，但是它真的有效（如下圖）

注意：這套體系搭建完了，可以起個很好聽的名字，比如CST模型（Customer Success Test），配合架構圖聽起來也是很唬人的。

七、常見問題

為啥實際工作中很難做出有用的分析？本質在于：缺少基建，脫離業務。

做數據的同學，過于指望統計學、算法本身，缺少基礎業務標簽建設，缺少受業務認可的標準結果，不會推動業務去改善流程，多收集數據。

做業務的同學，忽視流程對數據的影響，不重視流程規范與數據采集。以為數據是天上掉下來的，對數據建設漫不經心，卻指望一個“來著頭騰阿公司的大神”一炮搞掂。

兩者一結合，就是盲人騎瞎馬。實際情況是：

• 基礎數據沒有
• 業務標簽沒有
• 過程數據沒有
• 預測推斷沒有

就只會拿著交易結果做交叉，然后無腦輸出：

甲行業話術A轉化率高14個點

乙行業話術B轉化率高5個點

……

當銷售部門來質疑“到底是銷售本身不行、還是話術不行、還是產品不行、還是促銷力度不夠、還是外界因素？”的時候，一個問題都答不上來。最后只會顫顫巍巍地：“我們找幾個銷售調研下？？？”

八、場景擴展

有同學可能會說：銷售過程本身數字化難度大，如果是線上交易就容易了，每一步都有數據記錄呀。是滴，線上交易是有數據記錄，是能畫出轉化漏斗，可真遇到最后轉化率不高，咋分析？

• 要不要對推廣渠道評級？
• 要不要預估各渠道響應率？
• 要不要對推廣內容打標簽？
• 要不要對CTA動作打標簽？
• 要不要對轉化產品打標簽？
• 要不要對推送客群打標簽？

這些都是同樣的基礎建設。這些東西不做，遇到最終轉化率低，運營來質疑：到底是渠道本身不行、還是文案不行、還是產品不行、還是促銷力度不夠、還是外界因素？

• 又是只會拿著渠道類型，客戶類型和轉化流程拉交叉表
• 又是只會叨叨：“因為第三步轉化率低了”。
• 又是顫顫巍巍的：“我們找個用戶調研下？”

所以呀，漏斗圖和漏斗分析是兩碼事。做漏斗圖容易，做漏斗分析，就得認認真真設計思路，做好基礎，排除雜糅因素。