CRM項目實戰(3):客戶特徵=>客戶識別 +管理

CRM更多是為提升客戶價值設計解決方案,前文提到的絕大部分內容側重於提升銷售團隊人效,我相信絕大部分公司做CRM都是從這個點切入的。更進一步便開始考慮客戶精細化運營,深入挖掘客戶價值,實現從低價值客戶到高價值客戶的轉變。

1. 客戶特徵的重要性

企業業務發展過程一般有這4個大節點:

  1. 項目啟動初期:沒有客戶時,想盡一切辦法找客戶;
  2. 吸引來客戶之後,想盡一切辦法挖掘客戶消費潛力;
  3. 盛極而衰時,想盡一切辦法維穩(或是重新獲取新客戶、或是召回老客戶、亦或是穩定高價值客戶等等);
  4. 無力回天的衰退期,開闢新業務線(又是一番輪迴,具備良好警覺性的公司,往往很早就開始探索新業務)。

不論是找客戶、挖掘客戶潛力,還是維穩,都離不開“了解客戶 ”四個字,比如找什麼樣的客戶?什麼樣的客戶有潛力可挖?什麼樣的客戶是高價值客戶?等等。

在前文中,我也提到了我們的銷售團隊習慣按照客戶意向和客戶潛在價值兩個維度綜合判斷,將客戶分成A(好)、B(一般)、C(差)三類。顯然,我們的銷售更傾向於“去找A類客戶”,這其實是“找客戶”階段的“了解客戶”。

“了解客戶”本質上就是獲取和識別客戶特徵(即先有特徵再考慮如何用)。

不同業務階段,我們想要了解的客戶特徵是不一樣的,對應有不同的管理手段/措施。

2. 客戶特徵從哪兒來

那麼,客戶特徵從哪兒來呢?

基於我所在公司業務,我抽象出了三類客戶特徵來源:

  1. 購物行為數據:指的是在主商城上客戶的購買行為數據,這塊我們做得特別淺或者說基本上沒做,前期也沒有考慮過頁面埋點的問題,所以很多客戶行為數據採集不上來,目前只能從接口請求次數等層面去做簡單分析(舉個簡單例子:某個時間段內付款請求接口調用了10次,但真正完成支付的訂單0個,我們需要去分析背後的原因,比如是系統bug?還是前端交互不流暢?等等)。
  2. 銷售數據:從銷售數據中能反映客戶對平台的貢獻值,最常見的RFM模型就是基於銷售數據進行分析,下文我將具體說一說RFM模型。
  3. 立地數據:我們的業務是基於便利店,對於零售實體店來說,立地數據實際上指的是店鋪周邊地理位置(選址:人流、商圈、客群、競對等)、店鋪內的基礎情況(店鋪面積、機器設備:比如我們發現有咖啡機、微波爐的便利店,一般資質還不錯,未來有期望帶來高額銷售利潤)。

確定了客戶特徵數據來源之後,下一步該如何做呢?

RFM模型:

對於②,定義計算規則即可。

關於RFM模型(還是基於我所在公司進行闡述):

  • R(Recency)代表客戶最近一次下單時間距離分析當天的時間間隔。
  • F(Frequency)代表統計周期內,客戶累計下單次數。
  • M(Monetary)代表統計周期內,客戶累計下單金額。

關於RFM模型其實有幾個假設:

  1. 最近交易的客戶進行再次交易的可能性更高(與最近沒進行交易的客戶比);
  2. 單位時間內,交易次數多的客戶比交易次數少的客戶,更容易再次交易;
  3. 單位時間內,累計下單金額高的客戶比累計下單金額低的客戶,更容易再次交易。

大家可以發現,RFM模型其實是基於客戶之間的銷售數據差異做劃分。另外,“可能性更高”和“更容易再次交易”,這裡的“更高”和“更容易”是和誰比較呢?這個標準到底如何設定才能讓計算更簡單呢?

我們是基於平均值進行比較。舉例M:我們取單位時間內,所有客戶累計下單金額的平均值,那麼,必然有客戶高於平均值,有客戶低於平均值,共2種情況,同理R、F也有2種情況,共8種(2^3)。

也就是說我們的RFM模型一共有8種細分客戶(實際計算后,只有6種(頭部活躍、頭部預警、腰部成長、成長初期、腰部流失、尾部流失),前文也有提到,和我們客戶自身某些屬性以及銷售的商品有關係)。

簡單說一下我們RFM模型6類客戶的特徵:

  1. 頭部活躍:最近下過單,下單頻次也高,累計下單金額也高;
  2. 頭部預警:最近未下單,歷史下單頻次高,累計下單金額也高;
  3. 腰部成長:相對於頭部活躍客戶來說,只是累計下單金額相對較低;
  4. 成長初期:最近下過單,下單頻次低,累計下單金額低,此類客戶一般是新進客戶;
  5. 腰部流失:相對於頭部預警客戶來說,只是累計下單金額相對較低;
  6. 尾部流失:最近未下單,歷史下單頻次低,累計下單金額也低,此類部分客戶可能已經徹底流失。

基於RFM模型,我們可以為不同類別客戶制定不同方案,如前文提到的為流失客戶發放“召回券”等。

立地數據:

對於③,其實有兩步:採集哪些立地數據?如何採集?(誰採集?如何保證立地數據的準確、有效性?),我簡單講下採集哪些立地數據的問題,如下圖:

CRM項目實戰(3):客戶特徵=>客戶識別 +管理

上圖隱藏了大部分細節,但是骨幹以及思路已經很明顯了。我還記得“採集立地數據”的項目立項后,自己也有過一段時間迷茫着。主要表現是自己能想到很多單一維度的立地數據字段,但明顯能感覺到大思路上沒有層次和邏輯感。

直到某個時刻的頓悟:我閉上眼睛想象一家便利店開在某個位置,從它的周邊環境、外觀、到內飾、貨架、甚至商品,在腦子裡形成了一個便利店雛形。於是,我決定先分店鋪內和店鋪外兩個大類,如此一一化解填充,最後落實到單一維度(某個字段)。

最後,就有了大家看到的這張腦圖(這是最初立項時的腦圖,這裡就不放後期更新的版本了)。目前,我們已經採集了其中部分重要字段用來做分析。

簡單總結下本節:我們的客戶特徵來源於銷售數據(基於此做RFM模型)以及立地數據,前者是通過模型計算得來,後者是通過銷售團隊採集得來。

基於這些客戶特徵,我們更新CRM的框架圖如下所示:

CRM項目實戰(3):客戶特徵=>客戶識別 +管理

上圖中,我將客戶數據集市、客戶畫像、RFM模型3個模塊加黑。我們的客戶畫像是指根據客戶的購物行為(暫時弱化的部分)、立地數據、銷售數據等信息抽象出來的標籤化客戶模型。通俗說就是給客戶打標籤,利用這些高度概括的標籤(客戶特徵)來描述客戶,基於這些標籤做數據分析。從某種意義上來說,RFM模型中抽象出來的6種客戶類型,是客戶畫像中的標籤之一。

立地數據的應用之一:

立地數據是便利店行業很重要的數據之一,特別是選址相關的數據。很多好的地段躺着都能掙錢,當然這些地段不僅僅只是租金不菲而已(比如寫字樓內部的便利店)。

那麼,立地數據有什麼其他典型的應用么?比如接下來要說的銷量預測。

第一篇講了一些我所在公司的業務模式,當商品部同事決定上新品時,往往需要經過漫長的市場調研,其中有一個環節就是銷量預測。初期,只有知道商品的期望銷售額之後,才能決定分配多少資源去運作。

銷量預測的一種途徑是基於便利店所在商圈類型(寫字樓、社區、交通樞紐、學區等)預測新品銷量,比如包子這種強早餐屬性的商品,在寫字樓銷量是最好的。於是,下一步我們找出這些寫字樓店就可以了。

基礎邏輯實際上就是:包子銷量預測 = 類型店(寫字樓、學區……)數量*同類型競品店包子銷量(這個數據是基於初期市場調研的結果)。

稍微延伸一下,這個環節還可以繼續滲透,比如我們可以在新品上線后,通知到所有銷售,讓他們去拜訪適合包子銷售的類型店,將新商品推薦給客戶,整個商品上新的過程就形成閉環了。

基於客戶畫像做銷量預測,更新的CRM框架圖如下所示:

CRM項目實戰(3):客戶特徵=>客戶識別 +管理

3. 識別客戶+管理

客戶特徵應用實際上就是識別客戶+管理客戶的過程。

之前提到管理是一種手段,基礎邏輯就是:對客戶特徵進行分析后,發現需要對客戶採取某種措施,促使其下單,否則這類客戶會慢慢沉默直至流失。

關於客戶特徵分析,我簡單舉三個案例,結合具體案例的話,希望大家能體會得更深一點。

案例1:當我們的業務發展到一定階段,GMV增幅開始變得平緩時,需要找到新的銷售增長點。

那麼,怎麼去找呢?本質上思路應該是挖掘高價值客戶,如果沒有這麼多高價值客戶怎麼辦呢?於是,我們有了為便利店賦能的方案,即改造資質還不錯的便利店(改造的目的是擴品,提升店鋪內空間利用效率)。

所以,我們遇到的問題其實是:什麼叫做資質還不錯的便利店?如何尋找資質還不錯的店?

這個時候客戶特徵就起作用了,我們基於客戶銷售數據和立地數據特徵,很快從幾萬家存量店鋪中,篩選出目標便利店,然後以任務形式派發給負責這些便利店的銷售,改造便利店的項目流程隨即進入與客戶洽談合作的階段。如果沒有客戶特徵數據,短時間內,我們很難在幾萬家便利店中挑選出合適的店鋪來。

案例1,想說的是任務管理模塊(任務管理還有很多其他的應用場景),我更新CRM框架圖如下:

CRM項目實戰(3):客戶特徵=>客戶識別 +管理

案例2:銷售地推團隊,在做客戶新簽的時候有奇效,因為他們執行力很強,一旦涉及到後期客戶深度運營,往往倍感吃力。

所以,當我們將銷售全部轉為客戶運營后,曾一度懷疑這個階段的銷售團隊是否有存在的必要?他們的拜訪是否有效果?(此時此刻,這個問題我依舊沒有結論。我曾經利用相關性分析,確保有95%以上的把握證明銷售數據增長與銷售拜訪有關係,但現實情況和數據分析的結果真的一致么?)

為了驗證這個問題,我們將一部分流失客戶激活的工作交給了callcenter,嚴格意義上來說,我們的callcenter有兩個作用,一個是處理售後服務,另一個就是做線上的銷售。

線上銷售的工作內容,比如客戶調研、新簽客戶回訪、流失客戶召回等等,最後發現callcenter也能帶來2%左右的GMV增長。儘管如此,我們的銷售團隊還是存在着,如果深入一線陪訪能發現,線下銷售團隊和客戶的關係不是客服團隊能夠替代的。

客服是特別依賴客戶特徵信息的團隊,因為他們坐在辦公室,沒有機會與客戶當面接觸,所以只能通過乾巴巴的數據特徵決定要去回訪哪些客戶。

案例2,想說的是callcenter模塊,我更新CRM框架圖如下:

CRM項目實戰(3):客戶特徵=>客戶識別 +管理

案例3:便利店行業,特別是北京的夫妻老婆店,這類客戶對價格特別敏感,並且北京市場上存在着大量二批商、批發市場,這些地方商品採購價格低,相對於運營模式重的我們來說,有很大優勢。我們如果要掙20個點才能做到盈虧平衡,也許這些二批商掙5個點就盈利了。

舉個實際的例子:有一個客戶每天要賣1500個包子,我們只要一個包子貴1毛,客戶立馬流失(一個月貴多少?30天*1500個*1毛=4500塊),轉投二批商。

運營模式重的因,帶來了商品高毛利運作的果。想將運營成本轉嫁給毫釐必爭的便利店老闆,明顯是很難成功的。那麼,該怎麼辦呢?於是,精準營銷的概念就被提出來了。

精準營銷說的是放棄落後的廣撒網模式,將優惠補貼給最恰當的客戶。用人話說就是,A客戶不需要優惠也會自然下單,B客戶因為價格因素不願意下單,我們可以用定向補貼的形式給B客戶優惠,彌補與市場價格的差異,促使B客戶重新在我們這下單。

怎麼理解精準營銷(定向補貼)的作用呢?

假設同樣是2萬的營銷費用預算,廣撒網的模式下,可能會把其中5千補貼給自然下單的客戶,精準營銷的目標就是將2萬用在最恰當的潛在高價值客戶身上(最恰當:潛在高價值、價格原因離開平台)。

當然,作用還不僅僅如此,比如提高客戶粘性,我們發現通過定向補貼,客戶往往還會購買除補貼商品之外的商品,這也是我之前提到的一站式購物體驗(二批商一般運營品類狹窄,僅僅只是某些單品價格有優勢,無法滿足客戶多品且價優的需求)。

案例3,想說的是營銷管理模塊(該模塊場景也有很多,就不一一贅述),我更新CRM框架圖如下:

CRM項目實戰(3):客戶特徵=>客戶識別 +管理

最後,大家發現還有異常監控模塊沒有被加黑,所謂異常是和正常相對的概念。零售行業的銷售規律一般是以“周”為單位,所以我們數據監控一般是做周維度的同比監控,比如:本周一同比上周一的銷售數據,一旦發現同比數據差異較大,我們需要及時找到原因。舉個簡單的例子:臨近寒暑假期間,我們會發現銷售數據突然下降,最後調查原因是學校放假,便利店暫時歇業。

多說一點,基於我們的便利店業務,周一至周四加周天數據相對較高,但周五開始下降,周六最低。原因很簡單,我們的高價值客戶一般是寫字樓店,寫字樓店一般在周六、周日消費能力下降。

有讀者會問了,那為什麼銷售數據周五開始下降,周六最低?

原因就在配送時效上,我們的配送時效是次日達,今天買,明天送(目前是今晚八點前下單,第二天上午9點前送達,配送能力是我們的一大核心競爭力)。周五、周六分別採購周六、周日的訂單,所以才造成了周五、六銷售數據下降。

異常監控模塊,實際上就是在做這些銷售數據上的異常監控,讓我們把控一線市場的動態,及時發現問題(比如商品售罄、商品質量下滑、客戶被切走等導致的訂單量下滑)。

關於異常監控模塊,我更新CRM框架圖如下:

CRM項目實戰(3):客戶特徵=>客戶識別 +管理

以上是關於CRM的全部內容,到這裡也算是暫時結束了,我還一直在做CRM這方面的工作,估計過幾個月自己又會有新的認知(就和我之前做的權限系統一樣,寫完文章幾個月,又有了新的認知)。

相關閱讀

CRM項目實戰(二):獲取客戶篇

CRM項目實戰(一):概念和業務篇

#專欄作家#

QJQ,微信公眾號:倔牛的人生,人人都是產品經理專欄作家。關注電商/CRM/新零售/便利店。

本文原創發佈於人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基於CC0協議

本文由 PMBear 作者:小熊爸爸 发表,其版权均为 PMBear 所有,文章内容系作者个人观点,不代表 PMBear 对观点赞同或支持。如需转载,请注明文章来源。

发表评论