SaaS pricing and packaging: how to decide what's in each plan.

Your sales team wants a one-off deal for a prospect who almost fits the Pro plan. Your product team just shipped a feature nobody knows which tier it belongs in. Marketing is still describing the Business plan with language from eighteen months ago. None of this is a pricing problem in the sense of "the number is wrong." It's a packaging problem: nobody has a shared, current answer to what actually goes into each plan and why.

Quick answer

SaaS pricing and packaging is the practice of deciding which features, usage limits, and support levels belong in each plan, and how those bundles map to the value a customer actually gets. Pricing sets the number. Packaging decides what that number buys. Most SaaS companies get this wrong not because they picked the wrong price, but because they never built a repeatable process for deciding what belongs where, so the plan lineup drifts further from customer value every time someone ships a feature or closes a deal.

What packaging actually is, and why it's not the same as pricing

Pricing and packaging get talked about as one phrase, but they're two different decisions. Pricing is the number: what a customer pays per seat, per month, per unit of usage. Packaging is everything that number buys: which features sit in Starter versus Pro, what counts as an add-on, where the usage cap kicks in, whether support response time is a plan differentiator or a separate line item.

A lot of pricing content answers "how many tiers should I have" or "what value metric should I bill on." Those are real, related questions, and Revvly has covered when usage-based pricing makes sense elsewhere. Packaging sits one layer above both: it's the decision about what goes inside the tiers you've already committed to, and how you keep that decision from going stale as the product changes underneath it.

OpenView's Kyle Poyar, who has surveyed more than 2,200 SaaS companies on their pricing practices, found that nearly four in five companies change their pricing at least once a year, and most change it multiple times a year. Packaging changes just as often, usually more quietly, because a new feature getting bolted onto an existing tier without a decision process doesn't feel like a "pricing change" the way a number does. It still is one.

How to actually decide what goes in each plan

Start from the user journey, not the feature list

The most useful framework here doesn't start with your feature list, it starts with how a customer actually moves through your product. Andreessen Horowitz partners Jennifer Li and Martin Casado, writing from years of advising bottom-up B2B companies, describe a common journey: casual, unpaid use, then individual professional use, then team use, then organization-wide use. The core argument is that packaging should map to that journey rather than being reverse-engineered from whatever features engineering happened to ship first. A feature earns its place in a specific tier because of who needs it at that stage of adoption, not because it was built in the same sprint as everything else in that tier.

This matters for subscription SaaS specifically because your billing platform usually only sees the transaction, not the journey. A customer upgrading from 5 to 40 seats, or crossing a usage threshold, is a packaging signal. If that signal lives in your product analytics tool while your plan definitions live in Stripe and your feature flags live in code, nobody making packaging decisions has the full picture in one place.

Separate "new tier" from "add-on" decisions

Not every new feature needs a new tier. A feature that most customers won't touch but a subset will pay meaningfully for is usually an add-on, not a packaging change to an existing plan. Kyle Poyar's 2026 survey of 230 B2B software and AI companies found that the single most common monetization complaint right now is "not enough expansion revenue," and that the two most common fixes companies reach for are adding a premium edition above the base tier and charging separately for add-ons that most customers don't need but some genuinely value. Both of those are packaging decisions before they're pricing decisions: you have to decide where the line sits before you decide what it costs to cross it.

The test that tends to hold up: if fewer than a fifth of customers on a plan would use a feature, it's an add-on candidate. If a majority would use it and it's core to the job the plan already does, it belongs in the base package.

Decide your value metric before you decide your tier count

Every packaging decision eventually runs into the same question: what's the unit that scales with value? Seats, usage, active workspaces, records processed, something else. Get this wrong and packaging becomes a patchwork of overrides, because the metric doesn't track what the customer actually gets out of the product. Poyar's OpenView research found usage-based pricing has grown from 23% of SaaS companies in 2014 to 39% today, closing in on seat-based pricing as the default.

That shift is a packaging shift as much as a pricing one: usage-gated plans need a completely different definition of "what's included" than seat-gated ones, because the boundary between tiers is measured differently.

Build in a review cadence, not a one-time decision

Packaging decisions made once and never revisited are the most common failure mode here. A plan lineup that made sense at $1M ARR usually doesn't at $10M ARR, not because the pricing was wrong, but because the customer base, the feature set, and the competitive set have all moved. OpenView's research found that only 4% of SaaS companies scored "Excellent" on pricing maturity, largely because most never built a repeatable process for revisiting it, while 44% scored as failing outright. A packaging review doesn't need to be a full pricing overhaul. It needs an owner, a cadence (quarterly is common for growth-stage companies), and a source of truth for what's actually in each plan today, not what a sales deck from last year says is in each plan. If you're not sure whether a candidate change is right, running it as a small, reversible pricing experiment before rolling it out to every account on a plan is usually cheaper than reversing a packaging mistake after the fact.

The trap: packaging that lives in five different places

Here's where packaging usually breaks down operationally, separate from getting the framework right. The plan definitions live in a pricing page. The actual entitlements live in application code or feature flags. The exceptions and one-off deals live in a spreadsheet or in Salesforce notes. The person who can answer "what does the Business plan actually include today" with confidence is often one specific person, and they're on vacation.

This is the same fragmented-stack problem that shows up across revenue operations more broadly: pricing and packaging decisions get made in a meeting, implemented by engineering weeks later, and never fully reconciled back to what's documented anywhere a customer-facing team can see. Every subsequent packaging decision then gets made against incomplete information, which is how plan lineups drift into the kind of inconsistency that makes sales reps improvise and support teams guess.

A modular pricing architecture, where tiers, usage limits, bundles, and add-ons are configured rather than hard-coded, closes that gap by making the catalog itself the source of truth. Revvly's pricing and packaging configuration lets a Product or Growth lead change what's in a plan, add a usage-based add-on, or run a regional price variant without opening an engineering ticket, and have that change reflected immediately in what customers are billed and what your team sees when someone asks what a plan includes.

A quick checklist before you touch your packaging

Before adding a feature to an existing tier, creating a new add-on, or launching a new plan, it's worth running through a short list:

If the honest answer to the last two questions is "nobody" and "we don't remember," that's the actual problem to fix before debating whether a given feature belongs in Pro or Business.

Frequently asked questions