How to Price When Users Aren’t an Option with Zuora VP, Product Marketing Lubor Ptacek

Hi, good morning and welcome to SASA Annual. You are joining the roundtables. You are in the right place. We are joined this morning by Lubo Pacek from zora and we are going to go into some housekeeping items to start off the day and then dive into the session. All right, so this is an interactive session. You likely joined with your cameras on. So, hello everyone. Thank you for joining us this morning. We are here. You are muted, but you do have the option to unmute yourself, raise your hand and ask a question. It is interactive and we encourage you to do so. If you would like to raise your hand, you can do so with the little button where it says Participants at the bottom, a little icon, and do so. You can also use the chat function, which is in the bottom screen of Zoom as well, to ask questions. And we'll be able to take those and facilitate those throughout the session as well. Again, these sessions will be recorded so that you will have access to it after the fact as well without further delay. I am so excited for the session to introduce and welcome Liubo to the session today. And we have 30 minutes, action packed. So looking forward to it. Over to you, Devorah. Thank you.

Awesome. Thank you, Tammy. And good morning, everybody. Thanks for joining me this morning. So I'll go straight through it. As Tammy said, this is meant to be a round table and interactive session and I really hope that we'll get a little bit of a discussion here. Of course, we are all still experimenting with using Zoom only. Normally these sessions would be live in person, hopefully over a breakfast or dinner or something like that. But I'm sure we'll figure it out. I'm your host and I don't provide a full lecture for 30 minutes here. I prepared a couple of slides to get us started and so I'll kind of dive into those. But then I really would like to hear from you. The topic I've selected for today is a pricing topic. And at zora, we deal with helping companies run their subscription business. And so pricing is sort of very closely related to that. A lot of people are trying to figure out how to price your subscriptions. There are simple models and there are more difficult models. And I've been recently dealing with some challenges around a pricing model where the user count was not an option. I figured, wow, that's kind of an interesting thing. And there's going to be a lot of companies that have this situation where it simply doesn't scale by users. I want to just make sure that we are all talking the Same language. When I think of pricing, I think of three different dimensions of pricing. There is the functionality dimension, which is basically the features and how those are packaged. There is the usage dimension, which a lot of people are talking about, pay as you go, and those kind of models. Then there is the scale package, which usually makes sure that a small company, small deployment, costs less than a big deployment. And so maybe just kind of few words about those. So the functionality is pretty straightforward, right? You have built some technology, you decide to package in a certain way, and then there are different models, how you package it. There is the product suite model, which has been made famous by the Microsoft Suite decades ago, and it's basically a collection of somewhat independent products that can be then used together and sold together. Right? There is a good, better, best model, which I think companies like Salesforce use it today, where you have the essential license and the professional license and the super duper license. And that's kind of how you package the very common model, the platform and apps. And then there's all kind of other models, all you can eat, and you'll probably find few. But this is, this is usually the simple part. You decide sometimes driven by the architecture of your product, how you will package the products. This is the functionality bit. And yes, each package gets a price point, so that's kind of a first step. And you usually have to consider the relative value of those packages next to each other. So in the good, better, best, you would expect that the good package is probably the cheapest and the best package is the most expensive. And you kind of have similar considerations when you go through the other models. The second bit is the usage. And there's a lot of buzz about usage. Some people believe that you should only charge by usage, but we actually are looking at the data because our customers, we have over 1,000 of them, they are running their business through our platform. And so we actually see what's happening. One of the things that we studied was that usage by itself is not the healthiest model. It tends to be quite lumpy. And that lumpiness is actually uncomfortable, both for the vendor as well as for the customer, because they want to have a predictable cost as well. And so we actually found out that if you get the usage balance right, so usage versus kind of the fixed cost every month or every quarter or whatever, that there is kind of a healthy balance. And if you get that balance right, you actually will accelerate your growth. So we found that the healthy bands is somewhere between 10 and 25% of your cost should be usage so not all of it, only no more than 25%. Those companies that do that, they tend to grow 30% faster than other companies. So it's an interesting data point. Usage is something to consider, but you should think that that might not be everything that you put into your price point. And I know that there are some examples like aws, which kind of put heavy focus on usage only, but I would argue that they probably get away with it because they have such a dominant position that a lot of tech customers have no other choice but to go along with it. It's not necessarily how they want to price. And if you have any doubts about it, talk to your procurement person how happy they are with that pricing. Then there is the scale. And that's what we will be talking about, the scale. The logic behind it is simple. A small deployment should cost less than a big deployment, usage aside, even if there is no usage. Because like I said, usage can be quite lumpy. And we've seen many customers, especially in the last six months, their usage might have gone down to zero. We have fitness gyms providing subscriptions, their usage went down to zero. They still run their software and you still need to price them because you have cost of goods. And so you kind of need to make sure that you are charging something. And then the logic should be that small deployment should cost less than a large deployment. Well, usually this is ensured by user count. And it's kind of pretty simple, right? If you look at something like Slack or Docusign or Box or, or even Zoom, you would understand naturally that, hey, I don't know, Slack deployment for five users is probably going to cost less than slack deployment for 500 users. Yet the feature set is exactly the same. There is exactly the same number of features, the same functionality. Obviously the value is growing with the users and so that's your scaling factor. But what do you do when there are no users? When your software runs without users of that is the ZORA software, where some of the most sophisticated deployments are fully automated. So there's actually no human hand touching anything. It's just automated. And I've seen a lot of the process automation companies kind of in the same boat, right? All those RPA robotic process automation deployments, they also tend to be kind of hands free. Something has happened just automatically in the background and no users are involved. So how do you scale in that case? What is the metric or what is the mechanism by which you ensure that the small deployment costs less than a large deployment? That scale has something to do with the propensity to actually spend. The bigger companies are ready to spend more money, they expect to spend more money. Whereas if you are selling to a small startup, they don't have a lot of money. So you kind of have to account for that as well. So what do you do in that kind of situation? Before I open it up for a discussion, and I'm really hoping that you will be raising your hands or that you might have some questions in chat, so feel free to use that. I'll put in another thought. Right, so there is usually, if you don't scale by users, you might scale by something else. Number of transactions. Right. Okay, it sounds like a logical model, but turns out that that model actually works pretty well when it's a B2C type of scenario where the usage tends to be very transactional and really scales kind of with that notion. In a B2B type of scenario, it's often not the number of transactions, but it's some sort of complexity that actually drives the value. And I'd be curious if any of you have that kind of situation where you have to basically price for complexity and how do you measure complexity? So I'll open up with that and let's see if anybody there, I can see about half of you here on my other screen. If anybody there has got some experience with this. Do you have software that doesn't have users and that you need to price? All right, I see Augustin raised his hand, so feel free to unmute your mic and let's hear.

So we've actually just went through. Actually, let me do a bit of an introduction. I'm the head of growth for IP info IO. What we do is IP data. Well, mainly APIs, but also data sets. So as mainly an API business, there are no users. You integrate the API, you forget about it. Before, we used to price by number of API calls, which was usage, and it wasn't the most successful model. And we started pricing by complexity, by pricing mainly on features so you can get multiple types of IP data. And we've been pricing on how many types of IP data or how complex the IP API.

Calls are. Yeah, that's very interesting and thanks for sharing that. And do you see that new model working better? Do you see that? You know, people seem to.

Yes, especially. And so once we started deemphasizing frequency or, you know, how much the APIs were being used, we saw a lot more. I mean, our clients saw a lot more predictability in their expenses. So they were quite happy about it. We used to be In a very weird situation where we would be asking business leaders, hey, how many API calls per month do you expect to have? And they would say, I have no clue.

No idea. Yeah, exactly.

So we couldn't provide any kind of predictable model, so we just decided to have a tier that offers a lot of API calls and complexity and we start pricing on complexity.

So.

You'Re never surprised by your usage.

Yeah, that's great. And you just actually touched upon something that is really important and that's the ability for the customers to estimate. Because ultimately a lot of vendors have also a notion of committed usage. Right. And usually you get a better deal if you commit upfront, but you need to be able to estimate. And so sometimes these kind of transactional models, like number of API calls is a perfect example, is really hard to estimate because you just have no idea. And especially any software that you write using those APIs made behave very differently depending on the use case. And so it becomes really, really hard to estimate. And yeah, people don't like that. People want to have a predictability. They don't mind paying for value, but they want to see predictability. So thank you, Augustin. Anybody else, feel free to speak up, raise your hand, or just post a question in chat or comment. I'd love to hear your experiences. Right. This is not necessarily about questions. Who else is software that doesn't have any users?

Our software is a little unique. The user count logging into. We have a invoice sync program between other pieces of software. So our user count, you know, is usually like one. But then, you know, we have different customers with very different, different needs to scale. We have a competitor that's pricing per invoice, but I'm trying to avoid that because. Because there's some unknowns from the customer's perspective, how many invoices they're going to send maybe in the future. And I feel like it's better to have more clear pricing and be able to sell it. As this is all in for your number of invoices, I'm thinking about in the future. Right now we're just doing scaling based on feature counts and assuming that the larger companies are going to need the larger feature sets. But I'm also considering scaling or adjusting the pricing based on the number of users in the system that we synchronize with because we can pull that from the API.

Yeah, interesting. You mentioned something about invoicing, and I've went for a while down that road as well. The thing that I've learned is that customers don't like it because it sort of forces them to change their behavior and their customer experience to basically manipulate your pricing model. In other words, if you charge by invoice, they switch from monthly to quarterly or even to annual invoicing, which may actually have a detrimental impact on their customer experience and other issues. But they feel like you are basically forcing them to drive business decisions in a wrong direction. And so, yeah, ultimately I want to go that way because that was an argument I wanted to have with our customers. So yeah, thanks for sharing. And that was Brian, right? Thank you, Brian. Tom Winter. I see you have a hand up and then I see on just a sec on chat. We'll go then back to Phil afterwards. But Tom, go ahead.

Hey, I'm Tom Winter. I'm CRO of Deskler, which is a tool to test developer skills. We help to recruit developers. What I like to say is pricing should encourage abuse instead of limiting the usage because the holy grail in SaaS is actually not even getting the client, but having him and keeping the churn really low. So if we encourage abuse, we actually make our clients use the system. The more they use, the less they churn. That's easy as that. The more they use, the more they are happy with paying more because they get more value out of that. And the problem with users is actually pricing by users is actually limiting the usage in this case. So we're going against reducing churn because that's easy for US as a SaaS company going by users, it's easy for us. So one side of the transaction but like thinking about the value for the client is actually the way we try to encourage our clients to buy our system. That's why most of our competition, like Brian said, most of their competition price per invoice in our case is price per invite of a developer that we will test this way. If we would price it this way, it would be easy for the procurement to compare us. What's the price per invite and what's the price per invite. For every other competition, we are superior to our competition. And then it all comes to Excel sheet, what's the price per invite? And we are compared to whatever tool there is on the planet, which is super cheap. And it's really hard to force like the value show the values of the system. That's why we try to show the value and price for value that we give to the client, not to go like every other company on the market. That's a lot easier to sell to our clients.

Yes, thank you for that, Tom. I Love the term that you said encourage abuse. Love it because that's exactly right. If the pricing model sort of punishes success, it kind of goes against the grain of what you are trying to accomplish. And so it's. You are right. The holy grail is if actually the customers are getting more value by spending more money on you. Not always. Not always so easy. But that's, you know, that's really important. I'll read Phil's question. Do you have any opinions about how to engage with potential customers to zero in on pricing? Seems to be a lot of conflicting views out there. I'm wondering if you have any mental models or thoughts on if you should directly talk to potential customers and if so, the best way to go about it. Yeah, this is a great question, right? How do you actually get some customer validation or customer feedback on pricing? And of course there is kind of the difficult bit is if you ask customers how much are you willing to spend for xyz, they probably say zero and it should be free or something close to that. But that's probably not the right way to have that conversation. I think that the right way to have the conversation is first, what is the value? Tom actually just mentioned that what do you associate with value? Which metric actually represents value for you? In that scenario you start seeing what customers respond. I can give you an example where the value may be invoicing software which Brian mentioned. I think it might be the amount of revenue that you invoice or it might be the number of invoices. You have to have that conversation with your customers and see where is the pain point. And that gives you a lot of guidance. The price points itself, picking the right price point, is it going to be $10 or is it going to be $12? That's sort of something you experiment with. That's usually not as hard to figure out as the model itself. The model is the difficult bit. The price point itself usually have enough data points to experiment. If it's enterprise software, they will tell you via discounting if you are too expensive. And most enterprise software companies have plenty of experience in discounting. That's the one skill you don't need to teach your salespeople by the way, they are all very good at that. But the model, that's kind of a tricky bit and I think it's very important to have those kind of customer conversations. Augustin posted another chat question. Is there anyone who charges upfront for software integration or customization, so called front loaded pricing? That's a good question. Upfront for integrations, customizations. Anybody's got any experience with that? I only know it as part of a professional services engagement. Right. There's usually a statement of work where they estimate what the effort is going to be, how many hours it's going to take, and then they present a price for that. But.

So Brenda McCabe here, Matchbook Services. We have enterprise SaaS platform that allows customers to integrate with D and B APIs. They ingest the different packets for different use cases into their lines of business. So we have a flat rate based on records under management, not API calls. So Augustine, I'd like to talk to you afterwards because we're thinking about that. But we have, we build integrations and we build them into our quotes and it's basically on a service contract. So it's hourly and. But it's, but it's done. They have to have our, our platform and then the integrations are made off that.

Interesting. Thank you.

It's around 10. So our revenues were slightly under a million 12 enterprise customers. Large Fortune 1000. Our service revenues are under 10%. So we are selling the platform.

Cool.

Thank you, Brenda. Thanks for sharing that. All right, I see Kirsten has raised her hand. Kirsten, do you want to unmute yourself?

Yeah, I was just going to add to that. We also do charge up front for customization, but only if it's on our product roadmap. And we don't do it like hourly or anything like that. We just kind of when customers come up with things that they need that we don't yet have, we say, sure, we'll build that for however many thousands of dollars.

Okay, what kind of software do you have, Kirsten?

So we're Enterprise SaaS and we sell a automated coaching platform to enterprises so people can come and learn about like their work styles, thinking styles, get coaching on themselves and their coworkers. That's what it is user facing. So we do have users and we're totally user pricing. But I'm interested to hear this. But then it all boils up to generate data for the enterprise for talent management solutions.

Yeah.

Cool.

Interesting. Thanks. Thank you for sharing. All right, anybody else? Don't hesitate to share. Does anybody have some other interesting model by which you price? So we've heard about APIs, we've heard about invoices, encouraging abuse. Anybody? Some other interesting metrics? Yeah, Rikkart, do you want to unmute yourself?

Yeah, I wouldn't say maybe it's interesting, but I guess it adds a lot of complexity to share because we run contracts from $50 a month to a few hundred thousand dollars or half a million or something dollars a year and anything in between. So we run everything from fully credit card self service to enterprise sales into really, really large organizations. And what we do is we build security software. So we try to hack into company systems. And the trick with us is I guess when we test systems, it can be a very, very valuable application that we test. And then a very, very large company can be fine with paying $50 a month because they only want to test one thing or another company might want to test. I think we have the worst case now is that we monitor somewhere around 800,000 different type of applications per day and the actually the same type of company, same volume, but the value cannot really be automated into it because it's just so massively different types of scales where in one scenario also contribution margin doesn't matter. But when we started to get into these really, really high volumes, we actually need to start to look at just computational cost of the accounts. That adds complexity. And also on the customer side, it can be one user or it can be a thousand users on the other side. So we have so many different dimensions combined with both. Also enterprise versus self service sales and we haven't really figured it out yet. We have like a per consumption base on the lower end and then on the higher tier we try to figure out the value. But then the problem is then the big customer have always anchored it in the self service price that they see.

Yeah, that's the classical challenge. And I was expecting that somebody from security would chime in because that tends to be a class of software that often has that kind of problem. Right. Unless you are doing personal desktop security or something like that. Thanks for, thanks for sharing, Rikki. All right. We have time probably for like one or two more. So if anybody else has something interesting to share, I would love to hear that.

Hi Lilburn, this is Oz. So we have, we're a wellness marketplace, so it's just more complexity to the pricing. We're still doing subscriptions, but they are subscriptions on both sides of the platform, the demand side and supply side. So it's just more about balancing when there's enough value to go from a freemium to a paid. So I don't know if there's thoughts around that from any research if marketplaces are a big focus for zora.

Yeah, marketplaces are of course an interesting model. There's a lot of predictions about marketplaces growing more and more in importance, especially in the service industry and Other spaces. Right. So that's definitely interesting, but I didn't get that. Are you charging by users or is that kind of your mechanism or.

Subscription model? Sitting with a setup based off the transactions take rate, but actually subscription based?

Yeah. Okay, so it's just purely the transition from freemium to great to more services. Yeah, yeah. Most companies are kind of looking for the network effect. DocuSign is a perfect example where DocuSign license for one person makes little sense. If it's between you and your tax attorney or you and your lawyer, it starts making more sense. If it's 100 people, it becomes very valuable. And so that kind of network effect is really important. And that's what usually motivates people to then switch over to a paid model. We have like one more minute so we can hear from one more person. I love hearing these stories because, you know, a lot of companies are trying to figure this out. Right. And it's not always obvious. Sometimes you are dealing with complexity in many ways. If you are running on aws, they sort of make it harder for you because their pricing is so granular and so usage driven for every different type of API that it's sometimes difficult to attribute your cost of goods. Right. So what's actually driving your cost is not always obvious. That kind of complexity also doesn't help. All right, so I think we're out of time. I'm going to hand it back over to Tammy, but before I do so, I want to thank everybody for joining and participating in the conversation as it was an interesting discussion. So thank you very much.

Thank you so much for joining us and spending your morning with us today. And Lubo, thank you very much for sharing such an insightful and interactive conversation. It was a pleasure hosting you all.

Thank you.

Thank you all.

Thank you all.

Closing out the meeting. There we go. All right, thank you so much for your time today. It was magnificent. Great conversation. Good to see folks talking out loud and also in chat.

So, yeah, a little difficult to coax them, but the comments were actually quite interesting. Right?

Yes, yes.

Took down a couple notes and it was good.

Fantastic. Thank you so much. We'll take all the chat questions as well and then we'll have this recording. We'll clean it up a little bit and go from there. So thank you so much.

All right, great. Thank you, Tammy.

Bye.

Bye.

Bye.