Zentitle Business Models
A full suite of licensing models allows you to deliver pricing and packaging rapidly
What business models does Zentitle support?
Zentitle supports every major software business model — feature-based, time-based, perpetual, version-based, usage/consumption, capacity, named-user, floating and concurrent, plus trials — all out of the box and mix-and-match on the same entitlement.
Why one platform for every model matters
Most software businesses evolve pricing over time: perpetual then maintenance, then subscription, then tiered editions, then usage. Using one platform for all of it means the transition happens in data and configuration, not in application code.
How the models work in Zentitle
Each model is a first-class primitive on the entitlement, not a workaround.
- Feature-based licensing: turn capabilities on and off per customer
- Time-based: subscriptions (monthly, yearly, custom), dated expirations
- Perpetual, perpetual + maintenance, version-range licenses
- Usage, consumption and element-pool models
- Capacity attributes (e.g., up to 10 / 50 / unlimited)
- Named-user and identity-based with any OIDC provider
- Offline and dark-site support across every model
Who this video is for?
Product leaders and commercial teams shaping new pricing or migrating from perpetual to subscription/usage models.
Video transcript
Auto-generated from the video and lightly edited for readability.
One of the real benefits of adopting the Zentitle platform as you look to bring your products to market is the ability to abstract out the business model from the implementation of the application itself. So you instrument your application once and then you can take it to market against a wide range of different business models, such as using feature based licensing, That allows you to, for a given customer, turn specific capabilities, modules, components on or off per the license.
It also allows you to implement any kind of time based license. One month subscription, one year subscription, a license that expires on December thirty first twenty twenty five, etc. So any kind of date based metric you can implement as well.
Of course, you can also do perpetual or non expiring licenses with or without a maintenance contract. So you may on the entitlement self, want to keep track of when a given maintenance contract ends. And then you can build that into logic within your application, perhaps only allowing a customer to apply software updates for licenses that are still within their maintenance window.
You can also do version based licensing. So for example, you could require that a given customer must have a separate license for each version of your product. So they buy a version two license, and then when version three comes out, they need to upgrade to a different license.
Now another approach that we recommend instead for that is that you define in the entitlement the valid range of versions for that license. So it can initially start out, say, with a two dot x line. And then as they want to upgrade to the three x, four x line, etcetera. They use the exact same license, but update the attribute within that license to say, yes, This license can now be applied to a 3x line, you know, version, a 4x line, and so forth.
We also fully support usage based or consumption or serve software as a service, on-demand kind of model. By using our consumption tokens and other capabilities so that if you wanna track usage of, of a sum, some resource over time, you can easily do so within that license.
From a capacity standpoint, here's where you can use the attributes of the entitlement to put specific limits on whatever parameters you want. So perhaps for a lower cost addition, you give them the ability to manage say up to ten widgets.
For the mid-tier, maybe they can manage up to fifty widgets. And then for the enterprise, you may want to have unlimited ability to manage those, or what have you. And of course, you can have as many of those attributes as you want.
We can also support named user model Right? So you might set up a license for ten users of the application.
Lim that to a specific ten set of people named people based on identity and, give your end customer the ability to manage that list of who are the current named users able to access that application.
Similarly, we allow arbitrary integration with identity systems. So if you want to provide an experience similar to Adobe Creative Cloud, Office365, where an end-customer will activate a seat or be able to act as their license by using an identity, email address, password, etcetera. We fully support that. We can also integrate with any openID based, identity platform.
So whether that's auth zero, Okta, Cognito, Azure AD, etc., we can easily tie into that. One of the additional benefits that provides the end customer is if they have their own IDP that they're running within their own corporation. That can be used to federate into these other identity platforms. So those end customers can use single sign-on in order to be able to access those license rights.
And of course, we can also provide these kind of capabilities for end customers that have an ongoing internet connection or perhaps an intermittent internet connection or even completely disconnected or a dark site environment. And we can support that for both node lock, individual seat licenses, as well as if you want to deploy some sort of concurrent or network based licensing model that needs to run-in that dark environment.
So across all these different capabilities, you can really monetize your application any way you want. And in a mix and match manner, and in a way that doesn't build these dependencies into your core application so you can easily employ new packages, new offerings, new pricing without engineering changes.
Decouple your
monetization today
Join the enterprises scaling their revenue without rebuilding their stack every year.
Unleash the monetization potential of your software / SaaS / Hardware