To calculate bottom-up SaaS TAM, count the eligible buying units in each non-overlapping segment, multiply each count by a defensible annual price, and add the results. Every count, rule and price should trace back to a source or a named assumption. The total is potential annual revenue, not a forecast and not a list of buyers.
We see the same problem in most market models we review. The math is simple. The hard part is deciding what one customer is and keeping facts apart from guesses. A smaller number that anyone can rebuild is worth more than a big number nobody can explain.
What counts as one buying unit?
Start with a one-sentence scope. For example: "Annual subscription revenue potential for an operations product sold to U.S. service businesses with 20 to 249 employees." That sentence is a working scope, not a measured market.
Then pick the unit that matches how you actually sell:
- An enterprise license points to one parent organization.
- A per-location price points to sites, with a rule for multi-site discounts.
- A per-seat price needs eligible users, not total headcount.
- A usage price needs eligible customers and a realistic usage range.
Do not count a parent company and each of its branches as separate full-price customers unless you really sell that way. Keep parent and child links in the data so a reviewer can see where you merged records.
Can public data tell you who will buy?
No. Public data gives you a starting frame. The U.S. Census Bureau's Statistics of U.S. Businesses reports employer establishments by geography, industry and enterprise size. County Business Patterns reports establishments, employment and payroll by area and industry. Neither one tells you who needs your product.
Read the definitions before you add numbers together. The SUSB glossary defines an establishment as a single physical location and an enterprise as one or more establishments under common ownership or control. A "firm" in SUSB is tied to a geographic area and an industry, so adding firm counts across states or industries can count the same company more than once.
Check coverage too. Both datasets cover businesses with paid employees and exclude some sectors, such as crop and animal production, private households and public administration. If your market includes one-person businesses, an employer dataset will miss them. Industry codes from NAICS describe what a business does, not what software it runs or wants.
How should the model be structured?
We build market models as six small tables instead of one large worksheet. A spreadsheet works. A small database is easier to maintain. What matters is that each table has one job.
- Scope: model version, owner, currency, geography, product definition, and the written include and exclude rules.
- Source register: publisher, link or file, reference year, download date, filters used and known limits.
- Population: one row per non-overlapping segment, or one row per account with a stable ID and parent ID. Never mix the two and add them.
- Eligibility rules: each rule, the field it uses, the evidence it needs, and how unknowns are treated. Unknown should never quietly become eligible.
- Pricing: segment, annual price, billing unit, seat or usage assumption, discount treatment and evidence. Keep one-time setup fees out of recurring TAM.
- Scenarios: the population and prices each scenario used, the result, and notes. Results come from the tables above, never a number typed in by hand.
Record the reference year apart from the download date. A file you pulled this month can describe a year that ended long ago.
What does a simple worked example look like?
Take a made-up product with two segments that do not overlap:
- Smaller operators: 2,000 buying organizations at an assumed $3,000 a year.
- Larger operators: 600 buying organizations at an assumed $12,000 a year.
The bottom-up TAM is $6.0 million plus $7.2 million, or $13.2 million in annual subscription revenue. These are teaching numbers only. They are not market research.
Now test it. If the larger segment came from a branch-level source, the count may be too high. If larger customers pay for setup, that fee does not belong in recurring TAM. If price rises with usage, one average can hide very different groups. A good review challenges the inputs and keeps the calculation. It does not swap in a bigger industry figure because it looks better.
How are TAM, SAM and obtainable revenue different?
Teams use these terms in different ways, so write your definitions into the scope table.
In our models, TAM is the full defined opportunity across every eligible buying unit. SAM narrows that to customers your current product and delivery model can serve, such as supported regions, required integrations or languages. Obtainable revenue adds a time window and real limits like sales capacity, conversion rates and onboarding capacity.
Do not multiply TAM by a win rate and still call it TAM. And an account in your CRM is not automatically new opportunity. It may be a current customer, a duplicate or out of scope. If your account data is messy, our CRM services team usually starts there, because clean account records feed every later step. The same applies to sales tools: AI sales agents fail without continuous data enrichment for the same reason.
How do top-down and value estimates help?
Use them as checks, not as replacements. A top-down estimate starts with a broad category and narrows it. Its category lines rarely match your product, so treat a large gap as a reason to look closer. A value estimate asks how much benefit the product creates and what share might support a price. A customer's savings are not your revenue, so confirm willingness to pay with real conversations.
When methods disagree, look at unit definitions, geography, overlapping segments, product scope and price basis. Do not average two incompatible numbers into one precise-looking answer.
How do you show uncertainty honestly?
Build low, base and high scenarios by changing named assumptions, such as the share of a segment that does the target workflow or the likely annual price. Do not invent confidence intervals without a statistical basis.
Before anyone approves the model, run basic checks: overlapping segments, mixed years, mixed currencies, duplicate account IDs, orphan parent records, negative counts and silent price changes. Then ask a second person to rebuild one segment from source to total. If they get the same number, the model is ready to use.
Frequently asked questions
No. TAM is potential revenue in a defined market under stated assumptions. ARR is recurring revenue a business actually has. A large TAM says nothing about whether customers will buy or stay.
Only after you define which employees would use the product. Total headcount is a starting population, not a seat count. Record role, access and adoption assumptions separately.
Not always. A total market can include current customers. A new-business view should flag or exclude them. Label each output so nobody confuses the two.
Update it when a source, product boundary, price or eligibility rule changes. Keep old versions so leaders can tell a market change from a method change.
Sources
- U.S. Census Bureau: About Statistics of U.S. Businesses
- U.S. Census Bureau: About County Business Patterns
- U.S. Census Bureau: SUSB Glossary
- U.S. Census Bureau: North American Industry Classification System
Turn your market model into a data workflow
If your account records, source files and pricing sheets do not line up, the fix is a better data model, not another chart. Hexagon IT Solutions connects CRM, billing and research data so your market numbers can be rebuilt on demand.
