Seven things a customer can pay for.

Ask a SaaS founder how they price their product and you’ll often hear, “We charge per seat, billed annually.”

That tells me how they count customers and when they collect the money. It doesn’t tell me what the customer is paying for. And I think that missing question causes a lot of confusion.

I’ve been looking at common pricing approaches across different industries. My working theory is that customers ultimately pay for seven kinds of things, or a mix of them. It’s a broad claim, so here’s how I got there.

Pricing involves three different decisions

People often talk about pricing as though it’s one decision. In practice, I see three:

Decision	The question	Examples
How much?	How do you set the price?	Costs, customer value, competitors
What for?	What does the customer receive?	Access, work, deliverables, results
When?	When does money change hands?	Upfront, monthly, at milestones

For instance, a company might set prices based on customer value, charge for access per user and collect a year in advance. Those are three separate choices.

I want to focus on the second one: what the customer actually buys.

How I got from 40 labels to seven

I started with roughly 40 familiar labels: subscriptions, retainers, usage-based pricing, per-seat fees, commissions, time and materials and plenty more.

But a lot of those names describe different parts of the same deal. A subscription tells you that payment repeats. A tier describes how you package the offer. A volume discount changes the price. None of those necessarily tells you what the seller has promised to provide.

Once I separated those ideas, the list got smaller. I then used one question to test each category: what must the seller do to earn the payment?

Take advertising. Renting billboard space is access. Paying for a set number of views is paying for a delivered output. Paying for a sale is paying for an outcome. The industry stays the same, but the thing being sold changes.

Marketplaces work the same way. A listing fee buys access to the marketplace. A commission becomes payable only when a transaction happens, so that’s an outcome.

That exercise left me with seven categories. I’m not claiming the list is beyond challenge. If someone can make a convincing case for an eighth, I’d rather improve the framework than defend the number.

The seven things customers pay for

The first three give customers something they can use to create value themselves. The other four involve the seller doing work, delivering something, producing a result or taking on a defined risk.

What customers buy	What the seller promises	A familiar example
1. Ownership	Hand over the item or property	Equipment, materials, a building
2. Access	Make something available and maintain it	SaaS, hosting, rentals
3. Permission	Grant a right or agree not to interfere	Licences, exclusivity rights
4. Effort	Perform work, regardless of the outcome	Hourly work, AI tokens
5. Output	Deliver something that meets an agreed specification	A report, logo, fixed-scope build
6. Outcome	Achieve a specific result	Sales commissions, pay-per-sale ads
7. Protection	Cover a defined loss or failure	Insurance, warranties, uptime guarantees

Some of these can sound similar. The difference becomes clearer when you look at what the seller actually owes the customer.

Access versus permission: with SaaS, the vendor keeps the software running, updates it and fixes issues. That’s access. With a traditional licence that only grants the right to use software, the main promise may simply be permission to use it without legal interference.

Effort versus output: pay a developer hourly and you pay for the work, even if it takes longer than planned. Agree on a fixed-scope build and you pay for something that meets a defined specification.

Output versus outcome: a report can meet every requirement and still fail to improve the business. The report is an output. A measurable improvement, such as a completed sale, is an outcome.

Outcome versus protection: with an outcome fee, you pay when something goes right. With protection, you pay for coverage if something goes wrong.

Why seats, usage and subscriptions are missing

You might have noticed that per-seat, usage-based (opens in a new tab) and subscription pricing aren’t among the seven. I left them out on purpose.

They usually describe how we count, how we package or when we collect payment, rather than what we sell. A seat can measure software access. Tokens can measure an AI system’s effort. Litres can measure how much fuel changes hands. A subscription tells you the payment repeats.

A hybrid offer simply combines categories. For example, a retainer plus a success fee combines effort and outcome. A SaaS platform with seats and overage charges may still be selling access, just measured in two different ways.

Why taking on more responsibility can change the price

Now put the seven categories in order of how much responsibility the seller takes for creating value.

With ownership, access and permission, the customer still has to turn what they’ve bought into something useful. With effort, the seller does the work, but the buyer typically directs it. With output, the seller promises a finished deliverable. With outcome, the seller commits to a result. Protection is different: the seller takes on the downside if a defined problem occurs.

That shift matters because it changes what customers compare your price with.

Customer pays for	What they’re likely to compare
Ownership, access or permission	Alternatives and replacement costs
Effort	Hourly rates and labour costs
Output	Similar completed projects
Outcome	The result’s value to the business
Protection	The potential loss and cost of coverage

Imagine the same developers working on the same software. Bill hourly and a customer compares you with other developers’ rates. Sell a finished system for a fixed fee and they compare the deliverables. Tie payment to a business result and they look at what that result is worth.

That doesn’t mean you can simply move to outcome pricing and charge more. Customers may pay a premium when you take on risk they would otherwise carry, but you also have to accept the risk of not getting paid. And you need to agree on exactly what counts as success.

It also helps explain why SaaS companies worry so much about churn. A customer can buy access, barely use it and get little value. If that keeps happening, they’ll cancel.

One objection worth taking seriously

There’s a fair challenge to this framework: couldn’t an outcome fee simply be effort plus protection?

Think about a lawyer who only gets paid after winning a case. The lawyer does the work and takes the risk of losing. It’s tempting to treat that as two categories instead of one.

But if we use that logic consistently, output starts to disappear too. A fixed project fee could just be effort plus the risk of running over budget. Soon the framework stops describing what customers buy and starts describing who carries the risk.

I find it more useful to ask what triggers payment. For an outcome fee, it’s the agreed result. The risk follows from that commitment.

There are still grey areas. Labour hire and managed services, for example, can sit between access and effort. My practical test is who directs the work. If you use someone else’s machine to run your own processes, that looks like access. If their team or system performs the work for you, that looks more like effort. It won’t settle every case, but it helps.

A simple test for your own pricing

Try describing your offer without using the words “subscription,” “per seat” or “usage-based.” Instead, answer three questions:

1. What does the customer pay for? Access, effort, an output, an outcome or something else on the list?
2. How do you count it? Users, hours, projects, transactions or another unit?
3. When does the customer pay? Upfront, monthly, at delivery or after a result?

Then ask what would happen if you took responsibility for one more part of the customer’s result. Could hourly work become a fixed-scope deliverable? Could an access subscription include a clearly defined performance commitment?

You don’t need to change your entire service to change what you promise and how customers judge its value. But you do need to be precise about that promise.

My view is simple: if you can’t clearly explain what the customer is paying for, you may have a price, but you haven’t fully explained your pricing model.

What does your main offer actually sell? And does your pricing make that clear?