SaaS Pricing Models : Usage, Licenses & Credits

I think I'm good. Yeah, I think it's good. Hello everyone.

So we are waiting a few minutes for everyone to start. There is a chat over on the right-hand side, this little sort of speech bubble. So you can try and write me there and we'll see if we have sort of a line of communication. But so far it looks like we are 23 people on here. So I know that... Close to 200 signed up, so it's gonna be a blast.

And hello and good afternoon to Katina and David over in the chat. You found it. That's great. So while we are seeing people join, I will see if I can sort of figure out how to share screen here.

Yes, so David the recording will be available afterwards. I don't know if it will be available right after so there's a little bit of a trade off with with Riverside. So this is the the recording software that we're using here is that the video quality that comes out is like super duper, but it takes a little bit of a time to actually get it into the hands of like the general public so. Yes, it will be available afterwards. Maybe even we can get some links to it up in the community so that it's available right after. But at the very least, we'll make it happen within a week or so. And then all the slides as well will be available shortly in the pricing SaaS community as well. Alright, I see that we're 44 people right now and we are one minute past. So I'm just going to kick this off. Good to have you all with me. I know that for our European audience, it's a little late in the afternoon. It's 5 p.m. where I'm sitting in Copenhagen. And I know that we have people joining on the East Coast and West Coast as well. We were trying to sort of pick this as the best possible time of day for most people to join. So I know if you're joining from California, it's like 8 a.m. in the morning. So good morning to you guys. So we're gonna have about an hour together. I have a little bit of a presentation that I wanna take you guys through. And this is a... a series of webinars that I'm doing. I'm doing one a month and it has to do with the collaboration that we at Willingness2Pay have with John and Rob over at pricingsass.com. So if you don't know pricingsass.com, they are the brainchild of John Rob, John Kotovsky and Rob Lidders. And then John started to look at

pricing pages like several years ago, I think three, four years ago, and he then built sort of out of curiosity and just because he's a product guy, a scraper and have then been scraping around 3000 pricing pages daily and is compiling the data. So what I'm going to go through today is actually a lot of that data. So they came out with a report earlier today and I will sort of I have helped them and so we have spoken about how to. structure the data how to have a taxonomy on pricing models and I have through my consulting built a taxonomy of pricing models that I think is solid. So I'm going to share that with you and then we're going to show how that looks across the population of sort of public pricing pages all across the web. And so that's actually going to be a lot of fun. I think there were a lot of sort of let's say insights and intuitions in that data that sort of, you know, we was intuitive and we kind of knew but but now we have some some some hard numbers on it. So so that's that's that's pretty awesome. So the structure is as follows. I'm going to talk for about 20 to 30 minutes and then there's going to be an open Q &A and by open I mean like anything goes so you can I prefer that you talk to me about pricing but but you in reality I'll probably have an opinion about anything. So So that's how goes. But before we begin, just want to point to the community.pricing.sas.com. So pricing.sas.com, if you go there, there is a login that gets you to a community page. This is the Discord community. We used to have a community over at school.com slash SAS pricing. But we've now moved that because we want to, let's say, co-host the community together with the Pricing SaaS website, their newsletter, all of that content. think that's a bit ways of a stronger platform. So if any one of you is still on the school community, that is now, you know, yesterday's news. We really would appreciate if you took the two minutes and just like went over to the community.pricingsaas.com and just joined there.

This is also where I will be posting all the follow-up materials from this webinar. So the recording slides, all these things. I will sort of go there and answer questions. I will probably in the future have some fireside chats there and also any sort of longer form concept in terms of guides, templates, and video courses. done a bit of them in the past will be posted over in the community. So the idea is that That is the one-stop shop for SaaS pricing for everyone. So that's how goes. and if you don't know, Pricing SaaS came out with a report earlier today. And if you look at the chat, John from Pricing SaaS has linked to the report in the chat. So go over there and fetch that link. And you can sort of look through it as we go along. I will be referencing some of that material in the presentation today and then also sort of adding a little bit of my own magic. All right, so here we go. 20, 30 minutes of talk and then Q &A. So pricing models. So I'm a consultant. I help SaaS companies with pricing. And of course, pricing models is a big part of that work. So a lot of pricing architecture, how do we price, and so forth. And I hear a lot of different sort of words being used around what a pricing model is. Like we have a tiered pricing model. We have a usage-based pricing model. We have a value-based pricing model. We have a licensed model. and so forth. And I think for me, I just wanted and I've always wanted to clean up that language a little bit. So part of that is that some people mistake what is essentially packaging, like what you can buy. So a tiered model would be usually that from how the pricing architecture actually works. I gave this quite a bit of thought and I came up with this. These are the six components of what a pricing model has to have.

And I'll go through them a little bit. But today we're going to focus on the first two, the pricing modality and the pricing metric. So the pricing modality is essentially how you charge and the pricing metric is what you charge. I'll show you in a second. Then we also need a time period. So since SAS is a subscription, it's a price per week, price per quarter, price per month, price per year, whatever. So there needs to be a time period. And then if we have a unit that we price by, We also need some granularity. So if we're doing price per user, then it is price per one user or per five users or per 10 users. So there is some sort of granularity, like a chunkiness of the number. We probably want a discount structure as well. So some form of what happens if I buy a lot of it. And then finally, of course, we need a number, a price point. So $10, $20, whatever it is, the actual price point is also a product. But these... So the four elements, while important, like time period, generality, discount, short term price point, are actually almost secondary to the two sort of like major components of a price model, which is the modality and the metrics. So that's what I'm really gonna spend some time on. And then we have an extra sort of a wild card, which is thresholds that I'll touch upon and explain because it usually throws people off a lot. So we wanted to cover that too. And it's also in the report. over pricing says so here goes so pricing modality. This is there are four kinds and only four. So this is the how you charge not watching charge per how so not users or API calls but the how and therefore kinds one is just a flat fee. So Netflix for example has a flat fee. I go to Netflix. I buy the subscription. It's. 1299 or 15 bucks or whatever it is today. And then I have access to the platform. It doesn't charge me per movie. It doesn't charge me for how much of the movie I watch or how fast I watch it or any of the other things. It is just a number for having the product. We see flat fees used sometimes with lower.

ACV like Netflix like lower annual contract value products usually below a couple hundred where you just get access to the thing or the solution and then flat things work really well Usually they don't work well for higher contract values Which is also why we very rarely see them in B2B SaaS So we see them a lot in B2C SaaS, but actually not a lot in B2B SaaS with some exceptions we can see flat fees in add-ons, for example, which is where they're used a lot, where you just have a number. So flat fees is one way of charging. The second way of charging is that you charge per something, but on a license. So that could be per user per month, which means that you have a right to use something for a time period. So the time period is part of this and you pay that upfront. The second version of that would be a usage based model where you have not right to but access to use something and then you pay in arrears. So this would be the difference between having a seat where I have a right to user and then having to pay for active users at the end of a period. So for example, I think Slack very famously said, hey, know, just load on all the users you have. We'll just measure which ones are active, and then we'll just charge you for those. But it's actually free for you to give logins to all of your employees. So that's what people did in the early days of SaaS, and then they just charged them per active user, whereas a lot of other software just charges for the right to use. So if you want to create a user profile, you need to pay upfront. And of course, this also goes with any other kind of metric, API calls. store locations, whatever it is that your solution does. You can usually turn it into both a usage based where you count in a period and then charge at the end or a license base where you have a right that you then pay for upfront.

Credit systems as the fourth modality and this is a little more technical will also see a little bit later in the numbers that it is the one least used of the four. It has gotten a lot of recent popularity because a lot of AI functionality is priced on a credit basis. The credits is essentially usage paid upfront. So this is where I say OK, you get a certain amount of credits. 100 credits. For example, you pay that upfront. And then in the time period, you then expense some of them, you spend some of the credits, but the credits that you do not use, they roll over to the next time period. And this is what differentiates a credit model from a license-based model, is that the credits are not lost. If I don't use them, they simply transfer to the next time period. But I have to then buy another chunk or volume of credits whenever the time period renews. every month, every year, whatever it is. So I continually sort of subscribe to these things, which makes the cash flow more predictable for credit models compared to users models. But then the user or the customer has the ability to only pay for what they use. So the major components, what sort of what modality governs or why it's good or why it's bad in a pricing model is that it determines the cash flow. and the risk. The cash flow and the risk. So for example, with a usage based model, the vendor that's you, the SaaS company, you take the risk of non usage and you collect payment, the cash at the end of the period. So if I have this sort of user space model, it's essentially me taking on the risk and asking for the cash later, which is why A lot of people say, hey, users-based is really, let's say, customer friendly because it's very low risk for the customer. But of course, I would also say that it's a very high risk for the vendor. The SaaS company has no way of knowing of whether customers actually will use the software and they will only sort of pay for whatever they use. So if they don't use it, you don't get paid and so forth. License-based is the exact opposite. There you have the friction and the

point of sale like upfront in the first end of the time period where customers say, okay, I want to use the product so I pay you now. And then so you get the cash upfront and then it is the customer's risk if whether they use it or not. Credit models actually do sort of they split the two and they say you get the cash flow first, but the risk is now shared because the vendor ultimately takes the risk of that the customer doesn't use the product in terms, but the customer doesn't have the risk of they're not going to use the product because their credits roll over into the next period. So they will always get them back, right? So this is how the four different modalities are. Let's say different in mainly these two components, the cash flow and risk. Now the pricing metric is whatever we charge per. So price per user, price per API call, price per active store, anything really, right? So you can have any one of these metrics and then you can apply a license or user or credit system in order to govern it. So you can have a per user on a license, that's seats paid upfront, per user on our usage, that's active user in a certain period. You can have credits on a per user saying, hey, you buy these credits and then we count how many active users you have and we roll it over. So this is essentially what makes it different. Any metric needs to be measurable, meaning that if you can't measure it, you can't bill it. It needs to be legal, of course. If you are not allowed to measure it and you're not allowed to use it, then also you can't bill it. Customers must understand it and they must want to actually have more of it. That's at least a good thing. So and that last point I think is important because Metrics sit on a value chain. So in this example we have here we have some kind of a sales solution that helps people sell so For for this kind of example you say hey our software really helps you make sales and then the customer thing Okay, that means that I have a sales team

and my sales team that gets leads and then they work the lead and then they close the sale. So that is the value chain of the value creation process that happens at the customer. If you are to choose a pricing metric, then whatever metric you choose is going to sit at a certain point in the value chain, either in the beginning, the middle or the end, depending on what you count. So if you count number of sales reps, then you're counting the team members that are at the beginning of the value chain because, they're an input. It's something I need to buy. It's a cost I have in order to get what I want, which is the close sales. So nobody wants salespeople. People want closed sales, right? And then salespeople, they get some leads or they generate some leads and then they work the leads. So at the lead stage, you might have total leads. And then you might also say, hey, we're only going to count leads at a later stage, like a sales qualified stage or commercial discussion stage, where we're saying, hey, we're only counting leads at this later stage in the pipeline. And then ultimately we might say, hey, we're pricing you per closed one sale. Right. So this is the difference between what we might come outcome based or value based pricing. It really determines where in the value chain, the pricing metric sits. Are you counting something that sits at the beginning of the value chain or something that sits at the end of the value chain, which is different from whether something is usage based or whether something is license based. So you can have sales reps on a usage based model. That doesn't mean that it's value based. It doesn't mean that it's outcome based. It simply means that the risk and the cash flow, if it's a user space model, sits with the vendor, with the SaaS company, and not with the buyer or the customer. Whereas you could say, hey, we are pricing you based on the closed one sales that you have. So really, we have an outcome-based or value-based pricing because the pricing that we charge you by is very closely aligned with the value that you get out of the solution. And of course, if we charge that on a license-based, then we're really putting the risk

and the cash flow on the customer, like they need to actually close the sales in order to get the outcome. And of course, if we're saying, hey, we're pricing you based on the closed sales, and we're doing it in a usage-based way, where we also take on the risk and we only get the cash after you get the cash, then you have the perfect combination of those outcomes where people say, hey, why wouldn't I pay you because you only get paid if I actually get paid. and your cash actually comes to me first before they come to you. So the combination of metric and modality is really what governs a lot of risk and what governs a lot of sort of cashflow profiles and value in sort of outcome-based or input-based pricing across pricing models. So when we work with clients, it is really sort of one of these ideas where we try to assess how well their current model performs in a sales context, in a value communication context, and whether the customers of our client actually appreciate the pricing model and think that it is sort of, it is a fair and equitable way for whatever solution that they're buying, right? And this actually has a lot to do also with what kind of solution it is. Like some solutions are much, let's say easier to explain and contextualize in terms of one pricing model versus another depends also a little bit on whether the software is horizontal or vertical. And, but this is really where the rubber meets the road. And you can almost always, if you have a really awesome product that users actually really like, but for whatever reason, they're not adopting it too much. And it's hard to sell all these things. You can very often just rework the pricing model to something that is more outcome based and has a let's say more equitable modality, you can get customers to actually buy and then you can really make a difference in terms of the sales velocity and growth of the company. yeah. The next part is what I call like the extra sort of optional part here. That is pricing thresholds. And before I sort of go through what a pricing threshold is,

I just want to show you. So this is actually a screenshot from the pricing SAS report where we have Miro as an example. So Miro uses a per member pricing metric with a license modality. And they have no less than 11 thresholds. So we see here that the starter pack has $8 per month per member. So this is a license. And the metric is a member of what it is. But then when we see down into sort of the almost like the feature list of both the free and the starter, we can see that in the free, the single workspace has three editable boards and this is a threshold, right? And then we can see over in the starter, we have unlimited boards. And then we have TriMiro AI, 10 credits per month per team. And then of course I can get. Over in the starter package I can get create edit and since this I bought content with mirror AI and I get 25 credits per month per member, right? So that is per member and the others could see okay So what is going on here, right? And we also have talk tracks and number of spaces and all these things So Miro has 11 of these thresholds. So a threshold is Any unit of volume in a given package or plan? So this is something that sits inside of the packaging that is somehow limited, right? So we had three editable boards as an example. And this can come in two distinct types with different dynamics. So you can have a soft threshold. In the mirror example, these are the AI credits, right? So it's like, hey, you'd get 10 credits per month, but you can probably buy more, like that's the idea. So that's why it's soft. It's just a paywall, but we actually Encourage you to go above the 10 credits. It just has a price. So a soft threshold essentially is a Pricing metric there is a modality as well, but there is some sort of included volume So we're saying hey a soft threshold just like we're giving you a number of this metric in the Package or in the tier the product that you have, but if you want more then you need to pay

And this is in contrast to a hard threshold, which is enforced. So you can't just pay to get more of it. So in this example, it would be the editable boards, because the only way in which I can get more editable boards in Miro is by upgrading. So it's actually changing products from free to starter. So we are often using these hard thresholds to drive adoption. across a packaging structure, so up to a higher tier or into an add-on or some form of that. But we actually do not allow with a hard threshold any additional volume inside of the existing product. If we allow for additional volume just to pay to have more volume, then it is a soft threshold. And then essentially it's just a pricing metric that is just hidden, stuffed into the packaging. So I think The idea here is to have this taxonomy or understanding of what's going on with different sort of what actually constitutes a pricing model. So if you have the modality and you have the metric and you understand what these thresholds are, whether they're just like hard or just trying to drive your packaging or if they're just hidden pricing models inside of the product, that can be, that is a really, let's say, comprehensive way of explaining different pricing models. think it's solid. We have used it to explain hundreds of different pricing models without ever having to like come up with exceptions. So it's actually the taxonomy is pretty strong as we find. I want to add another comment on thresholds and that is that I actually don't like thresholds that much. So soft thresholds that can be fine. Fine meaning that Soft thresholds usually just allow you to buy things. can have a lot of complexity from a pricing perspective. so you'd really have to sort of choose how much complexity you add to the model. But overall, that's OK. Too many hard thresholds create friction with the customer in the following way. So imagine that you have two hard thresholds. So let's say number of editable boards with Miro and five talk tracks. So that's what we have here.

So what usually happens is that either these two things are correlated or they're not correlated. So you say, hey, is it so with most customers that we hit three editable boards and five chalk tracks at the same time or totally independent of each other? And my argument is that if you always hit them at the same time, so if the difference or the metric that we're measuring here are very correlated, then why would you have more than one of them? Like if they're correlated, you can just do boards or talk tracks. You don't need to have two of them, right? So then they're just like extra like fat on the model and you don't only actually just need one. But if they're not correlated, if it's so that, hey, some people hit like editable boards, but they're actually still at one talk track or vice versa, someone needs a lot of talk tracks, but not a lot of editable boards. Then what happens is that the customer hits that threshold and then they say, hey, okay, so to get more, I need to upgrade, but I don't feel that I'm using the entire product yet. So it feels unfair that I have to upgrade just because I hit this one thing while I'm actually not even using all of the product on this other thing. And this actually gets really a lot worse if you have a lot of these hard threshold. So. I worked with a headless CMS system that had no less than 14 of these hard thresholds and every customer sort of had hit one of the other threshold and then they were always stuck and nobody really wanted to upgrade until they had hit most of the hard thresholds. So there is a psychological barrier where customers feel unfairly treated or unfairly priced if they have to upgrade just because they are like out of bounds on just one of these. They want to sort of feel that they fill out and use all of the product before they upgrade. So I usually say, hey, thresholds are fine, but limit them just to just the one that really matters. And then you can solve the rest with just having a really good pricing metric with a good modality. And that usually takes care of the monetization for you and will create a lot more adoption than if you try to nickel and dime customers with having a ton of thresholds.

Because usually, at least in most of the projects I work with, having a lot of thresholds is a symptom that the team that's doing the pricing doesn't really need, doesn't really know what actually creates the value. And there is this sense that, we're leaving a lot of value on the table. And if customers are using a lot of the product over here, a lot of product over here, a lot of the product over there, then really we should try and monetize it. So we're creating all these barriers. so that if customers use more or less than this or the other volume, then they need to pay. And reality, you're creating this very ungenerous environment where customers don't adopt and also very rarely they actually don't pay you that much more. So I have had a lot of very transformative pricing projects where we just took away a lot of the thresholds and we just created a relatively simple, straightforward metric modality combo. that just priced well and governed risk and cash flow well. And then we saw really the product take off quite a bit. Okay. How are these used? How does it actually look out there in the field? So this is all pricing SAS and their scraping tool, their database and how they have compiled it. So the first thing is how many of licensed users credits and flat fees are there actually there? And if we take a look at it, we can see that license models still are the most ubiquitous model. So most of the models we see out there are licenses in that. You get a right to use, you pay it upfront, and that's how goes. We have a lot of usage models as well. So that has become more and more, let's say, the norm, especially because you have billing systems that can actually govern this. You figure out how to send invoices. So a lot of this is actually also the underlying sort of supporting mechanism in tech stack and in finance to actually execute on a usage-based model. We've seen a lot of these tools come out in the last five years.

So I think that's definitely a part of it. And then we see credits, creeping up, flat fees creeping up. I think we're gonna see a lot more credit systems in the next couple of years, especially because of a lot of the AI products and also functionality is being run on credits. So I think we're gonna see this almost, I don't think it overtakes usage, but I think it has a really... I think maybe on a revenue basis, it's going to overtake usage, but maybe not on difference like how many pricing models actually out there. But I think some of the most successful models we have are going to be in credits. And I think a lot of revenue is going to run through them. And they're also really, really good at handling very complex models with a lot of different variety inside of them. So if we take a look at the combinations like where we say hey, we're using license and users or usage and credit. We can see that the combo of license and usage is very common compared to the other combined product pricing models. We can see that uses and credit, credit and license is, this is around 3%. So this is sort of where you have like a few companies doing it. And then you have about 1 % that is doing all three where you have. a lot of different complexity across the price. But licensing usage, where you have something like, hey, this is what it costs to use the software to have access and rights of use. And then we have some elements where if you price and storage or API calls, so there are some infrastructure metrics or other things, we're going to price you based on how much you use it. And that can be also a really good way to both sort of get some cash upfront, but also cover your costs in some of these models. If we look at it on category, we see that something like project management, Asana, Monday.com, Trello, these things, they are heavily based on licenses. And then if we go sort of down and see sort of who is sort of, let's say the least based on licenses, we have a lot of the different sort of infrastructure related and horizontal and horizontal related DevOps, data analytics, machine learning.

especially the ones where you have a lot of different cloud costs and infrastructure costs. They are usually based on usage or credit models and so forth. But when you're at serum systems, workforce management and project management, that's where you have the license. And this was what I mentioned at the beginning where I hey, there was definitely some intuitions that I think have been proven right with this analysis that the pricing SAS did on the marketplace. So I think this is just like really interesting to take a look at. Does this mean that this is a recommendation and this is if you're a project management tool, you should have a license? Not necessarily. I think that entirely depends on your particular product or solutions take on that category. So it isn't necessarily a recommendation, but at least now you can see how other people are doing it. If we do the usage modality, you can see that it's almost inverted. So project manager now only sits at 3%. where Cloud and DevOps have So it's almost inverted on category who uses what for the exact same reasons as with the license modality. And then finally, we can see credits, which is sort of interestingly actually with the CRM system. So if you take CRM systems, we go two up here, they're the license model, but actually they're also some of the leaders in the credit modality. So Cloud and DevOps is leading it. We have a lot of these sort of infrastructure related place where you can see this. And then also in serum systems where you essentially have rights to, for example, do some marketing automations and so forth that runs there. So in the pricing SAS report, you see a lot of different examples. They have example pages for each of them where they actually link to the pricing pages of all the actual companies. where you can see how it is actually sort of done on their page. So definitely go and check that out. Okay, that was the talk. So.

We'll go to the Q &A here. So again, if you have a question, you go to the chat over on the right hand side. For whatever reason, can't do the. The you can't sort of like voice in your questions, so you have to actually write it over in the chat. I will just you know go from top down. Just just taking each of the questions and just try to answer the best I can and then. If. If there are too many questions, we'll take it over to the forum on community.pricingSAS.com. This is also where you can find the slides and where you ultimately will be able to find the recording once it's slide. OK, so questions. And thank you for letting me just talk at you for half an hour. So let's see here. Maya just registered on Discord. That's great. So Chris asks, would modality be a kind to the term monetization? Not really. think the pricing model overall is how you monetize. actually, interestingly, I have found that the biggest sort of like ability of a pricing model to really monetize the value actually has something to do with a specific aspect of the pricing metric, which is density. So I usually score a pricing metric on a few parameters. Actually, I think I might have it open over here because I thought this might come up. So I'll try and sort of open this up. This is just a template that I use for some of my, yeah, so whenever we're evaluating how to structure pricing model in the consulting projects we have. So we just like create a different sort of, like a list of different sort of potential.

Yeah, metrics that we have. could be this is a little bit like a seafood concept. have salmon, monthly active salmon feeding kilos. I'm actually doing a seafood projects right now where we do tons of output on aqua farming. And then we say, what's the modality that might actually be like a license. And then we ask a series of questions to customers understand it. Can we define what this is? Can we measure it? In which case, if that's three yeses, then we have like it's operationally viable. Then we ask, do we have demand for it? That's essentially the question of where in the value chain it sits. Then we can ask if we have a high expectation to pay. It's a technical term, so the easier term is just fairness. Your customers think it's a fair way to price. And finally, we have density. density would be, let's say you a user for a different system. And then you might say, hey, we have a type of user that is a high level admin user that is using a piece of software. Let's say I have a project right now. We're doing the cyber security where we have like the head of cyber security and we have the cyber security specialists inside of an organization. And then let's say below that in the hierarchy of this product, we have all the white collar employees that have access to computers. And then maybe below that, have all the blue collar employees that don't have access to computers. They just have access to machinery. And then for product like that, we might say, hey, if we just price per employee in this setup, we have a really low density, meaning that the cyber security professional and the blue collar employee have very, different value in this particular instance. So if we try to run that as a pricing metric, the customer will say, well, I know I have these really high value users that are really very relevant for the solution you have, but I also have a ton of these very low value users relative to the solutions you have. So I really would like to only pay for the low value users. So what happens is that SaaS vendors tend to look at the average value of the metric they have.

where SaaS customers tend to look at the medium or low end of the value inside of the metric they have. So if you're, say pricing per sale might be more sort of quantifiable example, and some sales are worth a million and other sales are worth 10 bucks, then even though the value on average might be 100K, the customer might say, hey, yeah, but if you charge like based on 100K, I'm losing money on all the... on all the $10 sales. So I actually want the pricing to be anchored to the $10 sale because I don't want to feel that I'm losing money on some of the things that you charge me per. So density is the clearest correlation I have found in this architecture around what really sort of gets at monetization potential. Because if you have perfect density, Stripe is a good example. So Stripe charges per transaction. not necessarily a of density, but they also charge you a percentage of dollar value of the transaction. And $1 is perfectly worth as much as another dollar. So dollar value has perfect density in a monetary system. So when they charge you 2.9 % of the process payment, they have perfect density. And that means that they can monetize the value extremely well in what they do. So they can charge you 3 % of the gross merchant value. which is if they just charge per transaction, then that monetization potential will be way less. So that's what I sort of, how I think about monetization across these things.

Chris says that he has a poor network connection and his screen freezes every minute. And if I'll be sending the recording, yes, go to the community page, there will be a recording, it will not freeze. I'm sorry about the connection here. Ray asks if I can provide another example of a credit pricing model. Yeah, so I think the most sort of ordinary example that most people know is Audible. So audible.com. where I buy audio books or I buy e-reader books. Basically, it's a B2C model. I go in, I have a subscription every month, I get five credits, 10 credits. I go in, I can exchange a credit for a piece of content like an audio book and then it's spent. And then when I run out of credits, I can buy more or I can wait until like the next time period where like next month I'll get more credits into my account. And that's basically how it works. And you can do that with I have done that with open source partnership models for CMS systems. I have done it for infrastructure related DevOps a lot like these kinds of things. I have done it for machine translation for a ton of AI products. I've used AI credits. very, because it has a, it feeds adoption quite well and also handles a risk. quite well in terms of usage. I've done that. But audible is the most common example that you have anywhere. Can you explain flat again with an example? Is the question my most? Yeah. like a flat fee is just you get access to whatever the solution is for as much of whatever the solution is. And there's just a number and that number is the same for every customer. So Netflix was a good example. It costs you whatever 10 bucks a month. 20 bucks month, whatever the price is to access Netflix. And that's it. It's not pricing you per anything. Like the per essentially is you as a customer. So it is a price per you, which is always one, right? So that just means that there is no, the price has never arrived at by multiplying by something else. Blockbuster is a user space model. I pay for every movie I...

rent, right, or buy. And then that's how that goes. But Netflix, flat fee, I just get everything. Annie Ruth says, credit feels like tokens at a game arcade. Yeah, like exactly. Credit model. The big friction point is always, I don't want to play game A anymore. I wish these leftover tokens would work on games B, D as well. Do you know of vendors that have large multifaceted SaaS ecosystems where they've trialed a universal credit approach? where customers can pay for credits to access any software on offer by the vendor, not just the one use case. Yeah, so I mean.

I've actually just invested in that company more or less. It's called PixelPie, P-A-I, which does that exactly thing for Web3 games. So, yeah, check that out. But I'm just like major plug here. So for others, would be audible, I guess. It's sort of like you have a marketplace where essentially everybody else comes together with their concept, like the audiobooks and so forth. And Audible basically provides access to all of that through a credit system that then handles the complexity. It is actually a really good, I don't know how they work. I think Coursera and Udemy and some of these like content platforms have credit-ish models where they, like you can access a lot of different offerings from like sub-providers. So I think that works in similar ways. You might say that anytime I have some sort of an account where I pay in and I then get to spend on something else, it works. I've actually used that in groceries. So I had a grocery vendor that happened to also have a banking license and we actually said, hey, if you prepay like every month, like a hundred bucks onto this account, we'll give you like 105 or 110 worth of grocery spend. and then also will give you access to like special deals. And that actually made a lot of people just upload their entire grocery budget to the grocer and it also increased basket size quite a bit. it worked wonders in terms of customer retention. So it's like you can really use credit models in a lot of different spaces. There is a lot of different sort of, let's say technicalities around when you're a bank. So your bank, if the credits can be paid back out in cash, so generally you don't want that. And then also you have some revenue recognition issues. So credits have to rot or expire at some point if you don't want to have this unlimited liability on your balance sheet where you always own credit somewhere. So it's a little bit like points on a loyalty card. If they don't expire, can be, it can be,

detrimental to your balance sheet. Okay, Jared asks, on thresholds, do you see that customer behavior is to stay under soft thresholds to limit cost? Depends on the case, right? So I would say that sometimes it's just so naturally baked into the product that you just use more of it. So I've used that, for example, Last year I built a model on AI machine translation where we had a software where said, hey, you get a bunch of these credits that are prepaid, you just use them. Whenever you hit this limit, you have to buy more. And that was essentially how we chose to sell that product. And that worked really well. So it really depends on what the product actually does and how the, let's say, PLG motion, like how how the usage interface presents that purchase to you, I would say. And then Jared asks further on variable models, usage credits. Do you see, especially in B2B space, that finance teams frown on variability due to the desire to have stable budgeting? For sure. Also on the customer side, right? So I would say that credit models actually... take away a lot of that variability, right? So because it takes away the cashflow variability, only, like this gets a lot of finance technical, it only produces a more variability on the earnings, right? So you'll have to sell the credits, you get the cash, and then the credits go on the balance sheet as on-end revenue. And then whenever the credit is actually spent by the customer, you can then book it as revenue, right? And then, but if you say that, hey, the credits only expire, they expire after two years and there's the your finance team will know if I say they're used on a FIFO basis like first in first out so you always use the oldest credit first they usually chill out and accept it right so so that's that's what we have here and I can see when I start to talk about finance stuff the the number of people in the call start to drop dramatically so I'll move on Jared Steve asks here

I'm curious what your thoughts are on the role of feature packaging in a credit model. If a key objective is to encourage experimentation, then a person that don't like the idea of feature packaging in a credit model because it puts certain features behind a paywall that I want users to explore. I'd rather just tie the features that matter to the credit's thoughts. Yeah, I think you're mixing two things up, right? So if you have, say, really power, I'm actually doing exactly this thing in a pricing model for a US customer right now, where we are saying, hey, these advanced team type features where we have some collaborative functionality, that's for a different tier. But on the base tier, you get more like single user type functionality, but the usage essentially governed by credits in both instances. So I think if you have a really clear differentiation between what job you're doing in the one tier and the other tier, I think separating with different features makes a ton of sense and the credit model can run both. Right. So I think if you don't have solid packaging and you're just like good, better, best thing or you're just trying to say, hey, these features sound like advanced, so I'll put them over here, then you can get into a lot of friction. But that's more like a packaging issue. If you have good packaging, then credit models are not going to disturb that at all. They're actually just going to empower it. Maya asks, token usage and credits for AI products, almost cost-based pricing. How to do a pricing model in a way that customers get it and that you do not go broke for them loving the product? Yeah, so I'd say that the reason that credits are great is because they are bought upfront so you get the cash and then customers get to sort of play around with the product and they don't feel they lose if they don't use it. So it's like, The risk is actually borne by you a little bit more than the customer, but you actually get the cash upfront. So what I tend to do with AI products right now is that nobody knows, and I actually said this in the last webinar, I think last month, like nobody knows really how your AI product is used if it was based on a license model. Like if I just had to, like I just pay like my Netflix fee, 20 bucks a month, and I just have unlimited uses of the thing, right?

then you incur all the token costs and if somebody uses it like a lot, like a million times, then you're losing money. So no bueno, that's why we put in place the credit models and the users based models and so forth. But then that actually limits usage. So you have this catch 22 where you don't know what is blocking the adoption. Is it the pricing model or is it the product itself? So what I usually advise people to do is to say, hey, if you have a bunch of customers, like you have a hundred customers, pick a few like three or five and then as a sort of almost like close beta, give them a license model. Like just give them unlimited usage for your AI product, even though it might cost like you can always turn it off and go if it goes crazy, right? And say, Hey, I made a mistake. But, but let them experience the product without having the sense that they need to pay every time they push a button or they do something and then just see how it goes. And then you can use that to then say, Hey, do I want to use that for all of my customers? Or do I just want to build a special pricing model around it, whatever it is. So you can have this experimentation mode across different pricing models with some of your customers, especially for AI, when you're not sure yet what actually is driving adoption of the product. That's how we usually do that. And then you can significantly reduce the cost risk if something goes crazy because it's only a few customers. Katina. you need to run, that's fine. Marina says, it seems that the only pricing model used in mobile apps are monthly or yearly license payments. Do think this will change in the future? So I don't agree. Like I think Uber, example, mobile app totally uses based, paid upfront, right? So I pay for the trip, I buy. So it's like, I think, but then, Of course, a lot of licensed models are there, like that's how apps started. But I think a lot of apps are basically pricing you on a ton of other things. Some of them are marketplaces, some of them are not. But I think you have all kinds of pricing models also inside mobile and also inside B2C. So I think the more advanced models are more predominant in B2B, but it's not an either or.

Or you seen asks which category or section the recording will be under in the community. I don't know, so you just have to look out for it, but it'll be there like if you look for it, you'll find it so to give a look tomorrow. KFS asked if I mind sharing the spreadsheet. No problem, I'll share the spreadsheet as well, so you can have a look at that. It's actually yeah, I've been sharing it with my customers for years, so it actually is the mystery to me that it hasn't sort of gotten out yet, but sure. Steve asks, do you have any thoughts on price models that generally work well for horizontal platforms? The biggest challenge is our customers get widely different amounts of value and it's very hard to find a pricing metric that get anywhere close to scaling with the value delivered across so many unique customer types and use cases. You're spot on Steve. So what you're experiencing is that you are a horizontal software and that means that you are not supporting one value chain, you're supporting multiple value chains. So you're basically providing the input to a lot of different outputs, right? So you have a single tool that sits at the beginning of a lot of different value creation processes. And this is sort of the case with a lot of horizontal software is that it's really, really hard to do outcome of value-based pricing in horizontal software because horizontal basically means that you are at the input end of a lot of different value chains, right? So I think you have Two options. and maybe a hybrid in between the two. Option one is just to embrace it, just say, we don't care. We're just going to be a really good input. We're just going to lower the price, and we're just going to go for it. Two is that you find the one avatar of vertical where you can provide a ton of value and just don't sell to anyone else. And then you stop being a horizontal software, and you become a vertical software.

And then the in between version is that you say, hey, we are going to fence different types of verticals. And then we're going to just price that. So what do I mean by fencing? So zoom pricing. Let's do that. See what we have here.

See if we can actually get Su's pricing page to work. So if you see up here, right, plants and pricing, Zoom has individuals and businesses, they have enterprises, that's basically sort of what they have, and then they have industries, right? And industries basically means that Zoom that has education, healthcare, developers. So this is sort of where Zoom has this issue where they're saying, hey, we are a horizontal software, like we just do meetings, but like developers and other... types of organizations are getting more or less value out of us and education doesn't have any money and healthcare is neither. So we want to price them lower than we want to price businesses. So this is why I call it a hybrid attempt to basically get closer to value creation for some of these verticals that they're serving and they use fencing to do that. So that's basically the trick. Is it elegant? No. Does it create a lot of different complexity in the model? Yes. Does it make you money? Sometimes, right? So those are the options you have. So Olivier says, how to make credit based relevant. For example, if I sell a number of credit, people will make the math and calculate what's in it for me. And is that a bargain? Usually we see big number and we do not get the top, but what would be the best practice here? In addition, can we mix license and credit to the same account? For example, we can target a Occasionally users with credit and regular users with license, right? Yeah, so so. It isn't a problem at all that that people just calculate what they get for each credit. I think that's a feature, not a bug, right? So you should just say hey, of course, like let me do the calculation for you, right? So I think that's fine. What it really does is it says hey. You can.

We want you to commit to using this and we want the cash upfront for providing the access to this thing. And then you basically get to spread your usage out over time. Then if I combine it with a, I usually don't necessarily combine it with a license model. You can, but I sometimes combine it with a pay as you go model and say, Hey, you can subscribe to the credits and then it's whatever $1 credit or you can buy the credits. without a subscription, but then it's like $2 credit. And then you decide if you want to be on a subscription for it, or if you want to be on a pay-as-you-go model. So I think that would actually be like the combination credits and transactional, if it's either or, is more usual than something else. All right, last question. that's Maya asking, like answering questions here. Edward says big companies love flat prices. have always have cost budgets. And I would say, no, they don't like flat prices. They like predictable prices. And there's a difference, right? So a flat price is not necessarily the same as a flat price is always predictable. but a predictable price isn't always flat, right? So you can basically say I have a license per user and then that's super predictable, but it's not a flat price. So I think for enterprise, solve for predictability, not for flat. All right. There's a little bit of extra time here. I know that we're at time. I appreciate the questions. I appreciate the attendance. I appreciate the community. So. We have a bet going on on how many people we can get to join the community. So make me win. Go there, community.pricingsass.com. Sign up. You can get it done before your next meeting. So go there and then also find the invitation for the next webinars and the next reports and find the full report. I only showed you like a teaser. yeah, so that's where it's all happening. Thank you so much for tuning in, guys.