How do you turn confusing SaaS packages into propositions customers understand?

You open a SaaS pricing page. There are three packages, and what separates them is a number: users, contacts, projects, API calls, transactions or credits per month. The first package includes a little. The second includes more. The third includes much more and costs considerably more.

Which one is for you?

Most buyers can only answer that by estimating how much they will use. They compare numbers instead of recognising themselves. When packages say nothing about who they are for, buyers default to the cheapest option, ask for a custom deal or quietly leave.

The problem is rarely the number of packages. It is that each package has a size, but not a purpose.

Three packages, and a commercial goal pointing the other way

I saw this recently while working as a consultant with a B2B SaaS company. Its product allowed businesses to process a specific type of transaction, either through a web portal or through an API built into their own workflows. Its packages were priced by the number of transactions included.

Prospects saw three packages on the website. Two were for the portal. One was for the API.

When I spoke to the product manager, he explained that the company wanted to sell mostly API. That was where customers gained the most value: transactions happened automatically within their own workflows, without interruptions and without someone having to log in to a portal and process each one manually.

Yet the packaging told a different story. Portal users had two options to choose from. API buyers had one, designed for very high volumes and clearly aimed at large enterprises.

The two portal packages differed only by the number of transactions included. Neither explained who it was for or which situation it was designed to handle.

The API package created its own problem. Many prospects wanted an integration but needed far fewer transactions than it included. To stop them walking away, sales reps reached for what the team called the "back-pocket package": an unpublished, lower-volume API option offered only when a deal looked at risk.

That back-pocket package was telling the company something important. There was a group of customers the public packaging did not recognise—and it was exactly the group the company most wanted to grow.

When packages differ only by volume, buyers can't see themselves

Volume-based tiers are common in SaaS because they are easy to build. Take one product, set three allowances and price them in steps.

But volume is an internal way of dividing the offer. Buyers rarely start by asking how many units they need. They start by asking what they are trying to achieve and how the product will fit into the way they work.

When packages answer only the first question, three things tend to happen:

• Buyers compare price per unit instead of value, which pushes them towards the cheapest option.

• Sales spends early conversations explaining the differences between packages instead of exploring the customer's problem.

• Off-menu deals become routine, and inconsistent discounting follows.

The packages exist, but they are not propositions. A proposition tells a specific customer what they can achieve and why this option has been designed for them.

Start with the customer, not the feature table

In this particular case, I based the recommendation on the company's ideal customer profile research, messaging work and competitor analysis, together with the outcomes the business wanted to achieve and the customers it wanted to serve.

Three questions guided the work.

1. Who are the customer segments, and how do they work?

The research pointed to organisations with very different needs. Some processed occasional transactions before onboarding a small number of high-value partners. Others needed to review large sets of existing records regularly. Others needed transactions processed automatically within onboarding processes that ran every day.

Each group had a different workflow, not just a different volume.

2. Which use case should each package serve?

Instead of asking how many transactions each package should include, I asked which situation each package should solve. That produced four clear use cases:

• Occasional individual transactions through the portal.

• Regular transactions and bulk reviews of existing records, still through the portal.

• Transactions processed within lower-volume onboarding workflows through the API.

• High-volume or business-critical transactions processed within operational processes, with more service and support.

Volume still mattered. But it became a consequence of the use case rather than the definition of the package.

3. Where does the value change between packages?

The biggest step up in value was not more transactions. It was the move from a person processing transactions manually to transactions happening inside the customer's own systems.

That was the transition the business wanted customers to make. The packaging needed to make it visible and easy to take.

Make the commercial goal visible in the package structure

Once each package has a clear customer, use case and step up in value, the structure itself can support what the business wants to sell.

A few principles help, whatever your product.

Recognise the segments your packaging leaves out. When sales reps regularly offer deals that are not on the website, they are compensating for a gap. Making that option visible gives those customers a clear way in, instead of relying on a rep to rescue the deal.

Balance the range with your strategy. If one route to value matters most to your growth, it deserves more than a single, high-threshold option. Customers need a realistic entry point and a clear way to grow.

Name packages after how customers work. Generic labels such as Basic, Plus or Pro say nothing about who a package is for. Names that describe what changes for the customer help buyers see where they belong.

Give every package a "best for" statement. Open each description by naming the customer and situation it is designed for, with examples of relevant use cases. Volumes and features follow as supporting detail.

Signal the recommended path. Highlighting the package you want most customers to choose, and making its price easy to understand, makes that step easier to take.

Select by need, not company size. A large organisation with a simple, low-volume need may still be best served by an entry package.

This follows the same principle I described in Why aren't existing customers buying more from you?: packages built around use cases help customers see why an option is relevant to them, not just what it includes.

Questions to ask about your own SaaS packaging

Before changing prices or adding another tier, ask:

• Can a buyer tell which package is for them within seconds, without calculating their usage?

• Does each package describe a customer and a use case, or only an allowance?

• Does the structure support the product you most want to sell, or work against it?

• Are sales reps regularly offering packages or deals that are not on your website? Which customer segment does that reveal?

• Where does value genuinely change between packages, and does the naming make that step visible?

• Can Product, Marketing and Sales explain who each package is for in the same way?

Packaging is positioning at the point of purchase

Packaging is often treated as part of the pricing exercise. In practice, it is where your positioning meets the buying decision. Every package should answer one question for the buyer: is this the option designed for me?

When the answer is clear, buyers choose faster, Sales spends less time explaining and the business can guide customers towards the offer it most wants to grow.

If your packages are clear but buyers still resist the price, read Why your SaaS pricing isn't working (and what it reveals about your product strategy).

At Ocean Wave Growth, I help B2B SaaS companies turn their packages into propositions customers understand, aligning segmentation, use cases and product value across Product, Marketing and Sales.

If buyers are struggling to choose, or your sales team keeps reaching for off-menu deals, book a conversation to discuss where to start.