Classifying Companies by Revenue Mechanics and Control Points

Hello. This opening module builds a map of the software and platforms industry before examining competitors in detail. We will start with a classification problem that often gets obscured by company descriptions: two businesses may both call themselves “platforms” while selling different things, earning revenue in different ways, and controlling different parts of the customer relationship.

By the end of this lesson, you should be able to classify a business as enterprise software, an infrastructure platform, a multi-sided platform, or AI-native—and explain the evidence behind your choice. The aim is not to memorize company labels. It is to develop a first-pass diagnostic you can apply when an unfamiliar company appears in an earnings release or industry discussion. Allow about 40–45 minutes, including the short readings and video.

Start with the transaction, not the label

“Platform” describes many products, but it does not identify a business model. An enterprise workflow vendor may call its application a platform because customers build on it. A cloud provider operates a platform on which developers run workloads. A marketplace operates a platform through which distinct participant groups transact. All three descriptions can be accurate, yet they imply different competitors and sources of bargaining power.

Use two questions together:

1. What is the customer paying for, and what makes the bill grow? Look for contracted access, metered resource consumption, fees associated with exchanges between participants, or charges for AI-driven work.
2. What does the company control that would be difficult to bypass? Possibilities include embedded workflows, a workload’s operating environment, access to another participant group, or a dependable AI capability integrated into a task.

Neither answer works alone. Subscription revenue does not automatically mean enterprise software: cloud services can be sold through contracts. Usage fees do not automatically mean a marketplace: a cloud provider meters computing resources. And putting AI in a product does not make the business AI-native.

These are primary business-model classifications, not mutually exclusive descriptions of every capability. A cloud provider can sell enterprise applications. A marketplace can use AI extensively. For a diversified company, classify the relevant business line first; a single label for the entire corporation may conceal more than it reveals.

Enterprise software versus infrastructure: where does the customer’s work live?

Consider an application that coordinates an organization’s service requests across existing systems. The customer pays for continuing access to that application and its capabilities. Its strategic position depends less on owning the underlying servers than on becoming embedded in how work is requested, routed, approved, and measured. That is the enterprise-software pattern—even if the vendor calls its product a platform.

ServiceNow’s filing provides a useful instance. Read its description of what the Now Platform does, then its explanation of what customers are billed for. Treat the filing’s account of the product and revenue as evidence; treat the proposed control point as an analytical inference to test.

The filing says the company’s workflow applications connect work across systems, while subscription fees primarily provide access to the ordered service. From those facts, a plausible strategic hypothesis is that workflow orchestration and integration into enterprise operations matter more to its position than ownership of raw compute. That hypothesis would need further testing—for example, whether customers rely on those workflows deeply enough to make replacement costly. For now, the classification is enterprise software, despite the word “platform” in the product name.

Now change the object of purchase. Suppose a developer buys virtual computing capacity, storage, and networking to run several applications. The bill varies with the resources used, and the provider operates the environment that makes those workloads available. That is an infrastructure-platform pattern: the customer is primarily buying a place and a set of services to build or run software, not one particular business workflow.

The following video contrasts physical colocation with cloud consumption. Focus on the distinction; its broad claims about the attractiveness of either model are less useful for classification.

A boundary matters here: owning a data center does not, by itself, make a company an infrastructure platform. A colocation provider can primarily sell space, power, and connectivity while its customers own and operate their servers. A cloud infrastructure provider typically controls and exposes programmable resources on which customers deploy workloads. Both are part of digital infrastructure, but the commercial object and operating control differ.

A multi-sided platform sells participation in an exchange

An ordinary software customer can receive value even if no other customer joins: its team can use the application to manage its own work. A multi-sided platform faces a different dependency. Its value to one participant group depends substantially on participation by another group. A reservation service, for example, needs both diners seeking tables and restaurants offering them.

The essential question is not “Are there multiple kinds of users?” Most enterprise products have administrators and end users. Ask instead: Does the business facilitate valuable interactions between distinct economic groups, and do those groups care about access to one another? If so, fees charged to only one group may not reveal the whole business model.

OpenTable is instructive because it also supplied table-management software to restaurants. If you classified it solely from that product, you might call it enterprise software. But the restaurant software also supported a reservation exchange: diners found available tables, restaurants reached diners, and restaurants paid fees associated with access and reservations. The cross-group interaction changes the strategic analysis. Restaurant adoption affects diner value; diner participation affects restaurant value. The platform’s control point includes its ability to coordinate that exchange, not merely its software features.

A practical revenue check is to distinguish the value exchanged on the platform from the platform’s own revenue. A marketplace may facilitate a large volume of purchases but recognize only its fees as revenue, depending on the arrangement. Conversely, an advertising-supported platform may charge advertisers rather than the people whose attention helps make the service valuable. The identity of the payer is important, but so is the group whose participation attracts that payer.

What makes a business AI-native?

AI-native is the least tidy category because it can overlap with the other three. It should therefore be a substantive claim about the product and operating model, not a label inferred from an AI feature or marketing language.

Imagine a company that handles a defined class of customer inquiries. Customers pay per successfully handled inquiry. The product’s core work is to interpret a request, draw on relevant information, decide what action is appropriate, use permitted tools, and check whether the result meets a quality threshold. Its economics depend on the price per handled inquiry, the fraction it can handle satisfactorily, and the cost of models, supporting systems, and human review. Remove the AI capability and the commercial proposition changes fundamentally. That is a plausible AI-native business.

Contrast it with an established case-management application that adds a summarization feature. The feature may improve the product substantially, but if customers primarily buy the underlying system to manage cases and the vendor’s principal control remains its installed workflows, enterprise software is the more informative primary classification. “AI-enabled” describes the feature; “AI-native” should describe what the business depends on to create and capture value.

The diagram below illustrates why the distinction requires care. It depicts applications and agents above supporting layers for evaluation, execution, and business context. It shows possible components of an AI-driven service; it does not establish any company’s revenue mix or prove that every application shown is AI-native.

For an AI-native classification, look for evidence in three places:

• Product dependence: Would the core customer outcome still be delivered without model-driven generation, reasoning, or action?
• Operating dependence: Are inference, evaluation, exception handling, and model performance central to delivering the service reliably?
• Value capture: Does pricing or expansion reflect the AI-delivered work, even if the customer pays a subscription rather than a per-task fee?

A company can meet these conditions and operate an infrastructure platform or a multi-sided exchange. In that case, report both dimensions rather than forcing away the overlap: for example, “an infrastructure platform with an AI-native service line.” If one primary label is required, choose the model that best explains the business line’s principal revenue and control point, then state the AI-native qualification and any uncertainty.

A classification you can defend

When preparing a first-pass company profile, write a short evidence trail rather than a one-word verdict:

1. Scope: State the business line you are classifying. A corporate group may have several.
2. Buyer and bill: Identify who pays, what they purchase, and what causes spending to rise or fall. Separate subscription access, metered resources, exchange-related fees, and services.
3. Control point: Identify what the business governs or embeds: an internal workflow, a workload environment, participation in an exchange, or AI-driven task delivery.
4. Counterevidence: Name the strongest reason another category might fit. Does “platform” refer only to extensible software? Does a transaction fee reflect a genuine cross-group exchange? Is AI integral or merely an added capability?
5. Verdict with confidence: Give a primary classification and, where necessary, a secondary description.

Applied to the examples in this lesson, the resulting statements are more useful than labels alone:

• ServiceNow’s workflow business: enterprise software; subscription access is central in the cited filing, and its described orchestration across systems suggests a workflow control point. Calling the product a platform does not make it a multi-sided marketplace.
• A provider of metered cloud resources: infrastructure platform; customers pay to run workloads in an environment the provider operates. Specific contracts may modify the billing pattern without changing that underlying role.
• OpenTable’s reservation exchange: multi-sided platform; diner and restaurant participation jointly create value, while restaurant software and fees support and monetize the exchange.
• The hypothetical AI inquiry-resolution business: AI-native; its saleable output and delivery economics depend on AI-driven task performance. A real company would require evidence on results, costs, and customer purchasing before that verdict was firm.

This discipline will help you avoid an early mistake in competitor analysis: comparing companies because they share a technology adjective rather than because they compete for the same spending or control the same part of a customer’s work.

Key takeaways

Revenue mechanics tell you what is sold; control points tell you why the business may retain power. Enterprise software embeds itself in organizational work. Infrastructure platforms host and enable workloads. Multi-sided platforms coordinate exchanges among participant groups. AI-native businesses depend on AI-driven performance to deliver their core proposition, though that characteristic can coexist with another model.

In the next lesson, you will use these distinctions to map a selected company’s activities across Product, Growth, Distribution, People, and Enabling Functions—moving from what kind of business it is to where its work and strategic choices sit across the value chain.