假設你有一套企業軟體，核心功能完全不變。

你可以每家公司每月收固定訂閱費，也可以按使用者席位、API 呼叫量或交易計費；可以要求客戶先承諾最低用量，再對超額部分收費；如果成果能被清楚量化，甚至可以把部分費用綁在結果上。

產品看起來還是同一個產品，程式碼可能也只改了一小部分。可是客戶開始使用的門檻、敢不敢多用、財務部門怎麼編預算、供應商怎麼預測收入、業務怎麼談合約，以及毛利會不會跟著用量起伏，都可能一起變。

所以定價不能只問 How much do we charge?。還得問 What do we charge for? Who gets which offer? What risk does each side absorb?

Pricing 在這篇裡不是一個數字，而是一套經濟架構。

先把 Pricing 拆成四個不同決策

很多討論會把牌價、方案、計費單位、折扣和商業模式都叫做 pricing。先拆開，後面才知道到底是哪個槓桿在動。

第一層是 revenue / value trigger：客戶究竟是在為哪種價值或事件付錢？可能是取得一段時間的使用權、增加一個使用者、消耗一個單位、完成一筆交易，或得到一個可驗證的成果。公開公司的收入分類不是這套 monetization 框架本身，不過它能提醒我們同一家公司可以同時存在不同 earning pattern。Salesforce FY25 年度報告 把收入分成 subscription and support，以及 professional services and other 兩個主要來源；term software-licence revenue 包含在 subscription and support 裡。

第二層是 pricing metric，也就是拿什麼當計費單位。可以是一個 seat、一筆 transaction、一個 API call、一 GB 儲存量、一小時運算，或一個經過定義的 outcome。計費單位和「每單位多少錢」是兩個不同問題。Stripe 對 usage-based pricing 的說明也把可計量的 usage metric、計費方式，以及讓支出更可預測的控制機制分開處理。

第三層是 packaging，決定不同客戶拿到哪些功能、權限、服務水準、用量上限或治理能力。第四層才處理最後真正收到多少錢，也就是 realized-price mechanics。牌價之外，折扣、最低承諾、預付，以及 credit、cap、floor、included allowance、overage 都可能改變實收價格。AWS 的 Savings Plans 把交換寫得很直接：客戶用一段期間的用量承諾換較低價格，底下仍然按 consumption metric 計量。

四層都定好之後，還要做 economic validation。把價格、用量、客戶組合、留存與擴張，以及服務這群客戶的成本，放回同一個 economic unit 和 cohort，再看 contribution economics 是否真的改善。

同一個產品連到 Value Trigger、Billable Unit、Packaging 與 Price / Commitment 四個變現設計選擇，接著影響 Customer Behavior、Risk Allocation，最後回到 Unit Economics 驗證。

你拿什麼當收費單位，就在改變客戶怎麼使用產品

固定訂閱下，多用一次通常不會多付一次；按 seat 收費時，每多一個人都可能讓採購重新問一次「值得再買一個 licence 嗎？」；按 API call 或運算量收費，新增 workload 會直接帶來邊際費用；按交易收費，供應商收入更直接跟交易活動連動。若改成 outcome 計費，帳單離客戶感受到的價值更近，但成果怎麼定義、由誰造成、何時算完成、例外怎麼處理，也一起進了商業合約。

Usage-based pricing 常被理解成「用多少付多少」。它確實可能降低一開始的承諾門檻，讓支出隨採用程度變化；Twilio 的公開文件就是 usage-based revenue 的公司案例，年報也把客戶用量增加放在 expansion mechanics 的脈絡裡。另一面是波動。客戶較難先把帳單鎖死，供應商也會更直接承受 usage 變化。

Outcome-based pricing 把計費再往可定義的成果推。Stripe 對 outcome-based pricing 的說明會先定義 measurable outcome，再搭配 base fee、variable fee，以及 cap、floor、commitment 等限制。若成果很難歸因，或買賣雙方對「成功」的定義不同，原本想靠近客戶價值的設計，可能先多出一層計費爭議。

Value-based pricing 是另一件事。它把客戶價值當成定價 anchor，不代表帳單一定直接綁成果。一份 OECD 關於 value-based pricing 的報告在藥品情境下討論 willingness-to-pay 與 differentiated benefits，也反映出「價值怎麼量」本身就可能有爭議。這個產業案例不能直接搬成 SaaS 規則；能帶回來的方法要求很簡單：做 WTP 研究時，要交代樣本、方法和使用情境。

Elasticity 也要留在自己的時間尺度裡。一篇 NBER 使用隨機利率實驗的研究發現，估計出的 demand elasticity 會隨觀察期間明顯改變。它沒有給 SaaS 一個萬用 elasticity 數字，只說明需求反應不能脫離情境與觀察 horizon。

Packaging 不是把功能排成 Basic、Pro、Enterprise 三欄

假設剛剛那套企業軟體仍然按 usage 計費，計費單位完全沒變。Basic 只放核心功能，Pro 加入協作和自動化，Enterprise 再加入權限管理、SLA、稽核紀錄與專屬支援。此時改的是 value fences，不是 pricing metric。

客戶會按自己的規模、工作流程、風險要求和願意付出的成本選方案。即使產品與 usage metric 都沒變，進來的是哪一群客戶、多少人轉換、哪些客戶往上擴張、需要多少支援，以及各群客戶的毛利表現，都可能跟著變。

因此，ARPU 上升之前要先看客戶是怎麼「升級」的。有人因為真的需要更多價值而主動往上走；也有人只是因為公司把原本的權限移出低階方案，被迫換到更高 tier。兩種情況都可能把 ARPU 往上推，後者卻也可能增加 churn 或直接把某些客群推出產品。

方案也沒有一個放諸四海皆準的最佳層數。像 Babaioff、Immorlica、Lucier 與 Weinberg 對 bundling 的研究，是在特定 valuation assumptions 下比較 bundle 與分開銷售的收入表現。這類研究能說明 bundling 會改變價值捕捉，而且結果依賴客戶價值分布與模型假設；它不能替每家公司推出「三層方案最好」。改完方案後，還是得回頭看客群怎麼移動，以及各群人的 contribution economics。

折扣不是價格旁邊的一個負號

業務說客戶要求 30% discount，只看這個百分比，幾乎判斷不了交易好壞。

如果這個折扣換回三年 commitment、最低採購量、預付款或更可預測的 demand，供應商犧牲部分單位價格，同時也改變了風險與現金流結構。若什麼都沒換到，只是單純降價，那就是另一筆交易。AWS Savings Plans 的機制很適合拿來看這件事：承諾一定期間的用量水準，換取較低價格。這裡借的是交換機制，不是叫所有 SaaS 都照 AWS 做。

所以談折扣時，我會先看三件事：少掉多少 contribution、換回什麼承諾、那個承諾實際降低哪一種風險。 Commitment 也可能設壞。低價承諾若帶來大量服務成本很高的用量，或把客戶鎖進一個最後不續約的方案，收入看起來更可預測，經濟性仍可能變差。

這時業務談判處理的已經是實收價格與風險怎麼分，不只是 price list 上的數字。

同一個產品，可以被設計成六種不同的生意

把前面幾層疊起來，六種 monetization 結構的差異可以不用「高、中、低」來評分，直接看每一種結構把什麼事件接到帳單上，以及波動往哪裡走。

Monetization 結構什麼事件讓客戶多付客戶支出怎麼動供應商收入怎麼動主要擴張路徑主要營運風險
固定訂閱續約、換方案或加購時若固定費不隨單次使用變動，短期用量增加不會直接增加帳單主要隨客戶數、續約、升級與加購變動升級方案、加購低使用量客戶可能覺得不划算；高使用量客戶可能被低估
Per-seat增加付費席位時席位增加就增加支出會隨付費席位與續約變動增加席位每新增一個人都有明確邊際費用，可能抑制跨團隊採用
Metered usage多消耗一個計費單位時直接跟可計量用量一起變直接承受用量增減用量自然成長帳單與收入隨 usage 波動，客戶可能刻意節流
Usage + commitment超過承諾或提高 commitment 時最低承諾先定一部分支出，超額再隨用量變承諾提供一部分底線，仍會受實際 usage 與 overage 影響超額用量、提高 commitment承諾設錯可能造成折價或用量錯配
Transaction-linked發生符合條件的交易時跟交易活動或交易價值變化跟交易量、交易價值與 mix 變化交易量、交易價值成長收入更暴露在交易週期與 mix
Outcome-linked出現合約定義的可驗證成果時會受成果數量以及 cap、floor 等條款影響取決於成果是否發生，以及合約如何處理 base fee、cap、floor 等條件可驗證成果增加歸因、測量、爭議與 gaming

固定訂閱、per-seat、usage、transaction、outcome 不是六個品質等級。差別在於哪一種客戶行為會進入帳單、收入靠什麼擴張，以及波動由哪一方承擔。Commitment 還可以包在 usage 之上，重新分配一部分波動，而不必換掉原本的 usage metric。

實際公司也常同時用幾種計費分母。固定平台費、usage charge、transaction fee 和 services revenue 可以並存；到了這裡，「我們是 subscription business」這種總標籤已經不足以解釋收入怎麼長。

C3 AI 是一個有邊界的例子。公司在 SEC filing 中描述往 consumption-based pricing 移動，希望讓採用方式更接近雲端服務的購買模式；同時也提到，這會降低對 consumption revenue 時點的可見性。這份 filing 沒有證明 consumption pricing 優於 subscription。它只是把一組很具體的交換放在同一張圖上：採用門檻可以下降，供應商承受的收入時點不確定性也可能增加。

營收變高了，先不要急著宣布 Pricing 成功

假設改價三個月後，dashboard 出現兩個好消息：Revenue +12%，ARPU +9%。兩個數字都是真的，也還不能直接判定新的 monetization model 比以前健康。

先拆 Revenue +12% 從哪裡來：實收價格提高多少？交易量或使用量增加多少？客戶組合有沒有變？是否有人被搬進更高方案？低價客戶有沒有流失？認列或交易時點是否移動？DoorDash 在 Q1 2025 results 裡同時報告 Marketplace GOV、revenue 和 Net Revenue Margin，也討論 affordability initiatives 與 category mix 對 margin 的影響。這個案例支持的是「收入變動需要拆 driver」，不是把 DoorDash 的 bridge 套到別家公司。

接著把 cost-to-serve 放回來。新的 pricing metric 如果鼓勵大量低毛利用量，收入可能長得很快，contribution 卻沒有同步改善。

ARPU +9% 也要看分母。有些低價、低用量客戶若先流失，留下的高價客戶自然會把平均值抬高。這可能是正確策略，也可能只是母體縮小。客戶 mix、匯率和 cohort age 都可能讓表面 unit economics 變漂亮。HubSpot 年度報告提供的是公司層級提醒：平均指標要連同客戶組合與指標口徑一起讀，不能把 HubSpot 的特定結果外推到其他公司。

Netflix 的公開年度報告會把 streaming revenue 的成長和 average paying memberships、price changes 等因素一起看。總營收顯然不只受一個 driver 影響，而這些公開資料也沒有提供每個 cohort 的 LTV。要從 aggregate revenue growth 推到「所有客戶經濟性都改善」，中間還缺驗證。

最後才回到 unit economics。這篇把 economic unit 當成操作性定義：找一個最小決策單位，讓 revenue、variable cost、retention 與 acquisition cost 都能用同一個 denominator 比較。它不是會計準則，而是避免母體漂移的分析紀律。Payback 也要守同一條線。實務上有方法用 recurring gross-margin contribution，而不是 revenue 本身，估算 acquisition cost 要多久回收；The SaaS CFO 的 CAC payback 說明就是一個 practitioner 例子。若服務成本會吃掉一部分收入，直接拿 revenue 當回收能力，payback 會顯得過度樂觀。

所以改價之後，我會把問題寫成：在一致的 cohort、unit 與 contribution basis 下，我們用什麼換到這兩個成長數字？留存、擴張、cost-to-serve 與 payback 各自怎麼變？

最後要選的不是 Pricing Model，而是你願意營運的風險配置

候選方案進到決策桌上時，先不要問哪一個 model 最好。先看公司能不能營運它帶來的條件。

收費事件要離客戶感受到的價值夠近，但也要真的量得到。Pricing metric 必須能穩定計量、修正和稽核，不然每張帳單都可能變成資料爭議。至於 Packaging，要回頭看客戶是否真的因需求不同而 self-select，還是公司靠移除既有權限製造被迫升級與 cannibalization。

折扣也要帶著交換條件一起看：它買回的是合約期間、採購量、預付款、最低消費，還是其實什麼都沒有？當 usage 上下波動時，客戶承擔多少預算風險，供應商承擔多少收入波動，公司是否真的有能力營運這種分配？

最後留一個能推翻自己方案的檢查：什麼證據會證明這次 Pricing 改版沒有讓生意變好？ 如果回答不了，monetization 仍比較接近商業敘事；如果能用固定 cohort、contribution economics 和真實客戶行為去驗證，才有辦法知道這次改的是價格，還是真的改了生意。

References