TAM, SAM, and SOM: How to Build a Market-Size Model That Holds Up

A market can look enormous until the first practical constraint arrives. The product works only in two countries. A required integration rules out half the accounts. The sales team can pursue 120 serious opportunities this year, not 12,000. A credible market-size model does not hide those reductions. It explains them.

market sizing: a market globe, account filter tray, and bounded sales ledger narrowing left to right, balance scale, desk lamp, ruler, potted plant

TAM, SAM, and SOM are three nested views of the same opportunity:

  • Total addressable market (TAM) is the full demand allowed by a declared market definition.
  • Serviceable available market (SAM) is the portion the current offer and operating model can serve.
  • Serviceable obtainable market (SOM) is the portion the business can plausibly capture within a stated period.

That nesting is the point. The three numbers are not optimistic, moderate, and conservative forecasts. Each answers a different question, and every step inward introduces evidence about a real constraint. The UK government’s investor-readiness guidance likewise treats the progression from TAM to SAM to SOM as a chain that should be evidence-based and logically connected, rather than three unrelated headline figures (GOV.UK).

For a bottom-up revenue model, the basic arithmetic is simple: eligible customer units × annual revenue per customer = annual revenue opportunity. The difficult work lies in defining the customer unit, finding a defensible count, and deciding which filters belong at each layer. A polished calculation built on a vague population is still a vague claim.

The three layers turn one broad claim into three decisions

The table below keeps the objects separate. It also shows why a large TAM does not automatically imply a large sales opportunity.

LayerQuestion it answersTypical inputsWhat it does not prove
TAMHow much demand could exist within the declared market boundary?Eligible customers or units, geography, category, period, annual value per unitThat the current product can serve every customer
SAMHow much of TAM can the present offer and delivery model serve?TAM inputs plus product, regulatory, geographic, channel, integration, and delivery constraintsThat every eligible account is identifiable, reachable, or ready to buy
SOMHow much of SAM can this business plausibly capture in the stated horizon?Reachable accounts, competitive position, sales capacity, price, win assumptions, timing, and tractionA guaranteed forecast

TAM draws the outside boundary

TAM is the upper boundary, but “everyone who could benefit” is rarely a usable definition. A B2B TAM needs a named customer unit—enterprise, establishment, site, seat, transaction, or another countable object—plus a product category, geography, time period, and value basis. Exclusions matter as much as inclusions.

Suppose the buyer is an enterprise, but the dataset counts establishments. One enterprise may operate several establishments, so multiplying establishment count by enterprise contract value overstates the opportunity. The U.S. Census Bureau explicitly notes that an establishment is not necessarily a company or enterprise; a company may contain more than one establishment (U.S. Census Bureau). The arithmetic can be flawless and the unit can still be wrong.

TAM can be expressed as customer count, units, or revenue. Revenue is often useful for comparison, provided the annual value per unit is defensible. Amazon Ads describes the common revenue calculation as potential customers multiplied by average revenue per customer and illustrates it with assumed household and spending figures (Amazon Ads). That example demonstrates the formula, not the truth of any particular market. Your customer count and value assumption need their own support.

A top-down industry total may provide a quick boundary, but only when its category matches what the company actually sells. If a report combines hardware, services, and maintenance while the offer covers only one of those, the published total is a starting point for filtering—not TAM by default.

SAM exposes what the business can serve now

SAM removes demand that falls outside the current product and operating model. Common filters include supported geography and language, legal permission to sell, required certifications, technical compatibility, minimum viable contract size, delivery capacity, and route to market. The test is present serviceability. A capability on the roadmap belongs in a future scenario, not current SAM.

This is where teams often smuggle their ideal customer profile into the market definition. The overlap can be useful, but the concepts are not identical. SAM asks whether the offer can serve an account. An ideal customer profile asks whether observable account characteristics indicate strong mutual fit and a worthwhile opportunity. GOV.UK’s ICP guidance suggests dimensions such as sector, company size, geography, budget, procurement, compliance, problem, technical fit, and readiness; it separately identifies technical, executive, and end-user buyer roles (GOV.UK). Those dimensions help prioritize accounts, but they do not turn a profile into a market-size estimate.

Consider a platform that technically supports every manufacturer in a region but produces clear value only for plants with a particular compliance burden. If that burden is inherent to the offer’s serviceable use case, it may be a SAM filter. If it merely predicts higher urgency or a faster sale, it belongs in the ICP and prioritization model. The distinction depends on causality: can the product serve the account, or is the account simply more attractive?

If a planned feature, unapproved jurisdiction, or unavailable delivery channel is counted in current SAM, the model is describing a future business as though it already exists.

SOM connects market size to a capture mechanism

SOM is not “SAM × a small percentage” unless that percentage follows from evidence. It needs a time horizon and a mechanism: identifiable accounts, a workable route to them, commercial capacity, expected contract value, competition, and a capture assumption grounded in something more than ambition.

For an existing business, relevant evidence may include qualified pipeline, historic win rates for comparable segments, renewal behavior, sales-cycle length, partner throughput, and delivery limits. For an early-stage business without such history, customer interviews, pilots, letters of intent, channel validation, and capacity-based scenarios can narrow the uncertainty. The result remains an estimate. Label it accordingly.

The GOV.UK investor-readiness page frames SOM as the share of SAM that can be captured over a defined horizon and gives a sector-oriented example based on target accounts, expected contract value, and win rate. It also mentions a 1%–5% share as a credibility signal in that particular guidance (GOV.UK). That is not a universal benchmark. A concentrated market with long replacement cycles, a regulated procurement process, or a capacity-heavy deployment can make even 1% implausible; a narrow niche with documented traction may support more.

SOM also differs from a target account list. SOM is a quantified capture scenario. A target list names the accounts selected for action under current priorities and capacity. Some accounts may contribute to SOM without appearing in this quarter’s list, while some strategic targets may be pursued for learning or partnership value rather than near-term revenue. Treating both as one object makes it impossible to tell whether a change came from the market, the strategy, or the team’s workload.

Build a defensible TAM, SAM, and SOM model from the outside in

A useful model is less like three circles on a slide and more like a short calculation trail. Each number should reveal where it came from and why the next number is smaller.

  1. Write the market boundary before finding a market total. Name the problem or category, customer unit, buyer type, geography, period, currency, and revenue basis. Record exclusions in plain language. “US employers in specified industries buying an annual site license” can be tested; “the global software market” cannot support a product-level estimate without extensive filtering.

  2. Choose a unit that survives all three layers. If TAM begins with enterprises, SAM and SOM should remain enterprises or revenue derived from enterprises. Do not switch silently from companies to locations, users, or contracts. Where a product genuinely has multiple revenue units, calculate each stream separately before combining them.

  3. Count TAM with sources that disclose their coverage. Government business registers and statistical programs can provide a strong starting point, but read their unit definitions and exclusions. U.S. County Business Patterns reports establishments with paid employees by geography, industry, and employment-size class, while excluding some industries and most government employees (U.S. Census Bureau). Eurostat’s structural business statistics can be broken down by economic activity and enterprise size, but they define an enterprise as an economic unit that may operate at multiple locations and exclude activities such as agriculture and public administration from the SBS scope (Eurostat). Neither source automatically matches every B2B market. The coverage note belongs beside the count.

  4. Attach an annual value to the same unit. Use observed annual contract value for a comparable segment when available. If pricing varies materially by company size, use separate bands rather than one average that no customer resembles. For a new offer, show the proposed price as an assumption and avoid presenting willingness to pay as established fact.

  5. Apply serviceability filters one at a time to reach SAM. Give each filter a reason and a data field. Geography may come from registration data; technical compatibility may require product or installed-base data; regulatory eligibility may require a separate register. Preserve unknowns instead of treating missing data as either eligible or ineligible. This makes gaps visible and prevents false precision.

  6. Model SOM through reach and capacity. State the horizon, reachable account population, number of opportunities the team can properly pursue, expected win basis, annual value, implementation capacity, and downside case. When reliable win history is absent, use an explicit scenario rather than borrowing a generic market-share percentage. The question is not merely how much share sounds conservative. It is how customers would move from eligible to contacted, qualified, won, and successfully served.

  7. Reconcile the layers and keep a change log. Confirm TAM ≥ SAM ≥ SOM in the same unit and period. Then record the source date, filter logic, assumption owner, and reason for each revision. If a new certification expands SAM, or a price change alters revenue without changing account count, the model should show that distinction.

Here is a simulated calculation, included only to show how the layers connect. Assume a B2B vendor defines its market as 20,000 eligible enterprises at an assumed annual contract value of $24,000. Its revenue TAM is therefore $480 million a year. Current geography, integration, and regulatory constraints leave 6,000 serviceable enterprises, producing a $144 million annual SAM at the same assumed value. The team can properly pursue 120 qualified opportunities over the next 12 months and uses a 25% win-rate assumption, giving 30 customers and a $720,000 SOM measured as first-year annual contract value.

None of those illustrative inputs is a market finding. The example becomes credible only when the 20,000-enterprise count, the $24,000 value, the filters that reduce 20,000 to 6,000, the 120-opportunity capacity, and the 25% capture assumption are independently supported. It also reveals what would change the result: more serviceable accounts enlarge SAM, while more sales capacity or better demonstrated conversion changes SOM.

Check the model from two directions before anyone relies on it

Bottom-up and top-down estimates answer different kinds of doubt. A bottom-up calculation starts with customers or operational units and is usually easier to connect to product constraints and account planning. Its weakness is coverage: commercial databases can omit private firms, duplicate entities, lag new formations, or classify a diversified company under an unhelpful industry code.

A top-down calculation starts with a published category total and applies shares or filters. It can expose whether a bottom-up result is wildly out of scale, but its weakness is category fit. The reported market may include products, buyers, geographies, or revenue types outside the boundary you declared.

Do not average the two simply because they disagree. Diagnose the gap. A larger top-down result may signal that the published category is broader or that the bottom-up source misses small and private entities. A larger bottom-up result may signal duplicate locations, a customer-unit mismatch, or an annual value that includes spending outside the offer. The explanation for the difference is often more decision-useful than a precise midpoint.

Three checks catch many failures. First, recompute the arithmetic from raw counts rather than a presentation graphic. Second, trace every filter to a source or an explicit assumption. Third, run a unit audit: customer type, geography, currency, revenue definition, and time period should remain compatible across all layers. If both the population and the price change between layers without being shown separately, the nesting can no longer be audited.

Sensitivity analysis helps when one uncertain input dominates. Vary the count, annual value, or capture assumption independently and show what happens. Do not choose a wide range merely to look cautious; every endpoint still needs a reason. If evidence cannot support a capture rate, say that the scenario is provisional and name the observation that would improve it—such as completed pilots, qualified pipeline, or a full sales cycle.

Presentation should preserve this reasoning. Put the three figures beside their unit, period, formula, source date, and major exclusions. Follow them with the short reconciliation note and the assumptions that most affect the decision. A reviewer should be able to disagree with a filter without first reverse-engineering the spreadsheet.

Start with the boundary, not the impressive number

The first useful move is to write one sentence that defines the market tightly enough to count. Then build outward evidence and inward constraints around it. If that sentence cannot name the customer unit, geography, offer category, and period, the calculation is not ready.

A smaller model with visible assumptions is more valuable than a giant TAM that cannot explain who is inside it. The aim is not to make the opportunity look modest. It is to show exactly which part of the opportunity exists, which part the business can serve, and which part its current capabilities give it a credible chance to win.

Frequently asked questions

Can SOM be larger than SAM?

Not when both use the same unit, period, and market definition. SOM is a captured portion of SAM, so SOM greater than SAM signals a unit mismatch, inconsistent time periods, double-counting, or a formula error. A five-year cumulative revenue SOM, for example, cannot be compared directly with a one-year SAM without converting them to a common basis.

How often should TAM, SAM, and SOM be updated?

Revisit the model when a decision-changing input moves: the product enters a geography, gains a certification, changes price, adds a channel, or produces new conversion evidence. Also refresh source data on its own publication cycle. U.S. County Business Patterns is annual, but the program notes that its releases arrive after the reference year, so the source date and reference period should both remain visible (U.S. Census Bureau).

Can TAM, SAM, and SOM be measured in accounts instead of revenue?

They can. Account counts are often clearer for territory design and capacity planning, while revenue helps with financial comparison. Keep both views if they serve different decisions: show the nested account counts first, then multiply each layer by a compatible annual value assumption. Do not combine accounts, sites, and seats in one sequence unless you provide an explicit conversion between them.

Run your growth team from one screen.

Invite only