Choose a Revenue Model by What Buyers Value
A software company can have a popular product and still struggle to answer a simple question: what, exactly, should appear on the customer’s bill? A flat monthly fee is easy to explain, but a customer who barely uses the product may see little reason to renew. A charge for every unit of use can look fairer, but the customer may hesitate if the bill is hard to predict. The choice changes the offer customers think they are buying and the revenue the company can expect from that offer.
A revenue model is the rule for how a business receives money from what it sells. It identifies the payer, the event that creates a charge, the unit being charged, and the period or term to which the charge applies. A price fills in the amount. A revenue forecast estimates what those rules might produce across customers and transactions. Neither the name of the model nor a larger bill establishes that the business is profitable.
The useful question, then, is not “Which revenue model is best?” It is “What can the customer understand, agree to, and verify as the basis of payment?” Start there. A model that fits the way customers receive value is easier to explain; a model built around an arbitrary unit asks the customer to accept a bill before understanding what the bill represents.
Define the charge before naming the model
Imagine a team selling software that helps businesses process work. “Subscription” says little about the actual offer. Does one payment cover an organization, a named user, a month of access, or a fixed amount of processing? Does the customer pay more when activity grows? Can an unused allowance carry into the next month? The answers determine the bill; the label does not.
A workable description of the model can fit in one sentence: “Each customer pays $80 per month for access for up to five users, plus $0.20 for each completed unit of processing above an included allowance.” This is an illustrative offer, not an observed company price. It has a payer, a term, an entitlement, an extra charge, and a measurable trigger. Those details let a customer estimate a bill and let the seller test whether the bill covers the work required to serve that customer.
The first distinction is between access and activity. A continued-access charge asks the customer to pay for the right to use the offer during a term, even if actual activity varies. A usage charge depends on a measured unit. A transaction charge depends on a qualifying event, such as an eligible payment. A contract may set a commercial commitment while permitting an additional charge for usage. AWS Marketplace documents contract offers and contract offers with metered charges, alongside offers it calls SaaS subscriptions. Its categories describe options on that marketplace, not every possible way a business can earn revenue. AWS Marketplace’s SaaS pricing models make that distinction concrete.
There is a naming trap here. In ordinary business discussion, “subscription” often means a recurring payment for continued access. AWS Marketplace uses “SaaS subscriptions” for a pay-as-you-go offer billed on hourly usage. Those are different charging rules under a similar label. A seller comparing models should write down the chargeable unit and timing rather than infer them from the word “subscription.” The same AWS Marketplace description sets out the platform’s specific usage of the term.
Charge for continued access when the standing benefit matters
A recurring access fee is a strong starting point when the customer wants a capability available throughout a stated term. The customer can plan around the known base amount, and the seller can relate its commitments to the number of paying accounts. The term needs to be explicit: a monthly fee and an annual commitment can produce very different decisions for a customer who is still learning how much the product will be used.
The seller also has to specify what access includes. A fee per account may be simple until one account serves several teams. A fee per user can scale with seats, but it may invite the customer to limit seats if occasional collaborators need access. An organization-wide fee removes that seat decision, yet it can leave the seller serving much larger groups for the same amount. These are consequences of the chargeable unit, not claims that one unit always wins. The best unit is the one both parties can identify without an argument about who or what counts.
Suppose an illustrative service has 100 customers paying $80 for one month of access. The resulting monthly charge is $8,000 if every customer is billed for that month. Multiplying by 12 gives $96,000 only under the further assumption that all 100 customers remain at the same price for every month of the year. It says nothing about collection, refunds, costs, or profit. A model describes how amounts arise; the customer count and the price supply the arithmetic.
Recurring access can be a poor fit when most customers need the offer for one isolated job. The seller may still prefer the steady billing schedule, but customers are being asked to buy ongoing availability they do not expect to use. A one-time charge for a defined deliverable, or a charge when a discrete service is performed, may make the exchange clearer. The choice turns on the customer’s reason to return, not on a preference for a smooth-looking revenue chart. Stripe’s pricing materials list both one-time and recurring invoicing as capabilities, while listing recurring billing and usage billing separately; those are billing options, not a recommendation about any particular seller’s fit. Stripe’s public pricing page shows the distinction.
A recurring fee also needs a boundary. If the seller promises unlimited activity while its own work grows with every request, the customer’s bill stays flat as delivery demands rise. If the seller instead imposes a low allowance that surprises ordinary users, the advertised fee no longer describes the expected bill. Define what is included from a plausible customer workload, then state what happens outside it. A clear base fee can coexist with a variable component when neither pure access nor pure usage describes the offer well.
Use metered charging only when the unit can be trusted
Usage pricing charges against a measured and reported unit. AWS Marketplace lets sellers define billing dimensions for usage offers and describes categories such as users, hosts, bandwidth, data, tiers, and custom units. Those are platform examples, but they show why “pay for what you use” is incomplete as a commercial promise: someone must define what use means and how it is counted. AWS Marketplace’s usage-pricing documentation describes the dimensions and reporting process.
For the customer, a good unit follows an action or result they can recognize. “Per completed report” is easier to check than “per processing event” if several invisible events are required to produce one report. For the seller, the unit must be countable in a repeatable way. The definition should settle whether a retry counts, whether a failed attempt counts, when the period closes, and how a customer can review the count. These questions become part of the commercial offer because each answer changes the bill.
Metering can align payment with activity, especially when accounts use very different amounts. It also transfers some uncertainty into the customer’s budget. A customer who cannot estimate future use may delay adoption or cap use of a product they otherwise value. That is why a usage offer should show the unit, rate, expected examples, and a way to see accumulating charges before the invoice arrives. The seller must weigh the more activity-sensitive bill against the effort of recording usage accurately and explaining the result.
For an illustrative calculation, suppose 100 customers each generate 400 billable units in a month at $0.20 per unit. The monthly charge is 100 × 400 × $0.20, or $8,000. That equals the earlier access-fee example only because the assumptions were chosen to make it so. If half the customers generate 100 units while the other half generate 700, the aggregate is still 40,000 units and $8,000; the individual bills, however, are $20 and $140. The seller should therefore look at the distribution of customer bills, not just the total.
Usage billing has an operational cost that a model diagram can hide. AWS Marketplace says its metering service requires sellers to report usage records and warns that it cannot bill for usage when transmission or receipt of records fails. That is a platform-specific rule, but it illustrates a general design question: can the seller produce a reliable record for each charged unit? The AWS usage-pricing documentation states that reporting requirement. A unit that cannot be recorded consistently is a weak foundation for a bill, however appealing the rate looks in a presentation.
The choice can reverse if activity is expensive to measure, if customer use is too erratic to budget, or if the counted unit is distant from the benefit the customer sees. In those conditions, a base access fee, a defined package of included activity, or a contract with agreed capacity may be easier to buy and operate. The point is to put variability where both sides can understand it.
Charge per transaction when the event is the product
Transaction pricing is a close relative of usage pricing, but its unit is a qualifying exchange or event. A payment service, for instance, can charge when an eligible payment is processed. Stripe’s public pricing page presents charges associated with payment transactions; the published rates depend on the payment conditions and can change. Stripe’s pricing page is an example of the mechanism, not a universal price for transactions.
The word “eligible” matters. A seller needs to say whether the charge arises when a transaction is attempted, authorized, completed, settled, or refunded, as applicable to its offer. A customer planning costs needs the same definition. If the model is a percentage of transaction value, the seller also has to state which value is the base for the calculation. If it is a fixed amount per event, small and large transactions produce the same fee from that component. Those choices alter the customer’s cost pattern even when the headline model remains “per transaction.”
As an illustration only, 2,000 eligible transactions at an assumed $0.40 per transaction produce $800 in charges for a period. At an assumed 1% of a $50 eligible transaction value, the charge would be $0.50 per transaction and $1,000 across 2,000 transactions of that size. Neither assumed rate describes Stripe or any real offer. The comparison shows why a revenue model must state both the event and the formula before anyone can forecast its result.
Per-transaction charging is clearest when the event is central to what the customer buys and the seller can define its boundaries. It is weaker when the transaction is merely an internal step toward a larger outcome. Charging for every intermediate event can make the bill rise because a workflow is inefficient rather than because the customer gained more. A customer would then have reason to scrutinize the seller’s process instead of the service received.
Let contracts describe commitments, not conceal the meter
A contract is often treated as a separate model, but it can play two roles. It can set a term and amount for access or capacity. It can also set the commercial framework within which extra usage is billed. AWS Marketplace describes SaaS contracts whose buyers pay for the contracted software and can pay for additional usage; it also describes contracts with pay-as-you-go metered charges on top of the contract price. AWS Marketplace’s SaaS model guide shows both configurations.
This combination can be sensible when the seller must reserve capacity or provide continuing service while the customer’s activity varies. The base payment supports the standing commitment; the variable component addresses activity outside it. The customer gets a known starting cost without pretending that unusually heavy use has no consequence. The cost of this design is a more complicated agreement and invoice. It should say what the base covers, when extra charges start, how the extra unit is counted, and whether the customer can predict those charges while using the product.
Consider an illustrative offer with 100 customers paying a $50 monthly base and generating a combined 20,000 extra billable units at $0.10 each. The amount charged for the period is $5,000 in base fees plus $2,000 in usage fees, or $7,000. That total depends on the stated customer count, period, units, and rates. It does not tell us whether the arrangement is attractive to customers or profitable to deliver. Those questions require facts about customer budgets, use patterns, costs, and the alternative offer.
Minimum commitments can also disappoint when they are set above the amount a new customer can confidently use. The seller gains a promised base amount, but the customer is asked to take on unused capacity. In the reverse situation, a contract with no meaningful limit on included work can leave the seller with a fixed payment and a growing delivery obligation. A good agreement makes the ordinary case easy to understand and gives both parties a workable rule for the unusually small or large case.
Multiple revenue streams are useful only when each has a job
One business can receive money through more than one mechanism. Salesforce, for example, reports subscription and support revenue separately from professional services and other revenue in its financial results. That reporting shows distinct revenue categories in one company; it does not tell another company which mix to choose. Salesforce’s quarterly results provide the company-specific example.
The practical question is why the second charge exists. If a customer pays for software access and also needs a defined setup project, a separate service fee can make the scope and cost of that work visible. If the setup is routine and necessary for every customer, an extra mandatory fee may make the advertised access price less informative. If the seller charges a base fee and an overage, each part should map to a different commitment. Adding lines to the invoice is useful only when it clarifies who pays for what.
Distinct streams should be examined separately before being combined into a total. A service fee may be paid once, while an access fee may recur; a transaction charge rises and falls with qualifying events. Treating all three as interchangeable obscures what must happen for next period’s revenue to appear. A business describing its model should say which payments require a new sale, which depend on continued access, and which depend on measured activity. That description is more useful than declaring the company “hybrid” and stopping there.
The mix also affects customer decisions. A low entry fee with many conditional charges can feel inexpensive at sign-up but expensive at ordinary use. A higher inclusive fee can be easier to budget, yet unattractive to customers who expect little activity. Neither presentation is inherently fairer. Compare bills for a light, typical, and heavy customer using the same stated assumptions. If the typical bill cannot be explained before purchase, simplify the offer or make the variable component more visible.
Do not confuse the model with the price, the bill, or profit
“$80 per month” combines a model with a price. “Per month” gives the term; $80 gives the amount. “$0.20 per unit” combines a usage model with a rate. Changing $80 to $100 changes the price but leaves the access-based model intact. Changing from a monthly account fee to a per-unit charge changes the model, even if an illustrative customer happens to pay the same total in one month.
A bill also reflects facts beyond the model: how many customers were active, which units were counted, which events qualified, and which period is being charged. Two sellers using the same model can receive different amounts because their prices and activity differ. Two customers under the same offer can pay different amounts if one crosses a stated usage threshold. A useful revenue estimate therefore states the commercial period and uses a denominator for each part of the calculation: customers, accounts, seats, units, or transactions as applicable.
Profit needs another set of facts. An access fee may be easy to forecast but costly to serve. Usage revenue may rise with activity while the cost of providing that activity rises faster. A service fee may cover skilled labor or fail to cover it. The revenue model alone settles none of these outcomes. Before choosing a model because it appears to increase revenue, compare the expected charge from a customer with the work and other costs required to make that offer available to the same customer.
Cash timing and commercial terms also deserve separate attention. A contract can establish a term while specifying a payment schedule; AWS Marketplace notes that buyers of SaaS contracts can be billed in advance or through a flexible payment schedule. AWS Marketplace’s contract description supports that narrow point. The timing of a payment should be stated alongside the charging rule, because a customer deciding whether to buy cares when money is due. It should not be mistaken for the rule that determines how much the customer owes.
Choose by tracing one customer’s bill
The most effective way to select a revenue model is to follow the customer’s experience from purchase to invoice. What capability or result is the customer buying? When does the customer receive it? What event can both parties observe? Which part of the seller’s commitment exists even when the customer does little? These questions narrow the choice more quickly than copying a competitor’s pricing page.
Begin with the simplest charge that represents the ordinary exchange. If the customer primarily wants an ongoing capability, start with a clear access fee and a stated term. If the customer buys discrete completed work, define the deliverable and the charge for it. If value and delivery load vary materially with a countable unit, test a usage charge. If each qualifying transaction is the service, define the transaction. Add a base commitment or an extra component only when it solves a real mismatch in the simpler offer.
Then test the proposed rule against three illustrative customers: one with light activity, one with the activity the seller expects most often, and one with unusually heavy activity. Write out each bill in full, including any included allowance and extra charges. Ask whether the customer could reproduce the number from records available to them. Ask whether the seller would still want to serve each customer at that amount. If either answer is no, the unit, threshold, or base fee needs another look.
Finally, examine the boundary cases before launch. What happens if a user is added partway through a term, a measured event fails, a transaction is reversed, or a customer uses more than the contract includes? The answers need not all be complicated, but leaving them unstated invites disputes at precisely the moment a customer is deciding whether the bill is trustworthy. A model is ready when the ordinary bill and the likely exceptions can be explained in plain language.
The strongest default is a charging rule that mirrors an observable part of the customer’s purchase and can be written in one sentence. Continued access, measured usage, eligible transactions, and contractual commitments are all workable mechanisms under the right conditions. Choose the mechanism only after naming the unit, term, and exceptions. Then set the price and check the expected bill against customer use and delivery cost. That sequence turns “revenue model” from a label into a decision a business and its customers can actually use.