一份簡報寫著：「這是一個 US10B的市場，只要拿到110B 的市場，只要拿到 1%，就有 US100M 的機會。」

算術沒有問題。真正的問題是，那個 1% 到底替你回答了哪些問題。

它可能同時代表：哪些客戶真的屬於市場、哪些能在目標期間採用、公司實際碰得到多少、競爭下能贏多少、團隊能交付多少，以及最後到底對什麼經濟單位收錢。如果這些條件全被塞進一個百分比，模型看起來很乾淨，卻很難知道錯在哪裡。

所以市場規模分析最值得做的，不是把 TAM 算得更大，而是把「從市場到營收」之間每一道限制拆開。

先別算 TAM：你到底在算哪一個市場？

在任何 headline market size 出現以前，我會先鎖一份 Market Sizing Measurement Contract。它不需要很長，但至少要把下面幾個欄位講清楚。

欄位要回答的問題
Economic unit你在數公司、使用者、交易、席次、設備，還是金額？
Product / job boundary哪一種需求算進來？相鄰但不可替代的需求是否排除？
Customer eligibility哪些客戶真的符合產品、法規、技術或商業條件？
Geography全球、某個國家、城市，還是特定可服務區域？
Time horizon今天、一年、三年，還是成熟市場狀態？
Price / currency basisList price、實收價格、ACV、產業 spend，還是哪一種 value proxy？
Source period分子與分母是不是同一期間、同一版本？
Economic perimeter這個數字代表市場流量、產業產值，還是公司 revenue？

Small Business Administration 的市場研究框架會分開看 demand、market size、location、saturation、pricing；美國司法部的市場定義方法則把產品與地理邊界、替代關係放在核心。兩者用途不同，但都提醒同一件事：先定義邊界，再談規模。

例如，公司賣的是一套給特定法規環境下中型企業使用的 compliance workflow SaaS。把「企業軟體支出」直接叫做 TAM，範圍通常太寬；就算縮成某個 vertical 的軟體支出，也仍可能混入不同國家、不同工作流程、不同客群與根本不會購買這個產品的預算。

同一個 US$1B 數字，只要 geography 或 eligibility 變了，意義就可能完全不同。

Top-down 跟 Bottom-up 不一致，反而是好事

市場規模常見兩條路：一條從 aggregate 往下切，另一條從可觀察的 economic units 往上加。

Top-down 可以從官方產業統計、產業支出或交易總量開始，再逐步排除不符合產品、客戶或地理邊界的部分。Bottom-up 則先數符合條件的公司、門市、房間、設備、交易或其他 units，再乘上每個單位合理的 spend、usage 或 value proxy。

這兩條路的價值，不在於最後一定要算成一樣，而在於它們會用不同方式暴露模型裡的錯誤。

以本文後面的假想案例為例，先假設一個 adjacent industry-spend source 顯示 US1.2B∗∗。另一邊，bottom−up找到broadtargetuniverse有∗∗20,000家組織∗∗，每家年度economicvalue/willingness−to−payproxy暫用∗∗US1.2B**。另一邊，bottom-up 找到 broad target universe 有 **20,000 家組織**，每家年度 economic value / willingness-to-pay proxy 暫用 **US10,000，得到 US$200M。

US1.2B和US1.2B 和 US200M 差了六倍。這時最不該做的是取平均。

真正要做的是 reconciliation：

可能的差異要追的問題
Category adjacencyUS$1.2B 是否包含相鄰產品或服務？
Unit mismatch一邊算終端客戶 spend，另一邊是否混入 channel / supplier revenue？
Double counting產業 aggregate 是否把同一價值在供應鏈不同層重複算進去？
Geography / eligibility兩邊人口與可服務範圍是否一致？
Price / value basisUS$10,000 是 price、ACV、WTP，還是只是 value proxy？
Residual還有多少差異目前無法解釋？

Census Bureau 的 County Business Patterns 適合拿來檢查按產業與地理切分的 establishment population；BEA 對 gross output 與 value added 的區分則提醒，aggregate 本身也可能包含不同經濟層次。這些資料的重點不是幫你選一個「正確市場數字」，而是讓 denominator 變得可檢查。

如果兩種估法最後仍有 residual，就把 residual 留著。看不懂的差異，不會因為平均之後變得比較可靠。

TAM → SAM → SOM 不是三個百分比，而是一連串限制條件

三圈圖最大的問題不是錯，而是太容易讓人忘記每一圈到底排除了什麼。

比較有用的寫法是：

Defined TAM → Serviceable SAM → Adoption in Horizon → Commercial Reach → Attainable Share / SOM

Defined TAM 先鎖產品、客戶、地理、期間與 economic unit。Serviceable SAM 再排除公司現階段因法規、技術、產品功能、部署方式或地域覆蓋而服務不了的部分。

接下來要補上一個常被略過的條件：時間。市場上存在需求，不表示客戶會在你這一年的規劃期內採用。Bass diffusion model 的價值，在這裡只是提醒 adoption 是 population + time 的過程，不是說所有市場都一定遵循同一條 S-curve。

再往下是 commercial reach。客戶想買，公司也未必碰得到。Sales coverage、partners、distribution、procurement access 都可能把市場再縮小。

最後才是 attainable share。競爭、switching friction、sales conversion 與執行能力，會決定 reachable demand 裡面實際能贏多少。

因此，「SAM 是 TAM 的 30%，SOM 再取 1%」如果沒有對應到具體條件，只是把未知換成百分比。

一個假想 B2B 例子：市場不是被砍小，而是被定義清楚

下面是純教學用的 regional B2B compliance / workflow SaaS 案例。所有數字都是 arithmetic assumptions，不是產業 benchmark，也不是建議比例。

先保留前面的兩個獨立觀察：top-down adjacent market 是 US1.2B∗∗；bottom−upbroaduniverse則是∗∗20,000家組織×US1.2B**；bottom-up broad universe 則是 **20,000 家組織 × US10,000 value/WTP proxy = US$200M。這兩個數字不互相平均，也不假裝已經完成 reconciliation。

接著只看 bottom-up constraint chain：

階段假設剩餘組織 / 客戶
Broad target universe20,000 organisations20,000
Serviceable population產品／地理／eligibility 篩到 7,5007,500
Adoption in horizon35%2,625
Commercial reach60%1,575
Attainable competitive share20%315

如果同一套 US10,000先作為annualvalueproxy，serviceablevalueproxy是∗∗US10,000 先作為 annual value proxy，serviceable value proxy 是 **US75M**。這仍不是 revenue forecast，因為後面還有 adoption、reach 與 win share。

到 315 個 demand-derived customers 之後，才把 illustrative ACV 接上去：

315 × US10,000=US10,000 = US3.15M demand-derived annual revenue opportunity

這個模型的好處，不是得到 US$3.15M，而是知道每一層要驗證什麼。7,500 如果站不住腳，就回頭查 serviceability；35% 有問題，就查 adoption；60% 太樂觀，就查 channel reach；20% 無法辯護，就回去看 competition 與 conversion。

而且 US$3.15M 還不是短期可達成上限。

假設 sales、implementation 與 onboarding 系統在同一決策期間最多只能承接 300 個新客戶，那 capacity-capped opportunity 變成：

300 × US10,000=US10,000 = US3.0M

需求端支持 315 個客戶，但公司只接得住 300 個。差的 15 個不是「市場消失」，而是目前 execution system 的限制。

市場規模到營收機會的限制鏈：US1.2B 的 Top-down 估計保持獨立，Bottom-up 由 20,000 家組織一路經 Serviceable、Adoption、Commercial reach、Attainable share 與 Capacity 收斂到 US3.0M。

US1.2B的Top−down估計保持獨立；Bottom−up的具名限制把需求端US1.2B 的 Top-down 估計保持獨立；Bottom-up 的具名限制把需求端 US3.15M 收斂到受 300-customer capacity 約束的 US$3.0M 可執行機會。

最後一座橋最容易算錯：市場流量不等於公司營收

前面的 B2B SaaS 案例相對簡單，因為 customer × ACV 可以形成很直接的 monetisation bridge。

但 Marketplace、payments、travel、commerce 平台常用 GMV、GBV、TPV、GOV、payment volume、gross bookings 等數字描述 ecosystem activity。這些數字可以很大，也可以是很重要的 operating metric，但它們不是公司 revenue 的同義詞。

Airbnb 會分開揭露 GBV、bookings 與 revenue；Visa 分開看 payments volume、processed transactions 與 net revenue；eBay 的 take rate 需要把 net revenue 跟對應 GMV 放在同一 denominator contract 下；DoorDash 的 marketplace GOV 與 revenue margin 也說明同一件事：ecosystem flow 要先經過商業模式，才會變成公司收入。

所以 market sizing 到 revenue 之間，還要再問一次：公司真正 monetise 的 economic trigger 是什麼？

Recurring B2B 可能接近：

eligible customers × effective ACV

Marketplace 可能更接近：

eligible transaction value × realised take rate

Payments 可能還要拆 payment volume、transaction count、cross-border mix、product mix 與不同 fees。Booking Holdings 的揭露也顯示，bookings 與 revenue 的關係會受到 payment facilitation、product mix，以及 booking 與 travel timing 影響。

若要把這套思路寫成一個 teaching synthesis，可以是：

Revenue Opportunityₜ ≈ Eligible Economic Units × Adoptionₜ × Reachₜ × Attainable Shareₜ × Usageₜ × Effective Monetisationₜ

這不是外部標準，也不是每家公司都要有完全相同的 driver。有些模型沒有 usage，有些按 seats、transactions、orders、assets 或 balances 收費。不能省略的是 market denominator 與 company-revenue denominator 之間的橋。

需求是真的，也可能吃不到：Capacity、Channel 與多邊市場的限制

一個市場可以真的存在，需求也可以真的強，但公司仍然可能在指定期間吃不到。

回到案例，demand-derived customers 是 315，capacity ceiling 是 300。近一期 revenue opportunity 應先受 300 控制，而不是把 315 全部當成可以如期上線的客戶。

其他 business model 的 bottleneck 可能長得完全不同：sales reps 的 ramp time、partner coverage、implementation consultants、physical inventory、regulatory approval、service capacity、support throughput，甚至 risk-control capacity 都可能先碰到上限。

因此，實務上最好把兩個 ceiling 分開保留：

  • Demand-derived attainable opportunity
  • Execution / channel / capacity ceiling

短期可達成結果不應高於兩者較低的一邊，但模型也不該把較高的一邊刪掉。因為兩者之間的差距本身就在告訴你，要解鎖更多 revenue，究竟該增加 demand，還是增加 capacity。

多邊市場還多一個 denominator 問題。Marketplace 有 buyers 和 sellers，payments network 有 cardholders、merchants、issuers、acquirers。不同 sides 可能都很重要，但不能直接相加成「總客戶數」再乘一個 ARPU。先確認公司對哪一側、哪個 event、哪個 value flow 收錢，才知道誰真正進入 revenue denominator。

不要問「最準是多少」：找出哪個假設會讓結論翻盤

最後一輪不是把模型壓成一個更漂亮的 point estimate，而是做 sensitivity。

NIST 對 measurement uncertainty 的方法會要求把 uncertainty components 顯性化。這裡借的是方法，不是宣稱 TAM 屬於 NIST 管轄的 measurement problem。HM Treasury 的 Green Book 也把 sensitivity analysis 與 switching values 放進 decision appraisal，這正適合拿來檢查市場模型。

前面的 base case 有一個很清楚的 switching value。其他條件都不變時：

7,500 × adoption × 60% reach × 20% share = 300 customers

解出來，adoption 約為 33.3%。

也就是說，當 adoption 高於約 33.3%，300-customer capacity 先成為 bottleneck；若 adoption 掉到這個門檻以下，需求端開始比 capacity 更早限制結果。

假設 adoption 從 35% 降到 25%，模型會變成：

7,500 × 25% × 60% × 20% = 225 customers

225 × US10,000=US10,000 = US2.25M

這時候 bottleneck 已經從 capacity 轉回 demand。對決策者來說，這比再追一個更精準的 TAM 小數點更有用，因為它告訴你下一個值得驗證的是 adoption assumption。

Low / Base / High 當然可以做，但三個情境不等於三個機率。沒有 evidence-based priors 或 distributions 時，不要把人工挑出的 case 包裝成 probability。

一份可以拿來做決策的 market-sizing model，最後至少要回答四件事：

  1. Boundary：哪些人、交易、產品與地理被算進來？
  2. Bridge：市場活動怎麼一路變成公司 revenue？
  3. Constraint：adoption、reach、competition、channel、capacity，現在到底哪個在控制結果？
  4. Switching value：哪個 assumption 變到什麼程度，決策就應該改？

這四個答案如果清楚，模型就已經從「市場很大」走到可以被驗證、被反駁，也能拿來分配下一輪研究與執行資源的 revenue opportunity。

References