SaaS產品推廣獲客：單兵作戰 vs 叢集作戰

今天聊聊SaaS產品如何實現規模化快速推廣這個話題，結合我們自己做HR SaaS平臺兩年多的實戰閱歷，分享從坑裡爬起來的經驗。

目前看全球市場，SaaS產品的獲客方式大同小異，各廠商們根據業務發展策略，優先選擇轉化率高的方式。類比軍事史上的“單兵作戰”與“叢集協同作戰”，極限追求投入產出比的閾值。

01 單兵作戰的關鍵是標杆效應

瞭解戰爭史的小夥伴一定知道，單兵作戰和叢集協同作戰在多次經典戰役中都有出現，它們是兩種風格迥異的打法，隨著戰爭進入不同階段而被指揮官靈活運用。

服務B端的SaaS產品比 to C的產品推廣起來要更復雜，起量更慢，幾乎不可能出現一夜之間指數級暴增。潛水待過多個產品社群，談到增長話題，B端產品經理們都比較含蓄，也知道不可能像C端產品那樣，可以風光無兩的爆料“經過策劃裂變活動，使用者量增長了數百萬”。B端平臺的客戶是一家一家拿下的，不是一群一群拿下的。

在HR SaaS這個賽道，目前頭部的北森、大易、Moka獲客的主要方式是透過KA（大客戶經理）去拜訪企業客戶，重點篩選行業中具備知名度的名企，透過服務知名企業樹立標杆形象，然後藉助標杆效應帶來的信任背書去降低同行業其他客戶的銷售成本。

在2013年以前，北森以服務中小企業為主，中小企業市場體量大，選擇這個客群是理所當然的。但是真正讓北森得以飛速發展的是2013年後轉向服務大企業客戶，中小企業存活的週期短，穩定性低，產品的研發成本無法以邊際遞減攤開。考慮到資料上雲的需求與付費的穩定性，北森轉向服務大企業客戶是聰明的決策。

企業服務市場SaaS業務的發展模式，大家參照的標的還是歐美企業服務市場。在認知上，美國的企業服務市場是成熟的，客戶們對於流程和軟體的認知很清晰，客戶內部也有專業懂軟體的工程師，作為廠商進入市場的難度較低，而我們國內對於SaaS的認知還處於初級階段，廠商的教育和服務成本很高。

在客戶需求上，美國的SaaS產品做的很細分，廠商只需要把單點產品做深入即可，客戶其他的需求有其他廠商的產品去滿足，但在國內客戶的需求很複雜，廠商們肯定是以客戶為中心。

比如我們做HR SaaS，客戶說我們看不到資料、報表，我們就要做資料看板、BI，有更為複雜的需求我們可能還需要做平臺，串聯起人事管理過程的上下游環節，這導致軟體開發的成本很高。

中小企業客戶很難承受這種高昂的客單價，所以國內SaaS廠商們現在的業務走兩條不同的發展路線，先做大企業的PaaS，然後提煉高頻的應用場景，面向市場推出標準版的應用，可以普遍適用於行業的中小微企業客戶。還有一種是直接做垂直應用，選擇全流程外的核心環節，單點突破，這種模式是可以透過參考 to C產品線上推廣方式來推入市場。

02 叢集作戰，考驗團隊對流量的數字化、精細化運營

只有提供最優質的服務，給客戶提供最好的價值，才能長期發展。前面說到北森做小微還是中大客戶，其實都會涉及到一個問題，就是產品跟市場的契合點到底高不高。

企業服務市場早期大家都去做小微，是因為小微對產品的需求簡單，但依然不能實現持續發展，我們做推才蛙時也深有感觸，每天線上新增的企業客戶超過數百，小微偏多，付費轉化的難度高，同時也無法持續鋪開。

因此除了產品契合市場，市場本身是否OK也很重要，好市場裡生意才能實現規模增長。對我們這些應用級的公司來講，怎麼建一個可規模、可複製的增長體系變得特別重要。

剛開始做推才蛙時，我們打算透過資訊紅利取巧，把市面上能夠找到的有關SaaS產品推廣的一手資料、二手資料全部收集回來，在內部做了一次推廣方式盤點，以需求評審的方式一個個拍板過會。最後得出的結論是市面上的可被搜尋到的資料，實戰參考價值低，關於SaaS產品的推廣大部分還停留在解釋SaaS產品本身或運營上，有文不對題之嫌。

比如銷售管理軟體CRM系統，我們常有一個認知誤區，就是認為購買後只要給到銷售團隊用，就能大幅度提升公司業績，這是一個很淺層次的看法。正確的看法是在打造銷售體系和團隊的時候，應該先將流程、體系整個梳理建設完畢，而後再透過應用工具與其相輔相成。

也就是說，具有成熟管理體系後，銷售人員招募上來上手週期縮得很短，複製性很強，整體業績一定可以大幅度上升。所以在推廣CRM系統時，我們需要定位清晰，能夠給客戶帶來的價值是什麼，如何在宣傳中凸顯這部分關鍵資訊，而不是讓客戶產生誤解，期望值太高被落空棄用產品，第二年就失去訂閱續費的動力了。

協同叢集作戰是建議SaaS產品推廣時，不要只依賴一種獲客方式。我們經常把Maketing透過打電話、做PR等方式獲客比喻成“空軍的力量”，那麼對應的，地面部隊就是銷售部門。

當然，每個企業的形態不一樣，在這方面投放的資源也不太一樣，但二者能否完美配合，成為一支強大的戰隊，是贏下競爭對手的關鍵。所以，這兩個我不認為應該被割裂開來，而應該相輔相成的去做。

03 我們關注十組獲客指標，強調轉化效果

我們在獲客推廣時，會整體劃分成內部和外部兩條線涉及到三個部門的核心指標。關注的外部指標有六個，分別是自然流入註冊量、有效線索量、線索轉化率和渠道投資回報率（ROI）、病毒係數（口碑傳播）、客戶流失率。

註冊量很常規，比PV/UV價值高，我們作為第一層關注的漏斗。對於可試用/體驗的企業級 SaaS 而言，註冊量可能是最重要的指標。無論是透過活動、內容還是搜尋引擎最佳化，我們的目標都應該是增加註冊量。

在理想狀態下，使用者能夠自己學習產品，定期使用，並在其中找到足夠的價值，來轉化為付費客戶。增加註冊量主要有兩大方向，一是擴大流量來源；二是提高註冊轉化率。

有效線索可分為MQL（M是市場驗證的線索）、SQL（S是銷售驗證的線索）、PQL（P是產品驗證的線索），使用PQL更常見，我們會重點關注PQL是因為它意味著使用者使用產品已達到預期效果，下一步是接近付費轉化的潛在客群。PQL指標體現在使用功能頻次、停留時長與使用功能數量。

線索轉化率可以透過漏斗模型來呈現，但要注意不同的是使用者分群可能導致轉化率不同，不要統一概述，它能直接影響銷售收入。

ROI是廣告渠道投放的投入產出比衡量。渠道可以分為自然流量渠道（像自有媒體）和付費流量渠道（像SEM）。作為市場或者運營，我們可以透過不同渠道帶來的流量、註冊量、成交客戶數及成交客戶金額等指標，去衡量每個渠道的 ROI。

我們產品使用者主要是企業HR，在線上和線上投放廣告肯定要做，但是作為初創公司，一定不可能鋪天蓋地的廣告投放，怎麼智取是值得研究話題，廣而告之是財大氣粗時的做法，沒錢沒預算時，我們只能從精準上進行突破。

運營團隊剛開始試水了很多新媒體平臺，最終經過一段時間的試驗，選定在知乎、人力資源論壇/貼吧、百度問答搭建了內容輸出體系，依靠線上的高質量內容引流，保證了每天的平臺註冊量從0到數百的增長，這是一個好的開始，包括後來我們孵化的另一款產品藍領送工也有從這條渠道中持續獲取有效線索。

口碑營銷（病毒係數）是不敗之師，如果現有的客戶能幫助我們獲客，增長將是成倍計算的。

早期的 Dropbox、Slack 等公司，它們的快速發展都離不開使用者間的傳播。可以說，病毒式傳播是每個企業級 SaaS 初創公司的夢想，但這也依賴於產品形態。聯絡到第一部分單兵作戰，透過標杆客戶建立口碑效應，也是參考了這種做法。

客戶流失率一般每年保持在 5-7%為正常水平。服務中小微企業客戶的 SaaS 公司可能會有更高的客戶流失率。

但面向大型企業的 SaaS 公司應該追求更低的、甚至是負的客戶流失率。比如：

• 推薦客戶購買增值服務
• 幫助客戶實現增長，促使升級更高級別服務
• 等等……

如果一家公司每月的客戶流失率是 5％，但其餘 95％ 的客戶在產品方面都是成功的，甚至購買了附加服務並增加了 5％ 的收入，那麼本月收入將是上個月的 110％ 。

達成外部指標是為了配合內部的轉化，一切的目的都是為了實現產品的增長推廣，以致為公司帶來健康可持續的營收及利潤。內部我們關注四組指標，分別是線索生成速率、活躍使用者量、淨推薦值和續費率。

為什麼要提到LVR 呢？因為轉化一定比例的 PQL（或 SQL 等） 只是時間問題，LVR 可以很好地預測未來的銷售業績。

我們知道線索轉化率後，根據營收目標反向推算所需線索的數量，這個數字可能不太現實。如果線索質量保持不變，就可以使用平均銷售週期來預測未來幾個月的新銷售收入。

舉個例子，假設本月建立了 1100 個線索，上個月建立了 1000 個合格線索，LVR 就是以每月 10％ 的速度在增長。

活躍使用者量和淨推薦值是常規指標，透過衡量使用者的滿意度和忠誠度，來評估產品是否健康。

一般來說，面向中小企業，客單價低，廠商應該關注客戶續約率，也就是續約的企業數量；面向中大企業，客單價較高的，廠商更應該關注金額續費率，也就是續費的金額大小。

為了長遠的發展，SaaS 企業都應該最多隻按 1 年去續費。

上面說了這麼多，並不是成功經驗分享，我們自己產品的推廣增長之路仍然處於一個摸索階段，談不上有多成功，只是略有成效，希望能和小夥伴們多多交流經驗，一起推動這個話題被更多關注，得到更多解決方案，降低損耗。

創業初期，能夠調動的資源有限，一定要聚焦單點突破，想清楚要做什麼，不做什麼。戰略兩字，拆開“戰”是指做什麼，“略”是指不做什麼，全部都做那是巨頭才能乾的事。

長假第二天，在外碼完字，形成條件反射了，作業要按時交，錯過一次那肯定會有下一次，人性充滿懶惰。國慶快樂，結尾推薦美劇·絕命毒師中出現的配樂，畫面里老白推著一桶錢在西部的荒漠上往前走，口哨聲環繞左右，Limeliters – Times are Getting Hard~

作者：大井蓋先生，前某廠PM總監，現創業公司CEO；公眾號：八點四十

本文由 @大井蓋先生 原創釋出於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。