Zentitle Plan Abstraction

As a product manager, one of the key tasks is to figure out how you're gonna price and package your software, which means figuring out what different kind of plans you want to take to market the price points. And then for each of those plans, what's included?

And so our plan of abstraction approach gives you a very easy way to manage it at exactly that level. So you can have your full list of offerings, often called SKUs or stock keeping units, sometimes called part numbers. And so this is the full list of offering. So we allow to easily manage that within Zentitle or import from another system. So once you have that product catalog, you can then think about, okay, well, how are you gonna take that to market? How are you going to advertise these different skews and what capabilities they have?

So, typically, you know, there's some progression from good to better to best. Small number of capabilities, starting point, lower price point, to the mid tier that may be most popular that has additional capabilities at a higher price point, and then the best, which may be an enterprise or more custom set of offerings.

And so as you define these, you can map them to the classic, product feature matrix. So to define for each of these individual offerings, what features are included. And of course, this should be something that's meaningful to the end customer.

So with our offering management, we allow you to easily define for a given tier. What features should be enabled for a customer who purchases that offering.

And we allow that both for individual features that should be enabled or disabled. We also allow you to specify arbitrary parameters. So for example, you might have, within your license, you know, how many, reports can you run per month? Or what are the total number of widgets that you can manage through the application? With different values depending on the tier that the customer's purchased.

So once you fulfill an order, so a customer buys a license for one of these additions. That can then generate a specific entitlement for that customer with those rights enabled or those parameters specified. Course, you can always override those as well. And then from an application standpoint, rather than the application having to say, Okay.

This customer is on good. This customer is on better, etcetera. We have a full abstraction API that allows your applications to simply query, hey, before this customer should feature one be enabled, or should feature two. And so they don't need to know about these arbitrary plans.

All they need to really focus on is enforcement of license rights at the individual feature or parameter level. So this completely removes your business model aspects from your code, which means that as you roll out brand new plans, You don't have to worry about re architecting, reimplementing any kind of logic in your application in order to support these different packaging approaches. That gives you a lot more agility, a lot more flexibility as you look to experiment with brand new offerings and bring things out to market.