← 全部概念地圖
標準

概念地圖・SaaS 40 法則

分類:創業

這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖,加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你,以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →

40 法則:成長加獲利,夠不夠 40

訂閱制公司常年活在一個兩難裡:多花錢衝成長,利潤就難看;把成本壓下來,成長就慢下來。投資人看報表時很難判斷哪一種比較健康。40 法則用一個粗暴到令人安心的做法處理這件事——把年營收成長率跟利潤率直接相加,看加起來有沒有到四十。成長六成、虧損兩成,算七十分;成長一成、賺三成,算四十分;兩邊都平庸的公司,這個加法會立刻讓它現形。

40 法則:成長率與利潤率的對角線分界 橫軸為利潤率、縱軸為營收成長率,一條由左上到右下的對角線代表兩者相加等於四十。線的右上方為達標區,左下方為未達標區,圖上以泡泡標出高成長燒錢、均衡、成熟高獲利、燒錢又不長與停滯五種典型位置。 兩邊都平庸的公司,這條線會讓它現形 達標區 怎麼組合都可以 成長率 + 利潤率 = 40 未達標區 兩邊都不夠 高成長燒錢 70 +(-25)= 45 均衡 35 + 10 = 45 成熟高獲利 12 + 30 = 42 燒錢又不長 25 +(-20)= 5 停滯 8 + 15 = 23 0 20% 40% 60% 80% 營收成長率 -40% -20% 0 20% 40% 利潤率(多以 EBITDA 或自由現金流計)→ 泡泡為示意公司;同一家公司換一個利潤定義,位置就會左右平移
線上的每一點都算及格,差別只在你選擇用哪一種方式及格

四種組合,四種完全不同的公司

這條法則沒有學術出處,它是創投圈在二〇一五年前後流傳開來的實務準則,Brad Feld 與 Fred Wilson 等人寫過之後迅速變成 SaaS 圈的通用語言。它之所以站得住,是因為訂閱制的高毛利與可預測續訂,讓「成長」與「獲利」在財務上真的具有某種可互換性——今天多花的行銷費,換來的是明年會自動續約的營收。

組合典型長相投資人的第一個問題最大風險
高成長、深虧損成長 70%、利潤 −25%錢燒完前追得上嗎?融資窗口關掉
中成長、微利成長 35%、利潤 10%成長還撐得住幾年?成長率逐年遞減
低成長、高獲利成長 12%、利潤 30%還有新客戶嗎?被新進者慢慢侵蝕
兩邊都不到成長 8%、利潤 15%這門生意還在成長嗎?估值直接換一套邏輯

套進去之前,先確定四個數字的定義

這個加法本身沒有技術難度,所有的爭議都發生在「你把哪兩個數字放進去」。

一、成長率算的是哪一種營收。年度經常性收入(ARR)、會計認列的營收、含一次性導入費的總收入,三個數字可以差很多。導入費高的公司用總收入算,會把成長率灌得漂亮,但那部分明年不會自動出現。自問:這個成長率裡面,有幾成是明年不必再賣一次的?

二、利潤率用的是哪一條線。最常見的是 EBITDA 利潤率,也有人用自由現金流或營業利益。差別很實際:把研發資本化、把股權獎酬排除在外,都能讓同一家公司的分數多好幾分。自問:我這個利潤率,有沒有把付給員工的股票算成成本?

三、你的成長是買來的還是長出來的。把行銷預算加倍就能把成長率推高,代價是利潤率同步下滑——在 40 法則的加法裡,這兩件事會互相抵銷,總分看起來沒變。要判斷這筆錢花得值不值,得看客戶取得成本要多久回收,那不在這條公式裡。自問:這一塊錢的行銷費,幾個月會回本?

四、公司規模到了嗎。年營收兩千萬的公司,成長 200% 是常態,加起來輕鬆破百,那個分數不代表任何事。這條法則在營收規模到一定水準(實務上常說一千萬美元 ARR 以上)之後才有鑑別度。自問:我的成長率高,會不會只是因為分母很小?

一家台灣排班軟體公司的三年

以下是一個示意情境,用來說明這條線怎麼改變一次內部爭論。

實例演練
  • 第一年:ARR 1,800 萬,成長 95%,利潤率 −40%。合計 55
  • 第二年:ARR 3,200 萬,成長 78%,利潤率 −28%。合計 50
  • 第三年:ARR 4,600 萬,成長 44%,利潤率 −22%。合計 22
  • 內部的說法:市場變難,再加一組業務就追得回來。要再燒
  • 攤開來看:新客成長掉一半,續約率卻沒有變差。留下來的人很滿意
  • 真正的改動:業務團隊不增編,改把導入流程從六週壓到十天。分子分母一起動

第三年那個 22 分,讓一場開了兩個月的爭論結束得很快。原本的方案是再招五個業務、把成長率推回六成,代價是利潤率再掉十個百分點——加起來仍然只有二十幾分,等於花掉一整年的現金去換一個沒有變好的分數。真正卡住的地方在別的地方:這套系統平均要六週才導得完,導入期間需要一位工程師陪著客戶,這件事同時壓著成長(客戶排隊)與利潤(人力綁住)。把導入時間壓到十天之後,同樣的團隊一年可以多接近三倍的客戶,而且不必多請人。第四年的數字是成長 61%、利潤率 −11%,合計 50。這家公司沒有選成長或選獲利,它找到了那個同時決定兩者的瓶頸——而那個瓶頸,永遠不會出現在這條加法公式裡。以上為說明結構用的示意情境,僅供理解框架之用。

這條線最容易被玩壞的三種方式

好用的單一指標都會遇到同一個命運:被拿來當目標之後,數字會先變好看,公司再慢慢變差。

  1. 加法讓兩個弱項互相掩護。成長 20% 加利潤 20% 得到 40 分,跟成長 60% 加虧損 20% 同樣得到 40 分,投資人對這兩家公司的估值倍數卻可能差上一倍。原因是這兩種分數的可逆性不同:一家高獲利低成長的公司,很難靠花錢重新變成高成長;一家高成長的公司,通常隨時可以踩煞車把利潤變出來。分數相同,選擇權的多寡差很遠。
  2. 單期指標最容易被會計選擇打扮。把一次性授權收入認列在今年、把研發支出資本化、調整股權獎酬的處理方式,都能在不改變任何營運事實的前提下讓分數上升。反過來說,一家為了併購而列了大筆一次性費用的公司,分數會莫名其妙難看一年。看這條線一定要連看三年,並且盯住定義有沒有換過。單一年度的 40 分,資訊量比想像中低。
  3. 它是為訂閱制訂做的,換一種生意會誤導。這條法則預設高毛利、營收具高度重複性、成長投資在明年會自動變成收入。專案型的軟體公司、硬體公司、低毛利的電商,這幾個前提都不成立——它們的成長需要同步押進存貨與人力,成長與利潤之間並不存在那種乾淨的互換關係。硬套的結果,往往是把一家健康的低成長公司判成失敗,或把一家靠補貼衝量的公司捧成明星。

四十分算得出來,續約的理由算不出來

痛點視角

這條線的位置全部由兩個結果決定:客戶增加得多快、你手上留下多少錢。兩個都是結果,而結果的上游只有一件事——那些客戶每年續約時,心裡想的是什麼。

那家排班軟體公司的轉折點很能說明問題。他們的分數掉下來,第一反應是「業務不夠多」,因為那是唯一直接對應到成長率的旋鈕。真正的原因躲在導入流程裡,而那件事之所以被忽略,是因為它同時不屬於業務也不屬於財務,沒有任何一個 KPI 在盯它。能同時把兩個數字推上去的,通常是同一個沒被解掉的痛。P.A.I.N. 之尺問的正是這一層:客戶最痛的是哪一段、他為了忍受那一段付出了什麼、你把那一段拿掉之後他願意多付多少。這幾個答案沒有一個會出現在財務報表上,卻決定了報表最後長什麼樣。今晚可以做的一件小事:找出你上一季流失的那幾個客戶,看他們是在合作的第幾個月走的。如果集中在前三個月,你的成長問題其實是一個交付問題。

關於 40 法則,常被問到的幾件事

40 法則的公式是什麼?

年營收成長率(百分比)加上利潤率(百分比),合計大於或等於 40 即為達標。例如成長 30%、EBITDA 利潤率 12%,合計 42 分過關;成長 15%、利潤率 10%,合計 25 分未達標。虧損以負數帶入。利潤率的定義沒有統一標準,EBITDA 最常見,也有人用自由現金流率,重點是同一家公司前後年度要用同一套定義。

為什麼是 40,不是 30 或 50?

這個數字沒有理論推導,是創投圈從一批表現優異的 SaaS 公司身上歸納出來的經驗值,屬於好記的門檻而非科學常數。實務上大家也會依市場環境調整:資金寬鬆時投資人更看重成長,門檻實質上被放寬;利率高、市場收緊時,同樣的 40 分,獲利那一半會被看得比較重。把它當成一條參考線比較安全,當成及格線會失真。

早期新創適用嗎?

不太適用。年營收還小的時候,成長率會因為分母小而輕鬆破百,加起來幾乎必然達標,這個分數不具鑑別度。早期公司更該看的是單位經濟學與客戶取得成本的回收期——一個客戶賺不賺錢、多久回本。等到營收規模站穩、成長率回落到正常區間之後,40 法則才開始有話要說。

非 SaaS 的公司可以用嗎?

可以參考,但要知道它的前提。這條法則假設營收具有高度重複性、毛利高、且成長投資會在後續年度自動轉成收入。專案型、硬體型或低毛利的生意不符合這些前提,成長往往必須同步押進存貨、產能與人力,成長與獲利之間沒有那麼乾淨的互換空間。這類公司用現金轉換循環或營運槓桿的角度看,通常比套 40 法則更貼近實情。

分數不到 40,該先補成長還是先補獲利?

先看哪一邊比較容易被買回來。獲利通常是隨時可以踩煞車擠出來的(砍行銷、緩招募),成長一旦掉下去往往回不去,因為它牽涉市場位置與產品競爭力。所以多數情況下的順序是:先確認成長掉下來的真正原因(新客變難、還是既有客戶在流失),把那件事修好,再談要不要把利潤壓出來。純粹靠縮減支出把分數補到 40 的公司,第二年通常會發現分數又掉回去了。

想把成長與獲利拆到單一客戶的層次去算,可以看LTV/CAC;想知道手上的現金還能撐多久,接著看新創跑道。至於高成長階段真正該管的事,這篇拆書整理得很完整。

發現引用或事實有誤?請寫信回報,我會依更正政策修正。