“Business model” and “revenue model” get used as if they mean the same thing. A business model describes how a company creates and delivers value to customers. A revenue model describes the specific mechanism a company uses to convert that value into money. Two companies can share the exact same business model and use completely different revenue models to monetize it.
Take two project management tools built for small teams. Same business model, same target customer, same core value. One charges a flat monthly fee per team. The other charges per active user, per month, based on how many people actually log in. Same product, different meter.
Getting this distinction wrong tends to show up later as a pricing problem that is not really about pricing at all. It is a mismatch between how value gets delivered and how the company chose to charge for it. This guide covers the most common revenue models in use today: subscription, usage-based, transactional, services, marketplace, PLG, and enterprise, along with how to tell which one fits your business.
Business Model vs Revenue Model: What’s the Difference
A business model is the bigger picture: who you serve, what problem you solve, and how you deliver that solution. SaaS, marketplace, agency, and hardware are all business models. A revenue model sits underneath that and answers a narrower question: how does money actually change hands?
A single business model can support several different revenue models at once. A SaaS company might charge some customers a flat subscription, charge others based on usage, and negotiate custom enterprise contracts for its largest accounts, all while running the exact same product and the exact same business model underneath. The revenue model is the layer that changes based on the customer, the market, and how value actually gets consumed.
Subscription: Predictable, Recurring Revenue
Subscription pricing charges a fixed, recurring fee, usually monthly or annually, in exchange for ongoing access to a product or service. It is the dominant revenue model in SaaS for a simple reason: it produces predictable, recurring revenue that is easy to forecast and easy to report to a board.
Subscription works best when value is delivered continuously rather than in a single moment. A customer does not buy project management software once and finish using it. They rely on it every day, which makes a recurring fee feel proportionate to the ongoing value they get.
Most subscription businesses layer tiers on top of the base model, separating features, seats, or support levels into Basic, Pro, and Enterprise packages. The metric that matters most here is monthly recurring revenue, or MRR, along with net revenue retention, since subscription businesses live and die by how well they keep and expand existing customers, not just how many new ones they sign.
The weak point of subscription pricing shows up when usage varies wildly between customers. A flat fee undercharges your heaviest users and overcharges your lightest ones, which is exactly the gap usage-based pricing was built to close.
Usage-Based: Pay for What You Consume
Usage-based pricing charges customers according to how much they actually consume: API calls, compute time, messages sent, storage used, or transactions processed. Instead of a flat monthly number, the bill moves with actual activity.
This model has become the default for infrastructure and API-driven products. Companies like Twilio, AWS, and Snowflake all charge this way, largely because it aligns cost directly with the value a customer is getting in that specific month. A customer sending a thousand messages pays less than one sending a million, without anyone having to negotiate a custom tier.
Usage-based pricing also makes it easier to land small and expand naturally. A new customer can start with a tiny footprint and a tiny bill, then grow into a much larger contract as their usage grows, all without a renegotiation. The tradeoff is forecasting difficulty. Revenue depends on customer behavior that is harder to predict than a fixed subscription count, which makes usage-based businesses lean harder on cohort analysis and consumption trends to build a credible forecast.
Transactional: A Fee Per Transaction
Transactional revenue models charge a fee for each discrete transaction or event that flows through the system, rather than a recurring subscription or a usage meter. Payment processors are the clearest example: Stripe and similar companies charge a small percentage plus a fixed fee on every transaction processed, and revenue scales directly with transaction volume.
This model fits businesses where the core value genuinely happens transaction by transaction, moving money, processing an order, completing a booking, rather than through continuous product access. The upside is that revenue grows automatically as customers do more business, without anyone needing to upsell a bigger plan. The downside is that revenue can swing with external factors like seasonality or a customer’s own business volume, which is largely outside your control.
Services: Billing for Human Labor
Services revenue comes from billable hours, fixed-price projects, or ongoing retainers, where the primary value delivered is human expertise rather than software. Consultancies, agencies, and implementation partners run on this model, and it remains common even inside software companies, particularly for onboarding, custom integrations, and enterprise implementation work.
The defining constraint of a services model is that revenue is tied to headcount capacity, not software leverage. A consultancy cannot serve twice as many clients without roughly twice as many consultants, which caps how efficiently the model scales compared to a pure software business.
Many software companies run a blended model on purpose, software revenue for the recurring product and services revenue for the one-time implementation work that gets a customer live. The services piece often exists specifically to reduce the risk of the software piece failing to deliver value fast enough on its own.
Marketplace: A Take Rate on Both Sides
Marketplace revenue models take a commission, often called a take rate, on transactions that happen between two separate parties on a shared platform: buyers and sellers, drivers and riders, freelancers and clients. The platform itself rarely owns the underlying inventory or service; it earns money by facilitating the match and taking a cut of the value that changes hands.
What makes marketplace revenue distinct is that it depends on liquidity on both sides at once. A marketplace with plenty of buyers and no sellers earns nothing, and vice versa, which means growth strategy has to account for both sides simultaneously rather than just acquiring customers the way a typical subscription business would.
Take rates vary enormously by category, from low single digits in categories with thin margins to twenty percent or more in categories where the platform provides significant additional value, like payment handling, trust and safety, or logistics.
PLG: A Motion That Shapes the Revenue Model
Product-led growth, or PLG, is technically a go-to-market motion rather than a revenue model on its own, but it shapes which revenue model actually works. In a PLG motion, the product itself drives acquisition and conversion through a free trial or freemium tier, with little or no sales involvement until later in the customer’s lifecycle.
Because there is no salesperson negotiating a custom deal, PLG companies almost always pair the motion with self-serve pricing, either a simple subscription tier a user can select with a credit card, or usage-based pricing that scales automatically as the account grows. The monetization has to be instrumented directly into the product, since there is nobody manually walking a prospect through a pricing conversation.
The tell that a company is running a genuine PLG motion is not the pricing page, it is whether a user can go from signup to real value without ever speaking to a human being.
Enterprise: Negotiated, Sales-Led Revenue
Enterprise revenue models rely on custom, negotiated contracts closed through a sales-led process rather than a self-serve checkout. Pricing is rarely published, terms are negotiated deal by deal, and contracts often run multi-year with committed spend, custom SLAs, and dedicated support built in.
This model produces a very different shape of business than subscription or PLG: fewer total customers, but a much higher average contract value per account. It also introduces a much longer sales cycle, often stretching across procurement and legal review that a self-serve customer never has to think about.
Many companies that start on subscription or PLG eventually add an enterprise tier once their largest customers start asking for things a standard plan cannot accommodate: custom security requirements, dedicated infrastructure, or contract terms their legal team requires before they can sign anything at all.
How to Choose, or Blend, the Right Model
Most real businesses do not run a single, pure revenue model. They blend two or three: a base subscription plus usage-based overage charges, a subscription plus a one-time services fee for onboarding, or a self-serve PLG tier that graduates into negotiated enterprise contracts once an account grows large enough.
The right starting point is not which model is easiest to bill for. It is how your customer naturally experiences and consumes value. If value is delivered continuously and evenly, subscription usually fits. If value scales directly with volume of activity, usage-based or transactional pricing usually fits better. If the value is mostly human expertise, a services model probably belongs somewhere in the mix, even if the core product is software.
Choosing the wrong model rarely looks like a pricing failure at first. It looks like customers churning for reasons that do not show up in a typical exit survey, or expansion revenue that never quite materializes even though usage is clearly growing. Before assuming your price is wrong, it is worth asking whether your model is.
Frequently Asked Questions
What is the difference between a business model and a revenue model?
A business model describes how a company creates and delivers value, who it serves and what problem it solves. A revenue model describes the specific mechanism used to charge for that value, such as a subscription fee, a usage meter, or a transaction fee. The same business model can support several different revenue models at once.
Can a company use more than one revenue model at the same time?
Yes, and most established companies do. A common blend is a base subscription plus usage-based overage charges once a customer exceeds an included amount, or a self-serve subscription for smaller accounts alongside negotiated enterprise contracts for the largest ones. Blending models lets a company match different customer segments to the pricing approach that fits how each one actually consumes value.
Is PLG a revenue model or a go-to-market strategy?
PLG, or product-led growth, is a go-to-market motion, not a revenue model on its own. It describes how customers discover and adopt a product, largely through a free trial or freemium tier without sales involvement. It usually pairs with a self-serve subscription or usage-based pricing model, since both can be instrumented directly into the product without a salesperson negotiating terms.
Why do SaaS companies eventually add an enterprise pricing tier?
Large customers often need things a standard self-serve plan cannot accommodate: custom security or compliance requirements, dedicated infrastructure, multi-year commitments, or contract terms their legal and procurement teams require before signing. Adding a negotiated enterprise tier lets a company capture that revenue without forcing every customer through the same sales-led process.
How do I know if I picked the wrong revenue model?
The signals rarely look like an obvious pricing complaint. Watch for churn that does not show up as a clear complaint in exit surveys, or expansion revenue that stays flat even though product usage is clearly growing. Both often mean the way you charge does not match how customers actually experience value, which is a model problem, not just a price problem.
What is a take rate in a marketplace revenue model?
A take rate is the commission percentage a marketplace keeps from each transaction that happens between buyers and sellers on its platform. Take rates vary widely by category, from low single digits in thin-margin categories to twenty percent or more where the platform adds significant extra value, such as payment processing, trust and safety, or logistics handling.
Leave a Reply