SaaS pricing and packaging have become significantly more complex over the last several years.
Product-led and sales-led go-to-market (GTM) models changed how software is adopted and expanded. Granular and feature-based packaging gave SaaS companies more flexibility around features, add-ons, and enterprise plans. Usage-based and consumption pricing also pushed pricing models closer to actual customer usage.
Customer expectations changed alongside those shifts. Buyers expect pricing and packaging that fit how they actually use a product, what they need today, and what they can grow into later.
According to Bain & Company, price is the main factor influencing purchase decisions in 80% of markets.
SaaS businesses are trying to keep up, but most internal systems were built for much simpler packaging models and struggle to support that flexibility at scale.
In Part 1, we explored the systems that govern B2B packaging and the pressure modern monetization models place on them. In this part, we’ll break down the common SaaS packaging challenges that, if addressed, would allow organizations to capitalize on shifting buying behavior.
SaaS packaging challenges come from systems that cannot support modern pricing, entitlements, usage tracking, and hybrid GTM models.
Common problems include inflexible entitlement systems, rigid data models, growing pricing exceptions, disconnected systems, confusing tiers, weak plan differentiation, and engineering dependency.
Many companies still rely on hard-coded packaging logic, manual work, and fragmented infrastructure that slow down monetization changes.
Schematic solves these challenges by decoupling pricing logic from the application and acting as the system of record for your product catalog.
There are several common challenges that tend to hold software companies back when it comes to software packaging:
Software entitlements are generally implemented in two ways.
The first is hard-coded entitlements, which manifests itself as features in the code base that are explicitly tied to plan IDs, then interpreted throughout the code base. This often creates challenges for the product team as packaging changes and new pricing requirements are introduced.
The second are feature flags (either homegrown or via a managed service) that are exposed as entitlements to the end user.
Both approaches are adequate for simpler packaging schemes, but they tend to create challenges in more complex scenarios, especially as companies grow.
Ideally, entitlements can be flexibly checked and bundled in any number of permutations without major code changes or the fear of disrupting existing customer cohorts or the overall customer experience.
That becomes very difficult once organizations introduce feature-based access, usage limits, enterprise exceptions, or add-ons tied to specific plans and core features.
Instead, what is typically the case is that each change to packaging requires refactoring brittle code paths, making affordances for legacy cohorts, updating integrations into billing tools, and exposing controls in internal tools.
Eventually, even small pricing decisions can create operational overhead, slow down development, and negatively impact customer experience and net retention.
Products need to maintain a data model that houses a relationship between companies that use the product and their subscription level.
In many cases, this is architected so that a given company has only one subscription. It’s logical that these models are built this way, but it limits the ability for organizations to commercialize individual features or deliver additional value to different customer segments.
For example, if you want to offer add-ons in addition to a base subscription, you would need to generalize your data model to allow a given customer to have multiple subscriptions. You also need to update the application logic accordingly.
That becomes important as you support small businesses, enterprise accounts, and other different segments with different packaging needs.
Furthermore, usage tracking must take into consideration scale, storage, accuracy, transformation, auditability, latency, and real-time data. Often, tools in the finance stack are not built to accept raw events, so they must be transformed before being sent to a subscription management or billing platform.
This problem compounds when a company has multiple pricing metrics or multiple entitlements that are gated by usage data.
What a customer bought, where they bought it from (self-serve, direct, etc.), when they bought (in 2020, 2021, etc.), where they are (e.g., domestic or international), who they are (e.g., parent organization or child organization, reseller, etc.), and even where they are in the sales process (e.g,. in pipeline, renewal, etc,.) all can dictate product experience, access, and billing.
That complexity grows quickly once organizations support different pricing structures, contract terms, and packaging rules for specific customer segments, enterprise accounts, resellers, and international users.
Different price points, sales motions, and market conditions can create entirely different experiences for new customers, long-term accounts, and other parts of the existing customer base.
As the permutations of packages and features sold increase, those states multiply for organizations. They result in legacy cohorts, a variety of one-off feature flags, plan sprawl in the product, and SKU sprawl in billing systems and product catalogs.
This creates a nightmare for operations, support, and engineering teams.
Billing ops become difficult to manage, access issues become harder to diagnose, and new feature development must account for growing layers of exceptions tied to customer segmentation and different types of paying customers.
Data is an important part of supporting packaging schemes in three ways:
Context must be accessible in the product stack to authorize or gate a user’s access based on the packaging scheme (e.g., if access is limited to 10 occurrences, or when access is limited when someone is abroad).
Packaging schemes must be accessible and actionable cross-functionally. Defining new packaging in the sales stack is often insufficient if that new packaging does not appear in finance systems, in the product, in reporting, and elsewhere for the entire organization.
It’s useful to determine what’s working and what’s not through customer feedback. This can inform additional investment and help teams take a more data-driven approach to go-to-market strategies.
There is quite a bit of work involved in supporting the various integrations into and out of the product and throughout the stack. That’s why organizations tend to struggle with accounting for and accommodating them.
Organizations rarely solve these infrastructure problems directly. Instead, they usually fall into one of three approaches:
Operations teams become data entry specialists and spend countless hours transferring data from one system to another, which is error-prone and time-intensive.
Engineering teams become SIs to support operations rather than what they were hired for—building new features, improving customer experience, and reducing wasted engineering time.
Massive professional service contracts may address the problem once, but don’t take into account ongoing maintenance as systems change.
Furthermore, in many cases (e.g., NetSuite), tools within these stacks offer weakly architected APIs that make integration very complex or not possible at all for some or all use cases. That results in connections that are out of date, insecure, and need to be updated as requirements change.
As SaaS businesses introduce new products, customer segments, and sales motions, pricing tiers can become complex for buyers to understand.
What may start as a simple good-better-best model for a SaaS product often turns into a mix of legacy plans, renamed packages, overlapping bundles, and add-ons that are hard to compare.
This creates friction during product evaluation. Potential customers may not know which plan is right for them, what features are included, or when they will need to upgrade. In many cases, sales and support teams are left to explain the differences manually.
The result is a weaker buying experience. When packages vary significantly without a clear pricing strategy, too many tiers or confusing feature bundles can overwhelm buyers.
Each plan should have a clear reason to exist. Buyers should be able to look at the packaging and quickly understand who the plan is for, what value it unlocks, and why it costs more or less than the other options.
Weak plan differentiation often happens when packages are built around internal feature lists instead of how different buyers actually evaluate value.
A small team, a growing mid-market company, and an enterprise business may all care about the same SaaS product. However, their customer needs, implementation requirements, and purchasing power can look very different.
When plans do not reflect those differences, buyers choose the cheapest option and have less reason to upgrade.
That is why each package should be designed for a specific target audience, not just a higher price point. Lower tiers may prioritize speed and simplicity. Meanwhile, higher tiers should map to more advanced use cases, extensive integrations, and other capabilities that align with a customer’s willingness to pay.
In many organizations, pricing and packaging changes are still dependent on engineering work.
Business teams may need engineering support to create new plans, update feature access, change usage limits, fix entitlements, or manage customer-specific exceptions.
This becomes a bottleneck as pricing and packaging evolve. Even simple pricing changes require application logic to be updated, tested, and deployed before the customer experience reflects what was sold.
Over time, engineering teams become responsible for maintaining packaging logic instead of building new product capabilities.
Product launches into new markets slow down, experiments become harder to run, and every new package introduces more operational risk.
Pricing stops being a growth lever and becomes another engineering dependency that limits business agility.
There is no simple solution. Many organizations try to solve these challenges in various ways depending on their packaging complexity, internal resources, and broader business goals.
Over time, application packaging and supporting the billing stack become distinct disciplines at organizations. The difference becomes more noticeable at scale, when companies tend to have dozens of engineers supporting the complex interplay between the product, finance, and sales stack.
This approach can provide more flexibility for organizations navigating complex monetization requirements or growing SaaS challenges, but it also requires significant long-term maintenance and engineering investment.
Even early-stage companies can accumulate operational complexity quickly while still searching for a stable product-market fit.
In some cases, the solution is augmenting the stack with additional tools.
For instance, organizations have started to utilize purpose-built UBP products to simplify data engineering associated with usage tracking and augment billing tools that lack UBP capabilities.
For many teams, finding the right tools becomes a way to reduce operational overhead without slowing product development or limiting future revenue growth.
The most common scenario is that organizations simply do nothing.
They work around their existing systems with process or code. However, they never address the underlying issues that prevent them from offering a modern buying experience, or they overload existing systems with responsibilities they were never meant for (e.g., feature-level data in a subscription management product).
While this works in the near term and may support immediate revenue, it frustrates customers and results in weaker acquisition or accelerated churn. It also limits an organization’s growth opportunities in the long term by reducing overall agility.
As customers demand better onboarding, more flexible packaging, and consumption-based billing, a solution must start in the product stack.
If that is not addressed first, any solution in the sales or finance stacks in isolation might lower the burden for sales or operations teams to facilitate, set up, and invoice a deal.
But it will not translate to fulfillment in the product, and it will compound exceptions that lead to weakening product velocity and poor customer experiences.
A modern approach to SaaS monetization might look like this:
This layer is designed to support a more flexible pricing strategy and increasingly complex packaging models without creating operational complexity throughout the technology stack. It should also be built with the following considerations:
How features are tied to packages and how those packages are associated with customers are purely a function of how a business sells.
The consideration and logic that governs it should be abstracted from the application, which would speed up new feature development, time to market, and overall flexibility.
That also includes out-of-the-box integrations with CRM and billing tools, which can either synchronize data or facilitate transactions with custom glue.
A true entitlement service should allow an organization to assign entitlements granularly and tie those to how the business sells and delivers customer value.
Baked in should be an assumption that packaging will have many permutations and change over time as the product matures or sales channels are added.
Feature flags must be purpose-built for entitlements with affordances for flag hygiene and organization.
Traditional release flags were designed to be short-lived, but entitlement checks often become long-lived because they govern plan access, upgrades, add-ons, and customer-specific terms.
Packages are almost never wholesale changes in value offered to buyers. Instead, they are tweaks in names, default pricing, limits, or features informed by customer research and usage trends.
These should be handled by versioned packages that are tied to a base package, rather than entirely new SKUs. That would simplify feature development, customer management, and integration into other tools while supporting a more value-driven packaging model.
Business teams need a reliable way to manage entitlements without depending on engineering or working through outdated internal admin panels.
The new system should connect directly to entitlements and store user and company context derived from business tools. It should also act as the core packaging structure for product access, plans, and other customer-facing functions.
SaaS pricing and packaging no longer live only inside billing systems or sales workflows.
Modern monetization now affects product access, entitlements, usage tracking, AI credits, onboarding, expansion, and runtime enforcement inside the product itself. Most internal systems were never designed to support that level of flexibility.
The challenge is no longer just deciding what to charge. The harder problem is supporting modern packaging models without creating brittle billing logic, entitlement sprawl, or growing engineering overhead.
Schematic helps SaaS and AI companies manage that complexity with a centralized system for entitlements, plans, usage tracking, feature access, trials, credits, add-ons, overrides, and hybrid monetization models.
The platform, built on Stripe, decouples pricing and packaging logic from the application. Teams can launch trials, add-ons, usage limits, and new packaging without hard-coded logic or one-off infrastructure.
Schematic also evaluates and enforces in-product access at runtime. Engineering can focus on core product features instead of maintaining complex entitlement systems.
Businesses can iterate on monetization faster while keeping product, billing, and GTM systems aligned as the product scales.
Packaging changes affect retention by influencing how customers perceive value, pricing fairness, and product flexibility. Many SaaS businesses use customer interviews and feedback from customer success teams to better understand what customers actually want from pricing and packaging.
Managing entitlements manually can create billing mistakes, inconsistent feature access, support issues, and growing operational overhead. Fixing those problems often requires a deep understanding of legacy pricing logic and customer account exceptions.
SaaS companies usually support multi-product packaging through centralized entitlement systems, shared billing infrastructure, and usage tracking. That becomes more important when products include add-ons, hybrid pricing, or AI models. Marketing teams also need visibility into packaging to ensure product positioning stays aligned with the company's size and willingness to pay.
Packaging decisions affect development speed because pricing logic, entitlements, and billing workflows are often tied directly to the product codebase. Supporting flexible packaging requires SaaS businesses to understand how monetization systems affect product architecture and engineering workflows.
