如何評估SaaS公司的經營狀況？本文作者將自己的整個指標體系梳理了一遍，并給出評價標準參考值。enjoy~

#SaaS創業路線圖#系列的第2篇提到，SaaS企業在下圖的“效率”階段需要建立指標體系。路線圖系列到今天已經連續寫了整整12個月了，過程中我又見了160多個SaaS公司，并通過咨詢服務深度參與了幾家公司的經營決策。

今天筆者就把這個指標體系完整描述一下，并給出評價標準參考值。

一、評價公司整體經營

除了公司會計中的常見財務指標（主要在資產負債表、現金流量表、損益表里），SaaS公司也很關注LTV（客戶生命周期價值）和CAC（客戶獲取成本）等行業指標。

我之前提出過，這些都是反映到財務數據上的“最終結果”。作為創業期的管理團隊，我更看重能快速迭代的日常業務過程指標，遂成此文。

二、評價產品

評估一個SaaS產品研發效率、效果的好壞，有很多指標可以用，我只推薦3個能通用的：

（1）服務可用率

我們可以算一下，如果一個月中服務宕機了1次，時長15分鐘（這對很多在線產品已經是非常糟糕了），該月的“服務可用率”為：1 – (15分鐘÷(30天 * 24小時/天 * 60分鐘/小時)) = 99.965%。

早期產品可用率可以略低一些，因為這要與版本迭代速度平衡好。進入擴張期后，客戶數量已經較大，宕機影響非常負面，“服務可用率”應該設法做到4個9（99.99%），大致相當于全年只能有3次15分鐘左右的服務宕機。

客戶服務的核心思想是“分類分級”。從研發側考慮，也可以把少量重點客戶與大量普通客戶分開部署在不同設備上，減少發生災難影響范圍。

（2）模塊用后留存率

SaaS與傳統軟件的本質區別是續費。SaaS公司應該以留存客戶為主要目的，而不需要與傳統軟件公司一樣不斷上新功能以期再次銷售新版本給客戶，所以我們應該在開發一個新模塊的決策上更加謹慎。

那么如何衡量新模塊上線后的效果呢？有一個很聰明的指標，就是“模塊用后留存率”。

意思是，1000個企業用到這個模塊（可能是產品中的自然引導，也可能是市場部的內容引導或CSM的人工引導），1個月后還繼續使用的比率有多少？

這里的邏輯是：產品和研發不對進入的流量負責，但要多試用后的留存率負責。

（3）開發過程Bug比率

12年前我在華為時，看研發部門用的是“千行代碼Bug率”指標。這2年我看這個指標演化為：版本開發過程中bug數 ÷ 版本開發人月，還有測試部門的“漏測率”等。這些我不往里深挖了，每家企業根據自己的情況選擇。

三、評價市場

我這一年見過的SaaS公司，在“客戶來源”上基本都在兩個極端，要么是成交客戶中80%以上來自市場線索，要么是80%以上來自業務員自開拓，能做到兩者平衡（各占50%左右）的SaaS公司不到5%。

也有一些CEO跟我說這是“產品性質的原因”，但回過頭來又看到有些區域自開拓的比例很高……

我當然不能在這里下結論說“SaaS公司應該讓開源方式均衡”。但起碼可以說，“過度依賴一種開源方式是不利公司發展的”。

（1）成交客戶中來自市場線索的比例

如果要給個建議參考值，我認為要努力做到30%以上。有的SaaS公司太依賴業務員自開拓，而荒廢了市場能力，這是很可惜的。

（2）各線索通道的“線索有效比例”

我理解由于組織能力和IT系統的原因，很多SaaS公司還難以做到Leads to Cash的完整跟蹤。上個月與一個知名SaaS Marketing Tool的創始人聊天，我們估算大概只有不到30%的SaaS企業能夠把這個數字算準確。

這其實很關鍵，筆者建議進入公司擴張期后，要去找找合適的CRM+ Marketing工具，并提升組織的流程能力，真正解決這個問題。

除了分開“自開拓”與“市場線索”，市場線索中還要分“線下活動”、“自然流量”、“百度SEM流量”、“360SEM流量”，到底哪些投入產出比更大呢？如果尚未解決L2C的問題，至少可以看看銷售的統計數字—— 哪邊來的“線索有效率”更高？

（3）自然流量線索的比率

這個可以衡量品牌和口碑的積累情況。完全不做品牌，會造成長期依賴百度投放，除了成本高昂，業績的天花板也會很低。

當然，不同產品這個指標差別很大，一般來說我認為目標應該定在10%以上。

（4）SDR線索分類分級準確率

SDR團隊不負責成交，只負責初次聯絡客戶，確定客戶需求有效性并進行線索的分類分級。不同級別、不同行業的線索，交給不同級別、不同行業特性的業務員，將能夠大幅提高線索轉化率。

如果有SDR團隊（一般建議放在市場部里），對SDR的嚴格管理將非常重要。一旦SDR出現效率低下或道德風險問題，對公司整體業績都有巨大影響。

因此建議設置QA崗，或SDR負責人兼任，通過抽查電話錄音加強日常檢查，并關注這個準確率指標。

四、評價銷售體系

初次見到一位SaaS創始人，我不會問LTV/CAC的數字，那些太抽象，而且數字往往是最近尚未更新的。我會首先問先這些問題：

（1）平均客單價與平均成交周期

一般來說，兩者有很緊密的關系。

我和這么多SaaS團隊聊過，總結大體情況如下，大家可以對比一下自己公司的數字：

1. 4萬以下客單價，應該在初次接觸客戶后30天內完成首個簽約付款；
2. 4~10萬客單價，應該在初次接觸客戶后45~60天內完成首個簽約付款；
3. 10~20萬客單價，應該在初次接觸客戶后45~90天內完成首個簽約付款。

再往上就不太好講了，成交周期當然是越短越好。

按我的價值觀，以上客單價指的是客戶一年服務費用，不是一次收多年服務費的合同金額，但可以包括一年內的增購、擴容收入。

（2）營銷費率

營銷費率 = 銷售、市場的費用之和 ÷ 銷售收入。

這個公式的分子與CAC的分子一致。國內SaaS企業的營銷費率大多在60~90%之間。理論上這個指標越低毛利越高，但也要考慮營銷體系發展速度的問題，希望更快速度發展，成本（例如招募、培養新人的損耗）就會高一些。

這個數字由于也需要進行大量財務核算，在日常管理中也不容易獲得。更好用的指標是這個：

（3）人效（銷售部門全員人均月單產）

人效指標與客單價及銷售組織方式有很大關聯。比方說，低客單價產品，要求盡量少的人參與；客單價高的產品，就能夠支撐更多人參與：前期需要SDR篩線索、中間需要售前技術支持……我畫張表說明：

（電銷：通過電話和線上互動完成銷售過程；面銷：以上門拜訪為主的銷售方式。）

原則上是電銷能解決問題的，盡量不用面銷。除了管理難度小很多，電銷的優勢是能夠輕易覆蓋全國，就不用設置那么多分支結構和開發代理商了，成本會大大減少。

當然，每家產品及市場情況有差異（特別是開源方式不同），上面這些目標數字會各有不同。

（4）各線索通道的線索轉化率

在L2C的過程中，市場部負責前半段（對有效線索數量負責），銷售部門負責后半段（對有效線索轉化回款負責）。如果爭議很多，建議設置SDR部門對線索進行分類分級。

五、評價服務

CSM（客戶成功部）是SaaS公司最重要的部門。還是那句話，SaaS的本質是續費，沒有CSM的續費，SaaS商業模式不會成立。

（1）續費率

包括客戶（數量）續費率和收入（金額）續費率。大部分公司會看重收入續費率，但我認為要根據情況判斷：如果咱們是聚焦中小企業市場的，客戶續費率也非常重要，不能用幾單大客戶的續費沖淡了大量中小客戶流失的影響。

對于續費率低的SaaS公司，應通過客戶分類，找到自己的目標客戶群體（很可能就是續費率高的那一類客戶），并為這個目標市場不斷改變產品和服務，以期提高未來的續費率。

（2）流失率（ = 1 – 續費率）

公式很簡單，內涵卻不同。SaaS公司應該在分類分級后，針對不同類型的客戶進行流失分析。

（3）新交付客戶本月活躍率

續費畢竟要一年后才發生，創業公司早期要加快CSM部門能力迭代速度，就得早日發現問題。因此可以多關注：上個月已付費、并已完成實施或簡單培訓的客戶在本月的活躍情況。

（4）CSM（客戶成功經理）平均服務客戶待續費金額

CSM不是客服熱線（被動應答），而是一個需要根據運營系統預警或主動發現客戶異常，及早主動聯絡客戶、推動更深度使用產品的。如果一個CSM服務太多客戶，那就做不到主動服務了。

不同產品需要的主動服務強度不同，客戶規模也有很大影響，所以很難一概而論一個CSM應該服務多少客戶。

我把這個數量指標轉換了一下：一個CSM服務的x個客戶，一年待續費的總金額是多少呢？這個指標就穩定不少，我推算無論服務對象是大企業還是中小企業，應該在200~500萬之間比較合適。

（5）凈推薦值NPS

NPS = (推薦者數/總樣本數)×100%－(貶損者數/總樣本數)×100%

這是一個簡單高效的客戶滿意度調查，只問一個問題：你有多大可能性將我們的產品推薦給朋友或同事（0~10分）？

9~10分為推薦者；7~8分為被動者（滿意但不忠誠）；0~6分為貶損者。

國內SaaS領域尚缺乏公開準確的NPS數據，我只能給出10%~30%作為參考目標，當然是越高越好。順便說一下，NPS這個指標其實是公司級指標，不是CSM一個部門能夠承擔的。

六、總結

最后我還是列一張表，讓大家可以一目了然看到評估SaaS公司各個部門的關鍵指標是什么。

SaaS公司評價指標及參考標準：

你所在的公司還用了哪些有特色的指標？歡迎留言交流。

相關文章

SaaS創業路線圖（47）：從管理會計看SaaS企業經營的真相

#特邀作者#

吳昊，微信公眾號：SaaS白夜行，紛享銷客天使投資人、前執行總裁。20年企業信息化和6年SaaS營銷團隊創新經驗，每天一篇2000字SaaS創業文章的堅持者，目前正處在從創業者向投資人的轉型過程中。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議