Revenue Model Testing SOP

Revenue model testing tells you how to charge (subscription, per use, commission, one-time fee or free with paid upgrades) by putting real offers in front of real buyers. A test takes a week to set up and three to four weeks to run. The choice shapes everything downstream: cash flow, how you sell, which customers you attract and how investors value you. Founders tend to copy the model of the best-known company in their space; this SOP replaces that habit with a few weeks of evidence.

What is revenue model testing and when should you use it?

A revenue model is the mechanism that turns value into money. In Business Model Generation, Osterwalder and Pigneur list seven ways to generate revenue streams: asset sale, usage fee, subscription fees, lending or renting, licensing, brokerage fees and advertising. Most startups choose between three or four of these, plus hybrids such as freemium or a subscription with a usage allowance.

This SOP tests the mechanism. Its neighbours handle the rest: pricing sensitivity testing finds the right price level, and pricing model validation checks tiers and packaging against your financial model. Run this one first, because a price level only makes sense inside a model.

Use it:

• Before you scale acquisition, since switching models later means migrating every customer.
• When customers keep asking for a different way to pay ("can we pay per project?").
• When revenue per customer varies wildly and you suspect the model doesn't follow value.
• When building a marketplace or platform, where commission, listing fees and subscriptions all compete.

What do you need before you start?

• A product or a convincing offer that people can buy now or put down a deposit for.
• A flow of buyers: at least 300 pricing-page visitors a month, or 20+ sales conversations for B2B.
• A way to take payment for each model: Stripe and Paddle both support subscriptions, metered usage and one-time payments.
• Cost data per customer, so you can check margins under each model with unit economics validation.

How do you run it, step by step?

1. Find the value metric

Ask what grows when the customer gets more value: seats, projects, transactions, contacts, hours saved. Revenue models that charge along that line feel fair to customers. A tool for sending invoices has a natural value metric (invoices sent); a meditation app's value is closer to time, which suits a subscription.

2. Shortlist two or three models

Pick models that follow the value metric and that you can bill for today. Write each in one line: "€29 a month, unlimited", "€0.50 per reminder sent", "8% of each booking". Three is the maximum; more splits your traffic too thin to read.

3. Make the price levels comparable

Set each model so a typical customer would pay about the same over a year. If the subscription is €29 a month and a typical customer sends 50 reminders, the usage price is around €0.55 to €0.60 each. This way you test the model and not the price.

4. Choose the test method for your stage

Pre-launch or self-serve: split new visitors between two pricing pages with real checkout or a refundable deposit, using the fake door testing SOP when the product isn't ready. B2B with sales calls: alternate the model offered, call by call, and log each response. Live product: show new signups one model at random, and keep existing customers on their current plan.

5. Run until you have enough buyers

Aim for at least 300 visitors per model, or 10 sales conversations per model, and run whole weeks. Record every objection: "I don't know how much I'll use" is a signal against usage pricing; "I only need it twice a year" is a signal against subscriptions.

6. Follow buyers for 90 days

Conversion on day one only tells half the story. Track payments, cancellations, refunds and support complaints about billing for at least three months, or one billing cycle for annual offers.

7. Compare revenue per 100 visitors and decide

For each model, calculate revenue collected per 100 visitors or leads after 90 days, minus refunds. Add predictability (how much revenue per customer swings month to month) and gross margin per customer. Pick the model with the best mix, then hand it to pricing sensitivity testing to tune the level.

Template you can copy

Sales call log columns: Date | Lead | Model offered | Reaction (yes/no/later) | Objection in their words | Follow-up.

Worked example: an invoice reminder tool for accountants

This example is illustrative. A founder sells a tool that sends automatic payment reminders for small accounting firms. She tests two models on 600 new pricing-page visitors, split evenly: subscription at €29 a month and usage at €0.55 per reminder, the same yearly cost for a firm sending about 50 reminders a month.

Subscription: 18 of 300 pay (6%), 3 cancel after the first month. Revenue by day 90: €1,392, or €464 per 100 visitors. Usage: 30 of 300 pay (10%), 2 cancel, average bill €21 a month. Revenue by day 90: €1,806, or €602 per 100 visitors.

Objections explain the gap: small firms didn't want to pay full price in quiet months. Usage revenue swings more, so she adds a €15 monthly minimum for predictability and moves to pricing sensitivity testing to tune the per-reminder price.

What should you measure, and when do you stop?

Stop when each model has 300+ visitors or 10+ sales conversations and 90 days of payment data. If no model leads by 15% or more, choose the simpler one to explain and bill, and move on: the price level will matter more than the model.

Which mistakes should you avoid?

• Testing model and price at once. A cheap subscription against an expensive usage plan tells you about price, not mechanism.
• Judging on day-one conversion. A model that converts well and churns in month two loses.
• Copying a famous company's model. Their customers, costs and value metric differ from yours.
• Ignoring cost to serve. Unlimited subscriptions attract your heaviest users first.
• Switching existing customers mid-test. Test with new buyers and keep current customers on stable terms.

How can AI speed this up?

Describe your product and customers to an AI assistant and ask it to suggest value metrics and three revenue models that follow them, with the risks of each. Ask it to calculate comparable price levels and to model 12-month revenue per 100 visitors from your test data. Check its assumptions on usage: AI fills gaps with averages from other products, and your customers' real usage spread is what decides margins.

The free business plan generator puts the chosen model into a full plan, and the F/MS investor playbook module explains how investors read different revenue models.

Where does this SOP fit in your validation plan?

Revenue model testing follows business model canvas validation, where the revenue block is flagged as a risk. Next steps:

1. Tune the price level with pricing sensitivity testing.
2. Check tiers and packaging with pricing model validation.
3. Confirm margins per customer with unit economics validation.
4. Estimate long-term revenue per customer with customer lifetime value analysis.

See all Business Model Validation SOPs.

FAQ

What is the difference between a revenue model and a pricing model?

The revenue model is the mechanism (subscription, usage, commission, one-time fee). The pricing model sets the levels, tiers and packages inside that mechanism.

How do I test which revenue model works best?

Offer two or three models at comparable yearly cost to similar groups of new buyers, track payments and cancellations for 90 days, and compare revenue per 100 visitors or leads.

Is subscription or usage-based pricing better for a startup?

Subscription gives predictable revenue and suits products used steadily. Usage-based pricing suits products whose value rises and falls with activity. Test both when customers' usage varies widely.

How long should a revenue model test run?

Three to four weeks to collect buyers, then 90 days of payment data to see churn and refunds.