Revenue Streams: What Goes in This Business Model Canvas Block

Revenue Streams is where the Business Model Canvas stops being a description and starts being a business. Eight of the nine blocks explain how you create and deliver value. This one explains how you get paid for it.

What the Revenue Streams block means

The Revenue Streams block captures the cash a company generates from each customer segment: what customers pay for, through what mechanism, and whether the money arrives once or keeps arriving.

Two clarifications keep this block honest. First, it is revenue, not profit. Costs are subtracted elsewhere, in the Cost Structure block at the bottom-left of the canvas. Second, it is per segment. Alexander Osterwalder’s line is that if customers are the heart of a business model, revenue streams are its arteries. Each artery runs from a specific segment. A revenue line that cannot be traced to a named group of paying customers is a hope, not a stream.

What goes in the block

A well-filled Revenue Streams block contains three things, not just a price.

1. The revenue mechanism for each segment. There are seven standard mechanisms:

2. The pricing mechanism. Fixed pricing (list price, feature-dependent, segment-dependent, or volume-dependent) versus dynamic pricing (negotiation, yield management, real-time markets, auctions). An airline and a bookstore can both use asset sales, but one prices dynamically and the other does not, and that difference shapes the entire operation.

3. The stream type and its weight. Is each stream one-time transaction revenue or recurring revenue? And roughly what share of total revenue does each contribute? Professionals annotate percentages next to each stream. A canvas that says “subscriptions 85%, services 15%” tells a reviewer far more than a list of stream names.

The guiding questions professionals ask

Facilitators and consultants push teams through a specific sequence of questions here. Use them as a checklist:

• For what value are our customers really willing to pay? For what do they currently pay?
• How are they currently paying? How would they prefer to pay?
• How much does each revenue stream contribute to overall revenues?
• What are customers paying for: the product, or what it enables?
• If we doubled the price, would anyone still buy? Who? (This is a price-sensitivity probe, not a pricing proposal.)
• Is this one-time or recurring revenue? What would make it recurring?
• Who exactly pays: the user, an employer, an advertiser, an insurer?

That last question catches more broken models than any other. In advertising businesses, two-sided marketplaces, healthcare, and B2B2C products, the user and the payer are different people, and the canvas must name the one who writes the check.

Three concrete examples

Netflix: a subscription core with deliberate layers

Netflix’s Revenue Streams block is a masterclass in stacking mechanisms on one asset base. The core is tiered subscriptions (ads, standard, premium), roughly $39 billion in revenue in 2024: recurring, monthly, and price-laddered so average revenue per user can rise without losing budget-conscious viewers. On top of that sit advertising on the $6.99 ad-supported tier (small today at low single-digit percent of revenue, but structurally higher-margin per viewing hour), extra-member fees that monetize the password-sharing households surfaced by the 2023 crackdown, and early-stage licensing and consumer products around its franchises.

Note the price ladder logic: the ad tier captures viewers at about $7 while premium subscribers pay around $25. That is segment-dependent pricing applied deliberately, and the periodic price increases (the standard plan roughly doubled from 2014 to 2025 with retention intact) are the proof of pricing power. The full breakdown is in our Netflix business model canvas example.

A B2B SaaS company: subscription plus expansion

A typical project management SaaS fills the block like this: per-seat subscription fees ($15 per user per month, fixed, feature-dependent across three tiers) as the dominant stream at perhaps 90% of revenue; one-time implementation and onboarding fees for enterprise accounts; and an annual-prepay discount that trades 15% of price for twelve months of cash upfront. The stream type annotation matters: the subscription is recurring, the onboarding fee is one-time, and the canvas should show both so nobody mistakes a services spike for durable growth. Who pays? The employer, not the user, which is why the enterprise tier can carry a price the individual tier never could.

A two-sided marketplace: transaction fees with a take rate

A freelance-services marketplace earns brokerage fees: a 10% commission on each transaction, charged to the freelancer side, plus a smaller payment-processing margin on the client side. Revenue is technically recurring only if the matched parties keep transacting on the platform, which is why mature marketplaces add subscription streams (premium seller profiles, promoted listings) to convert episodic transaction revenue into predictable monthly revenue. The block should name both segments and show which one carries the take rate, because “who absorbs the fee” is a strategic choice, not an accounting detail.

Common mistakes (and the fix for each)

Mistake 1: Confusing price with revenue model. Teams write “$49” in the block and move on. But $49 as a one-off sale, a monthly subscription, and a usage-based average are three different businesses with different cash flows, sales motions, and valuations. Defaulting to one-off sales also blinds teams to subscription and usage-based opportunities. Fix: choose the mechanism first, from the seven listed above, then attach a price to it. If you can delete the number and the block still describes how money arrives, you have done it right.

Mistake 2: Assuming willingness to pay without evidence. “Customers will pay $20/month” is the single riskiest untested assumption on most canvases. It feels like a fact because it is written in a box. Fix: treat every payment claim as a hypothesis and run a cheap test before building: pre-orders, signed letters of intent, or a fake-door pricing page that measures how many visitors click “Buy.” A guess with a test plan is a fine canvas entry. A guess presented as a fact is not.

Mistake 3: A single fragile stream, unlinked to segments. Two versions of the same failure: revenue that is not attributed to any specific segment, and 100% dependence on one stream (commonly “we’ll run ads”) with no plan for the segment that actually pays. Fix: draw an explicit line from each stream to a segment in your Customer Segments block, and if one stream carries everything, write down the trigger that would force you to add a second.

How Revenue Streams connects to the rest of the canvas

Revenue Streams sits at the bottom-right of the canvas, and its position is the point. The right side of the canvas (Segments, Value Propositions, Channels, Relationships, Revenue Streams) is the value-creation side; the bottom row is the financial ledger. Cost Structure sums what the left-side infrastructure costs, Revenue Streams sums the value captured from customers, and viability is the simple comparison: revenue streams must exceed cost structure, at least eventually.

The consistency check reviewers run on this block: every revenue stream must come from a specific segment paying for a specific value proposition. If you cannot draw both arrows, the stream does not belong on the canvas. This is also where change propagates. Swap your customer segment and your revenue mechanism usually has to change with it, because how a consumer prefers to pay and how a procurement department prefers to pay are rarely the same.

Where it appears in the fill order

Revenue Streams is block 5 of 9 in the recommended fill order: Customer Segments, Value Propositions, Channels, Customer Relationships, then Revenue Streams, before you cross to Key Resources, Key Activities, Key Partnerships, and Cost Structure. The logic is “value before infrastructure before finances.” You cannot answer “what will they pay for, and how?” until you know who they are and what value they receive, and you should not design operations until you know how the model earns.

If you are working through the sequence, our guide on how to fill in a Business Model Canvas walks all nine blocks in order, and the free canvas templates give you a printable or editable grid to work in. When you get to testing whether the numbers actually clear the viability bar, that is a spreadsheet job: the revenue and break-even models in the Complete Toolkit exist for exactly that step.

Fill this block last on the right side, annotate each stream with its mechanism, its type, and its rough share, and trace every one back to a paying segment. That is the difference between a canvas that describes a product and one that describes a business.