Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth and I'm Lead Advisor and Senior Analyst with KuppingerCole. My guest today is Martin Kuppinger. He is Principal Analyst and one of the founders at KuppingerCole Analysts. Hi, Martin.
Hi Matthias. A pleasure to talk to you.
Great to have you. And this time we want to look at a specific topic from a different angle. And I start with a situation that I encounter quite often when it comes to selecting solutions together with our customers. It's part of the tools choice process. This tools choice process is a well-defined process that starts from requirements, use cases, boiling down to capabilities and services, identifying the right products, and then talking to the vendors. And as part of the communication with the vendors, we, of course, ask them technical questions. We ask them organizational questions, we ask them service questions, how are they prepared for providing the right support for our customers? And in the end, we ask for a price. We ask for licensing details, we ask for, How much does it cost for a defined period of time or for an overall license plus support and all types of support in that. And that is the point where we are in a situation where we often have to align very different types of licensing schemes, licensing models, subscriptions compared with just buying a piece of software and everything in between. And that makes things difficult. We support our customers in that and we help them in getting a grip on that. But is this necessary? What should a proper licensing model look like that has also the customer in focus, not only the money that an organization gets from providing this software to a customer? What are your thoughts about proper licensing models, Martin?
Yeah, it's an interesting question because from an analyst's side, so to speak, we look at it a little bit from a different angle. So you guide the customers, which usually their procurement departments, got some quotes, and then they ask you and say, What should I do with these different numbers which don't fit each other? Or earlier, you are asked, so for what should you ask? What are the numbers of users and systems and other things to send to the vendors and to ask for a quote? We look at it more from the perspective of discussions with vendors, which come to us and say, okay, what would be the right way to license this? What would be the right license model? And I always start with a question that is, What do you believe is the most important element of a good and successful licensing model? And quite frequently it's that they come up with "cost". I have a strong belief it's not cost. Cost is important, clearly. If you're way, way more expensive than the others, it will be hard to sell. You'd need to be super super good, in the way you sell and in your product or service. But the point I make is it is about predictable models that can be easily understood. This is related to the customer because, at the end of the day, the customer must define a budget or gather a budget and must predict to the management, to the stakeholders what the price will be over the next couple of years. And if you can't do that, it is problematic. So I'd like to bring up two examples here. One is really from my past, when I started using the internet in the very early days of the Internet, there were quite a lot of offerings where the cost of Internet connectivity was based on the volume of data transfer, which meant if you had a website, it was very successful. It could end up with you paying quite a lot of money. That was not predictable. And these models very quickly disappeared, becoming replaced by some sort of flat-rate models. That is, I think, one very good example of why such approaches tend to fail. So models that are hard to predict are problematic. Another example is when you look at solutions for SIEM, security information and event management. Several vendors had or still have models where the price depends on the log data you manage, the amount of data. And that is from my perspective to totally absurd approach because you're penalizing the customers for making more use of the solution. The more data you have, the more data you can analyze, the better the results potentially will from that security analytics. And penalizing sort of prohibiting to put in as much data as you can is from my perspective, I think we can use the term nonsense here. And so licensing models, might just not work or just turn out to be wrong.
I would fully agree. I have an example. When we look at the identity and access management market and if we look especially at the consumer-focused areas, if you have a successful product, a successful service, and the number of your users rises, how do you prevent from being killed by success with the prices going up at a level that does not match the actual success of the website or the service or the product?
Yeah. And it's interesting, we had this scenario in quite some engagements it is that you see a product which says, okay, workforce user costs, whatever, x euro per year or month, and a customer costs maybe 1/10 or 10% of that. But why 10%? I never met a vendor who could explain why it's 10, not 8 or 15 or 3%. And as you said, it also doesn't resonate with the requirement for the predictability. And so once you are in these discussions as a vendor with your customer, customers quickly get the impression that they are not treated fairly and that is what is damaging your relationship. So it is important that customers can understand what is this license, that they perceive this as something predictable, that is also fair in the sense of, okay, it's the right thing to do it. It must be well measurable, for sure. And all these things come together. And so models that have, for instance, for very volatile things like the number of customers more sort of a flat rate model or something which says, okay, the success won't kill you from a cost perspective, tend to be from my perspective, the better ones. It's not always easy to come up with a good solution for these models, but it's relatively easy to identify things that definitely don't work and resonate well with the customer.
And what we also might touch is then the other aspect, which is, how elastic must license models be these days in the age of software as a service
Okay, when you say elastic, that, of course, means elasticity, and that means, it really is being capable of scaling between very slow starting and implementations to a very large, growing, and still being capable of being, as you said, predictable and possible to estimate. What other dimensions of elasticity do you think of?
I think that you touched on two important points. And what I observe in the market is that these are frequently not understood well or not considered as right. So the one thing is, you might implement an identity management solution, maybe in the field of IGA, identity governance, and administration. And that might take you... even if it's a SaaS solution it might take you a while to connect services to onboard your users. So, it might be that you have at the beginning 100 users and after the first quarter you might have 1000, and after the first year you might be at 10,000 or 15,000 and it takes still a little until you're fully done. Most vendors will ask you to pay for the full 20,000 users from day one. I think no customer would say this is fair. And so that is one element of that and the other is that the numbers of users might go up and down a little or other factors might go up and down. So why should you pay for your office application from the cloud when you have more or fewer users for the ones, especially if it's less, for the ones which are not using it anymore. And so for instance, I have seen scenarios for CRM solutions where you have to onboard sort of the full set of users and you have to subscribe for three years from the very beginning. So if an organization migrates to a new CRM solution, how likely is it that they will go back after six months and say, Oh we take the next one, and then another six months they move again? That rarely happens. So if this decision is made... yes, they might say at the very beginning, okay, this was a fundamental mistake to stop this project, but most likely it is that they will stick to the solution for many years so the risk for a vendor is very low that the customer will go away. So why push the customer into three-year contracts for a fixed number of users, which you control but not decrease? This is not fair. And there's no validity, there's no logical reason for doing so because the vendor probably would even benefit more. But rarely less. But so the customer's annoyed and this is not a good strategy. It's a bad licensing strategy. Or IGA solution in the cloud where you have to subscribe for 12 months or more. If you shift to that IGA solution how likely is it that you will go away from that quickly? So why not go to a monthly elastic fee? It will not cost fundamental harm to revenue, but there are a lot of positive things in that. And it's really that the vendors frequently ignore these facts. And I believe this is very important and then it also makes it way simpler to compare. And I think this is one of the challenges you have. How to compare different licensing models if they are not predictable? If they are very well predictable it's relatively straightforward. If they aren't, it's hard.
And having a predictable and estimated pricing model makes it much more possible to have a recommendation towards a product because once you have the proper product identified from a capability perspective, you cannot say how much it will cost over time. This is difficult to get to a proper decision that can be presented to senior management, that can be presented to those who spend the money on it. But on the brighter side, maybe one concept that has shown up recently that is quite interesting, this is the MAU concept, the monthly active users, especially in the consumer identity and access management, where you only pay for those users that are not stored within the systems but that use that system over time so that dormant customers that only buy a product for Christmas and otherwise not that they will only be charged for when they are active. I think that is one of the brighter sites that we see currently in that in these markets, right?
Yeah. It has some level of predictability. It needs still to predict the peaks. But it relates to cost to the success which makes it fair and so that is something where I say this makes more sense than many of the other models I've seen in the past. And again, maybe back to this example of CRM solutions. You know, when the customer says like it was in our case, for instance, Shall we go with this vendor? So if there's a huge risk so that a customer just says, okay, I go for another vendor due to the licensing model, then you've made a mistake. And I think it is doable to think through licensing models so that they are fair, that they are perceived as being fair and predictable by the customer. And that they still deliver the revenue. the ARR, annually recurring revenue to the vendor, to the provider as expected. And this is doable and these common pitfalls can be overcome if we play probably your life in supporting customers and comparing license models and license costs, more easier. Yeah, it would also simplify our work as analysts in inquiries on this topic.
Right. So we will continue our discussion on different frontiers. You will more talk to the vendors when it comes to vendor advisory and support them in finding these fair and proper licensing models. And we from advisory, when we talk to the end-user organizations, we will try to help the customers in understanding what an actual pricing model means to them and what the actual expectable figures are. Thank you very much, Martin, for that conversation. That was interesting and it's good to see that we have at least more than one lever to influence that as well. So really looking forward to getting to a better situation here as well. Thanks for your time and thank you for joining me and looking forward to talking to you soon again. Thank you. Bye-bye.
Thank you, Matthias, bye.
