How to design SaaS packaging: a practical guide in three questions

Across more than 150 pricing projects, I have watched one part of the work confuse people more reliably than any other: packaging.

Price levels feel like a question with a correct answer somewhere out there, waiting to be found. Discounting feels like a discipline problem, which it mostly is. Packaging is often treated as a matter of taste, which makes it hard to agree on anything without shared criteria for comparing the options.

Packaging involves many connected decisions: which segments to serve, which of their needs to prioritise and which features and services to offer each of them. That means saying no repeatedly, often to options that colleagues support. Working through those decisions takes a high tolerance for disagreement, and I suspect this is one reason teams move on to redesigning the pricing page before they have agreed on the offer itself.

The frame I use comes from ecology rather than from pricing. Designing packages is closer to stocking a habitat than to designing a product. A forest does not decide what grows in it. It supports certain species, and the ones that find what they need stay. Every package you design is a decision about which species you are willing to feed, and which ones you are quietly telling to go somewhere else.

Why packaging deserves the effort

In November 2025, McKinsey published an analysis of what separates the most valuable B2B SaaS companies from the rest. Companies in the top quartile by valuation multiple reached net revenue retention of 113%, which means they grow 13% a year from existing customers without winning a single new one. Companies in the bottom quartile reached 98% and shrink slightly.

In a separate survey of leaders at 98 B2B SaaS companies, McKinsey compared practices against net revenue retention. Companies with best-in-class pricing and packaging practices ran roughly 16 percentage points higher retention than peers with only basic ones, the largest uplift among the practices it quantified. Sophisticated value realisation, for comparison, was worth about seven points.

Hold those two numbers next to each other. The gap associated with good pricing and packaging is about the size of the entire gap between the most and the least valuable companies. A survey cannot prove that fixing your packaging moves you from one quartile to the other, but it does show that this is one of the largest measured levers on the metric that separates them.

Who this guide is for

Initial packaging is often based on the founders' intuition, competitors' plans and a few loosely structured conversations with prospects. Once the product reaches product-market fit, that structure can work well enough to support growth. Customers are buying, and there is little immediate pressure to reconsider the packages.

As the company grows, its customer base changes. The packages often stay the same, leaving customers with different needs and willingness to pay on the same plan. Because the existing structure still generates sales, the potential benefits of improving it are easy to overlook.

This guide is for B2B software companies with product-market fit and an established customer base. It is written primarily for teams with sales and customer success functions. Your customers, won and lost deals, upgrades and cancellations provide the evidence you need.

Many teams try to shortcut the work by copying a pricing page they admire. That hands you the shape without the reasoning that produced it. The three questions in this guide are that reasoning:

1. Which species actually live here? Which customer groups have needs and priorities that your packaging should reflect?
2. What does each species eat right now? Which features and services matter to each group, and which of them belong in each package?
3. What makes one of them migrate? Which events move a customer from one package to the next?

Answer all three and you can draw your pricing page without the prices. A short final section covers the choice of overall structure, such as tiers or a base product with modules.

How to use this guide

Each chapter is a sequence of steps, and most steps come in two versions.

Guerrilla is the faster and cheaper approach, with more risk of getting things wrong. It relies on data you already have and a few hours a week from people already on the payroll.

Expedition is for teams that want more certainty before they change anything. It builds on the guerrilla work with paid research or deeper analysis, and you need someone who can design the research and interpret its results.

You can combine the two, investing in more research only where a decision warrants it. Each chapter states how long both approaches usually take.

How much data you have changes what works. With fewer than 50 customers, treat your internal analyses with extra caution and rely more on conversations with customers. Each chapter adds its own caution where it depends on a particular kind of data.

Throughout the guide, boxes headed "Worked example" follow a fictional company called Vanrota through every step. Vanrota and all its numbers are invented for illustration. The value of the example is in the reasoning, so read its answers as one possible outcome rather than as a template to copy.

Worked example: meet Vanrota

Vanrota is a fictional B2B software company for field service businesses: plumbing, heating and electrical contractors. Its product covers job scheduling, a mobile app for technicians, invoicing and payments. It has been selling since 2018, has around 1,500 paying customers and about €9 million in annual recurring revenue, and charges per technician per month.

Its three packages, Starter, Pro and Enterprise, were created years ago by dividing the feature list. In 2025 Vanrota launched two AI features, job reports written from technicians' voice notes and a chat assistant, and placed both in Pro to encourage upgrades. A year later, few customers had moved to Pro, most of the cost of running the AI features came from a small group of large accounts, and enterprise prospects regularly received single sign-on as an exception in negotiations.

Chapter 1. Which species actually live here?

The first question is which customer groups have needs and priorities that your packaging should reflect.

In most of our projects, the team walks into the first workshop convinced it serves three segments, usually the same three that marketing uses for its personas. By the time we finish with the data, we typically count six to eight groups that value the product in meaningfully different ways. When the packaging gets rebuilt around those groups, we have seen revenue grow by 15 to 20%, mostly without building anything new.

A distinct segment does not automatically require a separate pricing plan. The purpose of this chapter is to identify the differences that should influence your offer.

For this chapter, a small team can get through the guerrilla approach in two to three weeks. The expedition approach adds paid interviews, a respondent panel and a survey tool. Plan for six to eight weeks.

Step 1. Identify candidate segments

Different teams often have different views of which customer segments the company serves. Gather those perspectives and turn them into a shared list of potential segments to assess.

Guerrilla: Schedule a 60-minute session with the founder, one or two sales representatives and someone from customer success. Each participant independently lists the types of customers they work with, using concrete characteristics: industry, company size, purchasing decision-maker, previous solution and the trigger for seeking an alternative.

Review the lists together. Ask participants to explain each group and identify customers who belong to it. Combine entries that describe the same customers under different names. Where groups overlap, determine whether they represent distinct segments or different characteristics of the same customers.

Agree on a name and short definition for each group. Use specific criteria, including employee ranges where relevant, and record disagreements as questions to investigate. Aim for roughly five to ten candidate segments.

Expedition: Run the same session, then export all won and lost sales opportunities from the past two years. Include industry, company size, buyer roles, sales cycle length and annual contract value: the agreed yearly amount for wins and the proposed amount for losses. For won deals, add subsequent cancellations, reductions in spending or expansion where available.

Assign each opportunity to a candidate segment, flagging ambiguous cases. Compare the number of opportunities, win rate, total and average annual contract value of wins, and sales cycle length. Review subsequent customer behaviour to assess retention and expansion.

Use these results to prioritise groups for further investigation. They describe your sales history; markets you have rarely approached may need additional research.

Industry and company size help organise the search, but they do not establish that customers have similar needs or value your product in the same way.

Step 2. Find differences in needs and value

Now investigate which aspects of your product different customers value, why those priorities differ and how that affects their buying decisions. An outcome that matters equally to everyone will not help distinguish segments, even if it is essential to the product.

Guerrilla: Start with the candidate groups from step 1. Compare your top 20% of accounts by current annual recurring revenue with the rest: what they bought first, what they expanded into and who owns the relationship on their side. Review your last 30 win/loss notes by buyer roles and the alternatives considered.

Run 8 to 12 switch interviews with recent buyers across your candidate groups. A switch interview reconstructs, step by step, how a customer went from being fine with their old way of working to signing with you. Ask what prompted the search, what they used before and what they would do if your product disappeared. Explore their budget, the paid alternatives considered and how price affected the decision. Focus on actual purchasing decisions and requirements, rather than asking for a feature wish list.

Expedition: Conduct 20 to 30 interviews, deliberately including lost deals and churned customers, with a budget for incentives. Use the findings to design a survey for 150 to 300 respondents drawn from your customers and your target market through a research panel.

Include a MaxDiff exercise on 12 to 20 outcomes your product delivers. Respondents repeatedly choose the most and least important outcome from small sets, revealing their relative priorities. Add willingness-to-pay questions about a clearly described offer and the customer characteristics from step 1.

Tools with segmentation features can propose groups of respondents with similar priorities. Review these groupings for clarity and commercial usefulness, then compare them with your original candidate segments. Use the findings to revise your definitions, merge similar groups or investigate differences within them.

Step 3. Assess the segments for packaging

Step 1 provided the initial groups; step 2 supplied evidence to refine them. Now assess which groups justify different packaging decisions using five checks.

1. Can you identify them early? Use observable characteristics or straightforward questions, ideally on the demo request form or by the end of the first sales call. If classification is unreliable, the definition needs more work.
2. Do they need different capabilities or more of the same? Distinct priorities may justify different features or services. Higher volumes alone can usually be addressed through your pricing metric.
3. Does their willingness to pay differ? Use the interviews or survey to assess this. Differences may support distinct pricing, but similar willingness to pay does not rule out separate packages when needs differ.
4. Is the opportunity substantial enough? Assess whether the customers and potential revenue justify the work of creating, selling and maintaining an offer for the group.
5. Can you serve them well and profitably today? Consider your current product, team and the onboarding, support and ongoing service required.

Guerrilla: Reconvene the participants from step 1. Score each group on each check: 1 = does not meet the condition, 2 = uncertain or partly meets it, 3 = clearly meets it. Record the evidence and assumptions behind each score.

A score of 1 on the first check means redefining or setting aside the group. Use the scores to structure the discussion, rather than treating the total as a ranking. A high score elsewhere cannot compensate for an inability to serve the group profitably.

Expedition: Use the sales data, interviews and survey results already collected to support the assessment. Add estimates of support workload, customer success time and substantial product usage costs. Keep uncertain segments provisional and record what needs validating.

Step 4. Merge and prioritise

Review the groups together. Merge those with sufficiently similar needs, buying economics and service requirements that separating them would not change a packaging decision.

For each remaining group, choose one of three approaches:

• Prioritise: design your packaging around its requirements.
• Accommodate: serve it through your existing offer, without additional development or customisation.
• Decline: decide which requirements or commercial terms you will not support. Set minimum contract values, price floors or limits on sales effort accordingly.

This discussion can become tense when a proposed decision affects customers someone wants to retain. Record the reasons and trade-offs behind each choice so the team can apply the same criteria to future opportunities.

Step 5. Write segment cards and test them

Give each segment a one-page description: its name, early identification criteria, buying trigger, main customer objective, alternatives considered, distinctive priorities, evidence about willingness to pay, share of revenue and pipeline, and the decision from step 4.

Guerrilla: Ask two sales representatives who did not write the cards to independently classify your last 20 closed deals. Give them only the information available by the end of the first sales call. If they disagree on more than one deal in four, refine the definitions in step 3.

Expedition: Classify at least 100 sales opportunities, including wins and losses. Check whether the groups differ in needs, buying behaviour, willingness to pay or service requirements in ways that would change your packaging decisions. Compare annual contract value, win rate, churn and expansion as supporting evidence, using won customers for the post-sale measures.

Similar historical results do not invalidate a segment: the current offer may have concealed differences in what customers need and would buy. Where the distinction remains uncertain, test it through further buyer research before committing to a separate package.

Worked example: Vanrota's segments

Vanrota's team expected three segments based on the number of technicians: small, medium and large customers. The session in step 1 produced seven candidates, and the evidence from steps 2 to 4 reshaped them:

Owner-operators (one to five technicians; the owner schedules jobs from a phone): Prioritise.

Growing contractors (usually six to 30 technicians, with a first office employee who runs the schedule): Prioritise.

Multi-branch service companies (two or more branches; the operations director and IT take part in the purchase): Prioritise.

Commercial maintenance contractors (planned maintenance for commercial clients under service contracts): merged with multi-branch companies, because they need the same audit trail, permissions and standardised job reports.

Emergency call-out specialists (24/7 repairs): merged with growing contractors, because they need the same dispatch tools, only faster.

In-house maintenance teams at property managers: Accommodate. They can use an existing package without changes.

Franchise networks: Decline. They need central billing for franchisees and custom reporting, so Vanrota sets a minimum contract value and does not build custom features for them.

The final segments look similar to the original three, but they are defined by different signals: who runs the schedule, how many branches the company has and whether it serves commercial clients under contract. Those signals return in chapter 3.

One of the cards, in short. Growing contractors. Early identification: an office role and six or more technicians on the demo request form. Buying trigger: hiring a first dispatcher or office manager. Main objective: fill every technician's day without double bookings. Alternatives considered: two larger field service platforms and spreadsheets. Distinctive priorities: dispatch speed and online bookings. Evidence about willingness to pay: switch interviews point to a budget around 30% above what owner-operators pay per technician. Share: about 35% of customers, 45% of revenue and half of the current pipeline. Decision: Prioritise.

In the blind test, two sales representatives disagreed on four of the last 20 deals, all of them small contractors that had just hired office help. The team kept the definition and noted that this moment is exactly where customers move between segments.

Chapter 2. What does each species eat right now?

The second question is which features and services matter to each segment, and which of them belong in each package.

Many packages are built by taking the full feature list and dividing it across plans, usually with the newest or most expensive features at the top. The result reflects the order in which the product was built more than what customers need from it.

Usage data looks like the obvious correction, and it is useful within limits. Pendo's 2019 Feature Adoption Report, based on usage data from 615 of its customer subscriptions, found that 80% of features in the average software product are rarely or never used.

Low usage does not always mean low value, though. Single sign-on may be configured once and an audit export used once a year, yet either can decide whether a security or finance team approves the purchase. This chapter therefore combines usage with evidence from sales, customer success and customers themselves.

Start with the segment cards from chapter 1. These fields matter most here:

• Alternatives considered show what customers already expect: anything the alternatives provide is a likely minimum requirement.
• Distinctive priorities and evidence about willingness to pay point to what a segment may pay more for.
• The decision from step 4 tells you which segments to design for. Prioritised segments get their own column in the analysis, accommodated segments are checked at the end, and declined segments are left out.

The goal is to give every feature and service one of four roles, separately for each prioritised segment: Core, Premium, Add-on or Background. Step 3 defines them. The same item can play different roles for different segments, and averaging across the customer base hides exactly those differences.

For this chapter, the guerrilla approach takes a small team two to three weeks. The expedition approach adds a conjoint study for items whose role remains uncertain after the guerrilla work. Plan for six to eight weeks in total. If a segment includes only a handful of accounts, treat its usage figures with caution and rely more on interviews and deal evidence.

Step 1. Build the inventory

List everything customers can receive from you: product features, services such as onboarding, training, support levels and account management, and commitments such as service-level agreements or security reviews. Leave usage limits and volumes for chapter 3: they depend on your pricing metric and on the boundaries between packages.

Describe each item in terms a buyer would recognise, such as "approval workflows for discounts above a threshold" rather than an internal module name. Group small features that customers would not evaluate separately, and aim for 20 to 40 items.

Guerrilla: Ask a product manager and someone from customer success to draft the list from your pricing page, release notes, recent proposals and signed contracts. Contracts often reveal services or terms added to close deals that never appeared on the pricing page.

Then run a simple usage check. For product features, export whether each account used each feature at least once in the last 90 days, or in the last year for features used periodically, such as audit exports. Without a product analytics tool, your engineers can usually pull this from the application database. For services and commitments, use CRM, support and contract records instead.

Calculate the share of accounts in each segment that use or receive each item. Count accounts rather than events, so that a few large customers do not dominate, and compare only accounts whose package includes the item. Where no account in a segment has access to an item, usage says nothing about that segment's need.

Expedition: Add depth: how many users within each account use each item, how usage has changed over time, and whether accounts that renewed or expanded use different items from those that reduced their plan or left.

Step 2. Gather the evidence

For every item and every prioritised segment, answer three questions in this order:

1. Is it a minimum requirement? Would buyers in this segment rule out an offer without it?
2. How many customers in this segment need it?
3. Would the customers who need it pay extra for it?

The order matters because an item can be both a condition of purchase and highly valued: enterprise buyers may value single sign-on highly and still refuse to consider an offer without it. That makes it a requirement, whatever they would pay for it.

Guerrilla: Collect evidence before anyone offers an opinion: usage by segment, interview notes from chapter 1, win/loss notes, RFPs, security questionnaires and requests from recent deals. Items that keep appearing in sales concessions are likely valued. Customer success knows which items customers object to losing at renewal or when they downgrade.

Then bring sales, customer success and product together, one segment and one question at a time. Do not put a two-by-two grid in front of the team, because holding two dimensions at once is hard and the result is mush. Sort the items into three piles for each question: required, not required or unsure; most, some or few customers; would, might or would not pay extra. Items marked required skip the other two questions. Record the evidence behind each placement and expect to need more than one session.

Expedition: Complete the guerrilla sorting first, then test the items that step 3 marks for further research in a choice-based conjoint study. Respondents repeatedly choose between versions of an offer that differ in features, services and price, and the software estimates how much each item contributes to the choice, expressed as willingness to pay.

Test no more than eight to ten items, starting with those that have the most at stake, and leave requirements out: a buyer who would reject any offer without single sign-on gives it a very high value, which looks like Premium in the results. Tag respondents with the identification criteria from your segment cards, plan for roughly 100 respondents per prioritised segment and use realistic price levels, which the analysis needs but which are not your final prices.

Step 3. Assign roles per segment

Now build the grid yourself from the sorts, one segment at a time:

• Core: a minimum requirement. Without it, buyers in the segment rule your offer out, so it belongs in every package they might buy. If they would also pay a lot for it, reflect that in the price of their package rather than in a separate charge.
• Premium: not a requirement, but needed by most or some customers, who would pay extra for it. It differentiates packages and gives customers a reason to move up.
• Add-on: not a requirement, needed by few customers, who would pay for it separately. An item needed by a minority that is expensive for you to deliver also belongs here, because including it in a package makes every other customer pay for it.
• Background: not a requirement, and customers would not pay extra for it, however many use it. Include it at no extra charge where needed, but do not use it to separate packages or as a selling point.

Two kinds of items remain uncertain. Treat an item marked unsure on the first question as Core only if you can point to evidence: deals lost or stalled without it, requirements in RFPs or security questionnaires, or consistent statements in interviews. Otherwise, classify it like any other item.

For items customers might pay for, the choice is between charging for them (Premium or Add-on) and including them at no extra charge (Background). Estimate what that choice is worth: count the accounts in the segment that use or ask for the item and multiply by a plausible price difference, such as the gap between your current packages or a typical add-on price.

If the result is higher than the cost of resolving the question with a few more interviews or a conjoint study, mark the item for further research. For the rest, choose to charge for now: adding an item to a package later is easy, while removing it from existing customers is not.

Guerrilla: Cross-check with the removal test: the cheapest package you could still honestly sell to the segment holds its Core, what you would add to make a customer pay around 30% more is Premium, and what only about a fifth of customers want but would pay for separately is Add-on. Discuss every item where the two methods disagree.

Expedition: When the conjoint results arrive, update the grid. Items with substantial value for most respondents in a segment are Premium candidates, items whose value is concentrated among a minority are Add-on candidates, and items with little value are Background.

Step 4. Build the map across segments

Combine the results in one table: items as rows, prioritised segments as columns and the role in each cell. Then look for patterns:

• Core for every segment: belongs in every package.
• Core for one segment, Premium or Add-on for another: belongs in the package for the segment that treats it as Core. Other segments reach it by moving up or, where it is an Add-on for them, by buying it separately.
• Add-on for one segment, Background for the rest: sell it separately, mainly to the segment that values it.
• Background everywhere: include it where needed and keep it out of package comparisons.
• Different capability areas rather than more of the same: if segments need different parts of the product, record it. It shapes the overall structure of your offer, covered at the end of this guide.

Check each accommodated segment as well: can it buy one of the emerging packages without custom terms? If not, decide whether you can live with the gap.

Step 5. Draft the packages and test them

Draft one package per prioritised segment; two segments with nearly identical columns can share one. Each package contains the Core items for its segment. Items that are Premium for a segment go into a higher package, where they give that segment a reason to move up; for the segment served by your highest package, include them there or offer them as add-ons. Background items stay available without appearing in the comparison.

Test the drafts with three checks:

1. Can you describe each package in one sentence about whom it serves? If not, it probably mixes segments.
2. Does the entry package leave a reason to move up? If it already meets most of the next segment's requirements, that segment can buy the cheaper package, and entry customers have little reason to upgrade.
3. Is the add-on list short? More than five to seven add-ons usually means some belong inside packages or should be removed.

Guerrilla: Replay your last 20 closed deals, won and lost, against the drafts. For won deals, decide which package the customer would have bought and whether it would have needed exceptions. For lost deals, check whether any draft would have addressed the reason for the loss. Repeated exceptions point to an item in the wrong place.

Expedition: Use the conjoint tool's simulator to estimate which draft package respondents in each segment would choose. It can only compare packages on the items and prices in the study, so treat the result as partial if the drafts differ on untested items. If most of a segment prefers a package designed for another segment, revisit step 4.

The output of this chapter is a feature map and a first draft of package contents. What the drafts still lack are clear boundaries: the events that move a customer from one package to the next, and whether your product can enforce them.

Worked example: what Vanrota's segments need

Vanrota's inventory has 32 items. The usage check covered only accounts on the Pro package, the only one with AI features. Among them, AI job reports were used at least once in the last 90 days by around 70% of multi-branch companies but by only 15% of owner-operators, and about 10% of accounts generated 60% of the cost of running the feature.

A slice of the feature map. Each item gets one of four roles in each segment: Core (a minimum requirement), Premium (valued enough to pay extra, so it goes into a higher package), Add-on (sold separately) or Background (included, but never used to separate packages).

Scheduling board, technician app, invoicing and card payments. Core in all three segments: nobody buys without them.

Online booking widget. Premium for owner-operators, who would pay extra to win more jobs. Core for growing contractors, because the alternatives they compare offer it. Background for multi-branch companies, which take bookings through their own call centres.

Dispatcher console. Background for owner-operators, who schedule from a phone. Core for growing contractors and multi-branch companies, whose office staff run the schedule all day.

AI job reports from voice notes. Add-on for owner-operators and growing contractors: few of them use the reports heavily, and those who do generate most of the cost. Core for multi-branch companies, whose commercial clients require standardised reports.

AI chat assistant. Background in every segment: customers use it occasionally, and nobody would pay for it.

Single sign-on and audit log. Core for multi-branch companies, where IT takes part in the purchase. Background for the other two segments.

Implementation and data migration. Background for owner-operators, who set up the product themselves. Add-on for growing contractors, some of whom want help moving their data. Core for multi-branch companies, which cannot switch without it.

Two results surprised the team. The same AI feature turned out to be a requirement in one segment and an Add-on in the others, and the requirement was backed by evidence: three lost deals in the past year named the missing standardised reports as a reason. The chat assistant, launched together with the job reports, ended up as Background everywhere.

The conjoint study tested eight uncertain items. For growing contractors, the value of AI job reports was concentrated in about a fifth of respondents, which confirmed the Add-on role.

The draft packages:

Solo, for owner-operators: scheduling board, technician app, invoicing and payments.

Crew, for growing contractors: everything in Solo, plus the online booking widget and the dispatcher console.

Network, for multi-branch companies: everything in Crew, plus AI job reports, single sign-on with an audit log, and implementation.

Add-ons: AI job reports for Solo and Crew, and implementation for Crew.

The chat assistant stays available in every package but no longer appears in package comparisons. All three checks pass: each package has a one-sentence audience, Solo leaves owner-operators a reason to move up to Crew (online bookings), and the add-on list has two items.

Chapter 3. What makes one of them migrate?

The third question is which events move a customer from one package to the next, and how to set the boundaries between packages so that those moves actually happen.

Animals do not migrate because the destination is nicer. They migrate because something stopped working where they were: the food ran out, the water froze, the days got short. Many upgrade paths stop at the destination instead. The higher package gets more features, and nobody defines what has to happen in a customer's business before those features become necessary.

The stakes grow as the company grows. ChartMogul's Growth Levers report, based on data from 6,525 software companies, followed those that made it from $1 million to $20 million in annual recurring revenue. At $1 million, 15% of their net new monthly recurring revenue came from expansion. By $20 million, the share had risen to 35%.

Expansion includes additional seats, add-ons and new products as well as moves between packages, so the figure does not measure packaging alone. It does show that as a company grows, more of its new revenue comes from customers it already has, and the boundaries between your packages decide whether those customers have somewhere to go.

Start with the draft packages from chapter 2. They tell you what each package contains, but not when a customer belongs in the next one. Two inputs from earlier chapters help here:

• Early identification criteria from the segment cards. A boundary has to rest on something you can observe, just as a segment does.
• Items that are Premium for one segment and Core for another from the feature map. They are the natural material for boundaries.

Boundaries follow one rule: a boundary has to be an event, not a preference. A third property, a compliance audit, a second team that needs access or a volume ceiling hit in month nine are events. We call the event that moves a customer across a boundary a migration trigger.

For this chapter, the guerrilla approach takes a small team two to three weeks. The expedition approach adds a cohort analysis of usage data, a short survey of customers who recently changed packages and a pilot of the new boundaries with new customers. The analysis takes four to six weeks, the pilot at least a quarter, and you need someone who can work with usage data at account level.

This chapter relies on customers who have already moved between packages. If you have seen fewer than 20 upgrades and downgrades in the last year, treat the patterns you find as hypotheses and rely more on conversations with customers.

Step 1. List the candidate boundaries

This step is the same for both approaches, because it relies only on data you already have. For each pair of adjacent draft packages, write down what could separate them. Candidates usually come from three sources:

• Premium items placed in the higher package. For each, ask which event makes a customer need it.
• Usage limits and volumes, which chapter 2 set aside: users, locations, projects, transactions or whatever unit your customers grow in.
• Signs that a customer is turning into the next segment: the identification criteria on that segment's card, such as company size, entry into a regulated market or a buying group that now includes IT.

Work through the pairs with the people who sorted the features in chapter 2: someone from sales, customer success and product.

Then check which of today's limits customers already run into. Take the limits in your current packages from the pricing page and your standard contracts, and look for evidence that customers push against them: exceptions approved in deals and recorded in the CRM or in contract amendments, support tickets asking for a higher limit, and overage charges in billing. A limit that keeps appearing in this evidence marks a boundary customers already run into.

For each candidate based on volume, export current usage and build a simple distribution: how many accounts in each segment are at each level of users, locations or transactions. You will need it in step 4.

Step 2. Find the events behind past moves

Now look at the customers who have already moved. What happened in their business shortly before they upgraded, expanded, downgraded or left?

Guerrilla: Take your last 20 to 30 upgrades and 10 to 20 downgrades or cancellations. For each, reconstruct the 60 to 90 days before the move from usage data, CRM notes and customer success records. Look for changes in the customer's situation: a new location, an audit, a new team, a jump in volume.

Look also for accounts whose usage flattens just below a limit, and for workarounds that show where accounts hit a limit before anyone upgraded: shared logins, a second account, regular exports to spreadsheets, support tickets asking for exceptions. Where the records are thin, call five or six customers who upgraded recently and ask what changed in their business before they needed the higher package.

Expedition: Compare accounts that upgraded with accounts of similar size and age in the same segment that did not. Track their usage over time and look for the level or event after which the share of accounts upgrading within the next quarter rises sharply. Then survey customers who changed packages in the last 12 months about the event that triggered the change, using answer options based on the guerrilla findings.

Step 3. Test each boundary

Every candidate goes through five checks:

1. Is it an event rather than a preference? Something has to happen to the customer: growth, a new obligation, a new group of users. A boundary based on wanting something more advanced leaves the timing entirely to the customer.
2. Can you observe it? You need to see the event in product data, the CRM or the sales conversation, ideally without asking. This is the same logic as early identification in chapter 1.
3. Does the customer get more value after crossing it? When paying more coincides with getting more, the move feels fair. When it coincides with nothing the customer notices, it feels like a penalty.
4. Can a sales representative explain it in one sentence without apologising? "The Professional package is for companies running more than two properties" is a sentence a rep can say. A boundary that needs a footnote tends to be renegotiated deal by deal.
5. Can your product enforce it? Decide whether reaching the boundary stops the customer (a hard limit) or warns them and alerts your team (a soft limit). A boundary the product cannot track will be enforced inconsistently, if at all.

Guerrilla: Score each boundary from 1 to 3 on every check, as in chapter 1, and record the evidence behind each score. A boundary that scores 1 on the first or the fifth check needs to be redesigned, however well it does elsewhere.

Expedition: Use the cohort data for the third check. Accounts that reached the event or usage level behind a boundary should have started using more of the product afterwards. If their usage did not change, crossing the boundary would not give them more value.

Step 4. Set the thresholds

The last example above, a volume ceiling hit in month nine, needs one more question: does the volume belong in a package boundary or in your pricing metric? Chapter 1 noted that higher volumes alone can usually be addressed through the pricing metric. If customers on both sides of a volume level need the same things in larger quantity, let the price grow with the metric and keep the volume out of the package boundary. If crossing the level coincides with new needs, such as approval workflows once a team grows past ten people, it is a package boundary.

Then decide where to set each threshold. Each package should cover a typical customer of its segment with room to grow, and the threshold should come at the point where customers start to look like the next segment. A threshold that most current customers of the lower package already exceed works as a price increase, and customers will treat it as one.

Guerrilla: Use the distributions from step 1. For each possible threshold, count the accounts in each segment that are already above it.

Expedition: Project each account's usage 12 months ahead from its growth trend. Estimate how many accounts would cross each threshold and what that would mean for revenue before you commit to a number.

Step 5. Build the migration map and test the ladder

Write one row per boundary: the migration trigger, where it shows up in your data, the one-sentence explanation, how the product enforces it and who acts when an account gets close. The last field matters more than it looks. If nobody notices that an account is approaching a boundary, the customer learns about it from a limit message in the product, which is a poor start to a commercial conversation.

Add the way back for each boundary: what happens when the event reverses, for example when a customer closes a location. A customer who cannot move down when their business shrinks is more likely to leave.

Guerrilla: Replay the last 12 months against the map and count how many accounts would have crossed each boundary. If almost none would have, you have built a menu rather than a ladder: the boundary is set too high or rests on the wrong event. If most accounts in the lower package would cross it at once, it works as a hidden price increase and is set too low.

Expedition: Introduce the new boundaries to new customers first, for at least a quarter. Track how many reach each boundary, how many upgrade and how many push back. Apply the boundaries to existing customers only after that, and plan the change as a migration.

Worked example: Vanrota's boundaries

Under the old packages, Vanrota's only upgrade path was the AI features in Pro. That boundary fails the first check, because wanting AI is a preference rather than an event. In the previous 12 months, about 3% of Starter customers had moved to Pro.

Step 2 pointed to two events. Owner-operators moved up when they hired someone to run the office and the schedule, and growing contractors moved up when they opened a second branch or signed their first service contract with a commercial client. Workarounds confirmed both: before upgrading, several accounts shared the owner's login with a new office employee, and others ran a second branch as a separate account.

The migration map:

Solo to Crew. Migration trigger: the first office user who schedules jobs but does not work in the field. Signal: a user with an office role in the product. One sentence: "Crew is for businesses with someone in the office running the schedule." Enforcement: soft limit; adding an office user prompts an upgrade and alerts customer success. Way back: if the office role stays empty for a full billing period, the customer can move back at renewal.

Crew to Network. Migration trigger: a second branch or a first commercial service contract. Signal: a second branch created in the product, or a contract type recorded in the CRM. One sentence: "Network is for companies running more than one branch or serving commercial clients under contract." Enforcement: a hard limit of one branch in Crew, and a soft alert for commercial contracts. Way back: closing a branch allows a move back to Crew at renewal.

Two volumes stayed out of the boundaries. Every additional technician needs the same things in every segment, so the per-technician price carries that growth. AI job reports are also needed the same way at any volume, so Network includes an allowance per technician, and further reports are sold in credit packs, the same way as the add-on for Solo and Crew.

Replayed against the last 12 months, the new map would have moved around 140 accounts from Solo to Crew and around 30 from Crew to Network. Vanrota offered the new packages to new customers only for the first quarter before planning the move of its existing base.

Putting it together: choosing the structure

The three chapters give you the segments to design for, the contents of each package and the boundaries between them. One decision remains before you can draw the pricing page: the overall structure of the offer.

Three structures cover most B2B software offers, and they are often combined:

• Tiers, often called good-better-best: each package contains everything in the one below it and adds more. Tiers fit when larger or more demanding segments need more advanced versions of the same capabilities.
• A base product with modules: every customer buys the base and adds modules for specific capability areas. Modules fit when segments need different parts of the product rather than more of the same.
• Add-ons on top of either: for items that few customers need but those who do will pay for, or that are expensive to deliver for a minority.

Your feature map already points to the answer. In chapter 2, step 4, you recorded whether segments need different capability areas or more of the same. If the differences are mostly in depth, tiers fit. If segments need different areas, a base product with modules usually fits better, because tiers would make customers pay for areas they never use. If your add-on list grows past five to seven items, some of those items probably belong inside a package or a module.

Then check the structure against the migration map. Tiers need a boundary between each pair of adjacent packages, and each module needs its own trigger, usually the moment a customer starts working in a new capability area. A structure your boundaries cannot support will work as a menu, however tidy it looks on the pricing page.

Worked example: Vanrota's structure

Vanrota's segments need the same capability areas at increasing depth: scheduling, dispatch and reporting, with more control and documentation for larger companies. Tiers fit, so Vanrota kept three packages, Solo, Crew and Network, with two add-ons. Had commercial maintenance contractors needed a separate set of capabilities, such as asset registers and planned maintenance schedules, a module for them would have been the better answer.

Before you announce anything

New packages also have to reach existing customers, who bought under the old ones. Moving them across without losing revenue or goodwill is a project of its own: who moves when, on what terms, with which protections, and what sales and customer success tell them. Introducing the new packages to new customers first, as the expedition approach in chapter 3 suggests, gives you evidence before you touch the existing base.

At Valueships, we use the research and analysis described in this guide to prepare decision workshops with commercial teams. Much of their value comes from the hardest choices: which segments to decline, what goes into the entry package and where the boundaries between packages fall. Moving existing customers onto the new packages follows as a separate project, and it is a large part of what we do with clients.

I believe the boundaries between packages deserve more attention than the packages themselves. A customer chooses a package once, but meets its boundary every time their business changes, and that moment decides whether they grow with you or start looking elsewhere.

Packaging is also never finished. Your segments will keep changing, and the evidence that tells you when to revisit your packages is the same evidence this guide asks you to collect: who buys, what they use and what makes them move.

Download the templates

The three maps from this guide are available as one Excel workbook, with a tab for each chapter. On the segment cards tab, you score every candidate segment on the five checks and record a decision. On the feature map tab, you give each item a role per segment, and a formula shows whether an uncertain item is worth further research. On the migration map tab, a formula flags every boundary that fails the first or the fifth check.

The grey rows contain the Vanrota example from this guide, so you can see a completed version before you replace it with your own data. Columns for roles, decisions, enforcement and scores accept only the values the guide uses.

Download the SaaS packaging templates (Excel) →

Sources

• McKinsey, The net revenue retention advantage: Driving success in B2B tech, November 2025
• Pendo, The 2019 Feature Adoption Report
• ChartMogul, Growth Levers: The Path from $1M to $20M ARR, November 2025