Office Hours: Selling and Renewing 7-Figure Deals

I can. Can you hear me? How's it going, man? I'm doing well. How are you feeling? Nice. Ugh, that's such a bummer, man. I like I don't even think about that anymore, but just traveling and how brutal that can be when you get sick and have a baby at home. Ugh.

Yeah. Good, have you? Much better now. l last week was a rough, so

Yeah, it was like all fine. I was on a leadership off site in Seattle and it was all fine. And I think I picked something on the way back in the aircraft. and this time it was like really brutal. It just like made me really weak and I was like just like resting for five days. So but I now I'm all recovered, so that's good.

Ugh. Good man. Good. I'm glad to hear it. I like the office by the way. It looks it looks really nice and organized behind you.

It's it's all my wife's work, so I wouldn't take the credit for it. I actually had earlier joined the Google Meet and then I realized I need to join this other studio.

Nice can't take credit. Love that.

shoot, is there still a Google Meet in the got it? Okay. Okay, so it wasn't in I just want to make sure it wasn't in Luma. Ulrich okay. Ulrich should be on soon, but I'm I'm gonna start letting people in here in just a second. This so candidly, this is our first time using Riverside for this. so we will see how it goes. I'm sure there'll be a few bugs, but seems pretty easy to use so far.

It was just a placeholder on my calendar, so yeah.

Yeah, yeah. Looks very similar to like Google Meet. The quality is really good. So yeah.

Can you hear us? there we go.

We had a we had a Wi Fi thing ten minutes ago. So we'll see what happens. But manually's smart enough for both of us. So

Yeah, we've got Yeah. Yeah, so I think like what so hey Pavel, by the way, sit see you there. I'm gonna start letting people in. This is the first time we've used Riverside Ulrich, so we'll see if we run into any issues on that front. I was just explaining that to Manu and then having rescheduled it a couple times, like I I think a bunch of the people that registered signed up for the first time. So I'm hoping that we still get 'Cause we have a great list of attendees. so at the very least we'll be able to kind of reach out to people afterwards. But in the meantime I'm I'm hoping we can get some solid attendance and Pavel we'll we'll probably give it a good like five minutes after ten just to let people join and make sure they're not having any any issues with with getting in here.

How was the off site Manu? Nice.

It was good. it's just like very busy, like eight hours, seven hours of like straight sessions, like session after session with the leadership. So it was really I would say really busy but good busy. So yeah.

Yeah. I I remember those from HubSpot. It's like you go there for, you know, like a day or two and it's just completely jam packed.

Yeah, it's like eight to five, you're just in the conference room. So But good FaceTime with the leadership, so that's always nice. So

That's awesome, man. okay, so we are okay, here we go. Got one person joining. That's great.

Hey Rob. Try to figure this out. Good, man. Awesome. I'm just gonna mute you real quick 'cause I'm hearing an echo.

Doing good, man. I'm just gonna mute you real quick because I'm hearing an echo. but just wanted to let you know we are we're just gonna give it a few minutes to let people kind of trickle in. This is our first time using Riverside for this, so I'm hoping that technical difficulties aren't too bad. But I'm starting to see some people trickle in right now, so hopefully that's a good sign. Hey Steven.

We're just gonna I I keep repeating myself, but we're just gonna give people till like ten five. This is our first first crack at Riverside for one of these. So hoping that there aren't too many crazy technical difficulties. But we'll let people trickle in and and then we can get going.

that's always the the like major downside with any of these sort of podcasting tools is that there's just like this small barrier to entry to join them compared to just joining a Zoom call whatever it is right so everybody joins a Zoom call it's fine it just works people get in anything else it's just like there's this friction where half the guest list just like dies in the attempt.

Hundred percent. And it's like the smallest pieces of friction. Yeah.

Hey Jeff. Doing good, man. How you doing? Awesome. We're we're just giving people we'll we'll kick things off now. We are giving people a few minutes to get used to the Riverside switch. It's the first time we've used Riverside for this. We were just talking about how sometimes there's a decent amount of friction with that. but we can just jump right in. I think we've got a good small core group right now. I I I know a few of you guys, and I know you guys asked some awesome questions. So I would love to get your questions out there.

and we can keep going from there. And as people join, I'll I'll keep adding them in. before we before we jump in, I think most of you guys know Ulrich Manu. Did you want to just kind of give like a brief introduction to yourself, what you're up to now and and your background?

Sure, yeah. Hey everyone. I'm Manu currently at Databricks. I lead the mere industries For the strategic deal pricing for the industries. And then yeah, been in pricing for almost 15 plus years now. almost two years at Databricks. Before that, spent five years at GCP, and then like spent three years at ThermoFisher. So yeah, it's been like all pricing all along. And I would say last eight years have been concentrating mostly on very large enterprise customers, building seven figure, eight-figure deals for some of these large customers. Yeah, and super excited to be here and share some of the knowledge and looking forward to this.

Awesome. And Ulrich, just in case anybody on here is not familiar with you, do you wanna do you wanna just give a quick background on yourself?

So I'm Ulrich. I'm the founder of willingness2pay.com. We are an expert advisory firm. We deal only with complex B2B SaaS and AI pricing. So that's we'll we'll leave it in that for now.

Awesome. All right. Well, we can jump right in. I'm Rob. I know most of you guys, co-founder of Pricing SAS. And for today's session and just generally how these office hours typically go, is I I tend to moderate. And so we have a great list of questions that were asked beforehand that we'll start chipping away at. And Steve, I I figured we could we could start with yours. And the idea is I will kind of kick it over to Ulrich and then Ulrich if you want to answer and then kinda kick it over to Manu, we can handle it that way because I I think it would be really valuable to have kind of like Ulrich's perspective having dealt with these challenges across hundreds of clients and then Manu actually being in the weeds at Databricks and GCP or in the in the past, I think it would be great to get your perspective as well. cool. So Steve, I'll read your question. If you want to add any additional context, I'll unmute you and you can jump right in. so Steve's question, let me find it. It's one of the ones that I highlighted. Do you have any rules of thumb as it relates to building in a certain amount of cushion for discretionary discounts to satisfy procurement on large deals? For example, deals over a million dollars, target price is thirty percent below list price. Anything you want to add there, Steve?

No, I had forgotten my question, so I was curious what it was. But yeah, that I think that's pretty pretty much covers it. Yeah, that's a good one. Let's start there.

Yeah, it was probably a few a few weeks ago.

Still what you want to ask?

Okay, so I th I think so so discounts are so usually I would say that that discounts should be run, let's say eighty-ninety percent of what I call structural discounts, where it's like it just it falls from a table. So that sales discounts become become sort of this sort of slight variance at the end and not what sort of governs every deal. So I think with that you'll end up with with like less overall what I call commercial debt, like variance across deals. And then If we're talking sort of the largest deals, that's sort of where you then would have like a little bit of extra like wiggle room to close something. It's it tends to be that that these sort of like the necessity for discounts are driven a little bit by industry and also by geography. Right. So I think the primary example is like You have to sort of bake in a certain amount if you go to China, for example. And there will be sort of a whole like structure where you'll go through the deal will be accepted five times and then at the last minute it will drop. There won't be a signature and they'll ask for another round of discount as sort of gets escalated like through a system of buyers. So they sort of bleed you out. So you have to sort of plan for that. So there are different sort of cultural elements in that in in certain geographies. Certain industries have a little bit of that too. and some do not. So I think it's a like so so you should kinda l need to know sort of where you're where you're playing this game. But if we sort of leave that aside a little bit, I would say that I would I would leave aside something for discount, but it shouldn't necessarily only be a monetary discount.

So I would have sort of a, I would, I would have a I would have a plan of like a structured retreat in negotiation. Like what am I giving away first? What is sort of the list of concessions I will give first, second, and third? And the way I structured is that you have you have contract terms. And then you have things like bonuses, extra giveaways. we're gonna do extra service, we're gonna do give you sort of like we're gonna do all this configuration, the PS hours are like willy-nilly, all these things. And then some of them you can give once for a limited amount of time or in permanence, like forever. So obviously things that you give permanently are more expensive than things you give once or only for a limited amount of time. So you kind of sit down ahead of time with these deals and say, okay, what do we have to give that isn't money? Like what could we give extra value? What could we give in terms of like term concessions on let's say cancellation terms, SLAs, data processing agreements? Just the fact that you, for enterprise deals, might want to not use your standard contract can be a concession. So some of these you can put monetary values to. So I remember we did it, we did an eight-figure contract once for, and the customer was HSBC Singapore. So large bank trading platform, we sold that. And we had it as one of the things like if if they wanted to use their contract paper and not our standard, that would be another eight percent of the deal, which is like a meaningful amount of money, and that was like a forever thing. And then They really wanted their papers to be used. So we kind of used and we knew that ahead of time. So we sort of let them use their paper, but then by having this sort of determined up front, it allows us to push back on any other discounts because we said, hey, we already gave you your contract. That's sort of what you want, but that was sort of worth eight percent. So we're not also giving you like these other things, right? So I think just having that plan in place before you go can be sort of is is the way to do it.

But I'm just I'm a I'm a coach, not a player. So maybe I'll just hand it over to Manu and hear what you're saying. Yeah.

That was great over Steve, sorry, you can f ask a follow up if you want to. I was yeah. I was gonna kick it over to Monu too and just see if he had anything to add.

Yeah, I would I would hundred percent agree with with Ulrich on this. I think like it's important to understand, at least in my experience, like where we are in the negotiation cycle, right? So like if you know that this is your best and final round, then having a question might not be the best idea because you might be like leaving like competition on the table, right? Versus like if you know that some like for example, in my experience I've also seen some regions tend to be more price sensitive. For example, Asia Pacific tends to be more price sensitive. So you need to have something in your back pocket if you know that they're gonna come back in the last round. And throw a curveball at us. Also, I agree with Ulrich, like it's not just a simple decision to say, okay, are we maxing out our discounts on specific products? It's the complete economic structure, right? Like whether can we give them a little more shortfall? Can we give them a little more predictability? Can I throw in some credits to fund some of those initial POCs? So it's a mix of a lot of things. And finally, the way I have seen this evolve over time is like put it into like three buckets. So one would be okay, what's your target economics? This is like Like the best case scenario for you as a vendor. Then the second is your acceptable economics. Like, okay, this is something I can still live with on the long term. Because think of it like when you give these like really large discounts, you also have to think about renewables. Subsequent renewables becomes your new baseline when this customer comes up. And then finally, I would say is your walkaway economics, which is like, okay, this is my walkaway point, and I cannot go anything lower than this. So once we have clarity on where we are in the negotiation cycle and then how it like works across the target economics. Acceptable and your walkaway point, I think then it becomes very clear on how much cushion you need to build in when you're having these negotiations.

Awesome. Just one quick follow up. how prescriptive do you like to get with the sales teams? Like, are you saying here's the list of things we're willing to negotiate on? This is like the exact order you need to go through when you're talking to procurement or whoever the the buyer is, or do you try to leave it a little bit more flexible in terms of what you let the sales reps do during the negotiation?

I would say it depends upon the complexity, Steven. Like for example, like if I know that this salesperson is like really seasoned, they have worked on these large deals and they understand negotiation, then I would go like I would do the double click with them and I would also like go on customer calls, for example. Versus is if I know like this is a first deal this this AE is doing, I would try to keep it like very simple structure, not creating multiple layers of pricing. So I it I think it all depends upon two things. One is how complex and how big your enterprise customer is, and then how seasoned your your sales rep is to kind of go into that like very prescriptive very like double click kind of a thing I would say.

th the only thing I would add there is that you kinda have you need to have the the buy in from the sales team or they they can't operate or execute the model. Like so you kinda have to sell it to them first. Like truly like they need to sort of buy into okay, this is how we're doing it, this is the walk away, like whatever it is, these are these are this is the the structure of concessions we give. Because if they're not, then they're gonna like drop the ball like in the mid play.

Awesome question, Steve. Ulrich, one thing there there was a comment in chat that your audio is coming in a little bit quietly. I don't know if it might be like a microphone thing. just wanted to mention that before the next one. But awesome, awesome question, Steve. And up next, I'll jump into Jeff from Miro. And then we've got Radika and Nathan. I'll I'll follow up with you guys and and Chris will get yours in there after that. Just wanted to give you guys kind of a batting order. so Jeff's question, in these large deals, it feels like I'm always being asked to position everything in a single platform light item so that it can't be pulled apart or individually scrutinized. How do you balance this request with the details needed for ramps, usage, overages, and showing how price will scale with value? And Jeff, feel free to unmute and and provide any additional color on that.

Nope, like Steve, like I was also interested to see what question I asked. And I think, that's the one.

So I think it depends a little bit also what category you're selling. So so I think the there is if we're talking about like large larger deals where you are going to have to let's say argue the value across sort of multiple stakeholders, procurement, all these kinds of things. And if like there can be many strategies, but the an effective one is what I call wallet structuring, which essentially means that you pull out line items that target specific budgets. So let's say you have infrastructure line items that you know are gonna be picked up by the CTO on their end. Then you might have specific sort of more value-based line items that is gonna be picked up by the line of business that you're selling to. You might have things that are, you know, headed for their like legal team because it's more with you know regulation and compliance. et cetera. Right. So I think just structuring your pricing and packaging to sort of fit into this structure can like we we've had projects where like where but that started as sort of like in in in sort of both six and seven figure ranges where we have had very significant price increases based off of like essentially unbundling the in the sort of wallet structuring architecture, like adding these extra line items. So the important thing here is that some of these are gonna be more, let's say Cost measures that you flow through. So say, hey, we have storage for this solution and you have to pay for storage. We have API calls, you have to pay for your API calls. And that actually means that if you have if you have a total bundle priced, let's say a million bucks, and then all these infrastructure items are let's say 200k, then if each of them makes sense individually, the customer can recognize them and say, okay, so they're actually priced like more or less reasonably at cost, which means that they're not going to try to get them discounted, because then they know that you would be making a loss on.

essentially providing infrastructure for it. And suddenly they're only trying to sort of get you to discount on like a smaller portion of the deal. So a larger proportion of the revenue sort of flows through unencumbered. So that's sort of that's the that's the underlying idea. It also means that The remainder, which is in this case maybe 800K or 500K, whatever, that is usually what gets placed on your direct line of business, the line of business you're selling to, like their unit economics. So for example, we had an like a claims management system for insurance, and they essentially were selling automated claims management for let's just say $10 per claim. And so we knew that the unit economics of claims management can't really do $20 per claim, like for for whatever like is happening. Inside a claim system, that's just too much. But it can handle $10 and then the IT infrastructure part can handle another two million. That's fine because it's another budget. So you actually get to sort of like you get to engineer what kind of unit economics sits inside each of the different sort of budget holders by creating these sort of unbundled items overall. So I think I think it's that level of detail that you should consider it at and not just like well how many and how bundle and unbundled should be. So it's like so I think the my advice is whatever like have a specific purpose and and recipient for things that you unbundle. You know who you're unbundling it for on your customer side.

I feel like I'm almost asking like the flip side of it. And like, think like we're frequently being asked to position like, easiest example is like, we've got, you know, Miro sells collaboration, for enterprises we recommend a, you know, security guard add-on costs 30%. And we think you're going to use X amount of AI. We're going to give you, you Y amount of credits like, let's give them a whole package for a million dollars and present it as like, know, Miro, Miro great deal package or whatever. And like, and by doing presenting it as one thing rather than three things, we don't allow procurement to go in and say like, do you need $200,000 worth of credits? We think it's only 150 K. Like, and so like they're like, should, you know, security costs 25%. Like we think it should cost 10%. And so like it, it, it take the attempt that we're, that I'm frequently getting is like bundle as much into a single line item so that there's not the ability to, to scrutinize each line of like, well, we don't think you need that many credits or we don't think security is worth that much.

by presenting it as a full package and a full offering. But like, I think the trouble with that is that it's then harder to say things like, you know, what you would expect credits to increase as you adopt more. And so like, it gets really hard from a like multi-year growth perspective because you've bundled everything into a single line item as like a platform offering. Like that's what's happened with us all the time.

I think it I you can't argue with success. So

Maybe you can say, just don't do that. it's tougher.

I think especially if you have a lot of like consumption based elements inside of your system, I think you need to you need to sort of be very clear around how those are priced and how they affect also like future like renewal rates and all these kinds of things. So so I I would I would especially if you have a lot of AI and you're still sort of unsure how cost structures and these things run into them, you you you you can be forced to come even midterm in a contract to a customer say, Hey, you need to pay us more because you're very successfully using the product. So so I think I don't want to sort of like just diagnose without sort of but but but but if I had to I would say that that you'd probably I think there is a better and more effective sales motion on the other end of practicing some of the unbundling that you're currently like avoiding. I think if you go into that and get good at it and get good at like pushing back on procurement on these different things and like structuring deals in ways that actually is defensible, I think you'll you'll get at a more you'll get at a more like like scalable, repeatable motion at these sort of higher deal sizes and you will also be able to sort of run renewals and all the different things in it in in a better way. this sort of, hey, everything included is just a million bucks or two million bucks, especially as you have to sort of change over the years, can be really hard to run. And you're extremely, let's say, vulnerable to like individual skill on your sales like on your sales team as well.

Yeah, it's definitely harder. And again, like I'm like tend to think in the same way that you do of like the value per component and stuff like that. Like our push from enterprises that we're selling to very frequently is like, I don't want to be monkeying around with you guys on each of these things. And so that's the push we've

I I think one thing I'll add there is like when it c especially when it comes to like the overages, I think it's important like between the seller and like the buyer, are we using the same set of assumptions? Like do we have a good line of sight of what this three to five year workload mix looks like? What does the spend mix looks like? I think the more we are aligned on these assumptions, when we are negotiating, the I I think you're solving for most of it in the for the future as well, because then the overages could still happen, but they could still stay within bounds because we have done like a very good due diligence of what the workload mix looks like. So that's another thing that I've seen successfully, at least in my experience, is just having a good line of sight of what kind of workloads, at least in tech space that the customers are bringing to your platform, and that could help build some of those overages protection or predictability around the costing.

Awesome, awesome question, Jeff. Ann Marie, if you want to tr throw your question in the chat, I'm gonna go through like we're gonna go through kind of a sequence of questions that were asked prior to the meeting. and we can definitely jump in and and answer that one in a little bit if if that works for you. okay, Radika, I wanna ask your question. I work so I'll I'll pull it up and and feel free to unmute yourself and add any additional context. So I work at LinkedIn and as we contemplate usage based pricing, we realize that there will always be a need for custom and bespoke deals for our largest customers. I'm trying to understand whether this means two separate systems entirely, one built for scale and another built for allowing whatever flexibility is needed for our largest customers. Has anyone had success using the scaled system even for the most complex largest customers? And feel free to add any additional context right eco before Ulrich and menu jump in. Yeah.

Yeah, I'd actually like to refine my question a little bit because things are moving so quickly out here. admittedly we're a little bit slow in the usage based pricing space. We're kind of behind, so there's a lot of catching up we need to do. But here's kind of the the crux of the problem that I'm faced with. We have we ha we're setting something up for kind of, you know, like a usage based pricing system. It might have some kind of a platform fee and then you pay for credits. The customer pays for credits and stuff like that, and they keep buying credit packs and topping up. We think that that could work for maybe like 95% of our customers. But our largest giants, the hypothesis going in is that they want a lot more predictability just because their spend is that much higher. And what we might end up doing is signing fixed-fee contracts with them for even are AI products, which are very much usage based and have a cost to us. And there's a world in which they could significantly exceed usage and go above like whatever we're charging them 'cause we're still in the figuring it out stage. Is this normal? Like do other companies do this? Or how do you get around this problem where you have like sh these enormous customers who are just like, I do not want this unpredictability. My CFO is not going to sign off on it. So you give me one fee and I will pay it, even if it's huge. But then at the back of your mind you're like, my god, I don't know what's gonna happen. Like they might just end up using so much and we'll be in a hole.

So normal and advisable are two different things. Right? And so so I think and I think the the way I would look at this is that you have to look at as a time series problem. Like you're you're in one stage right now and you're moving to through multiple stages of discovery and exploration and also custom relationships. So

I mean, your those large enterprise customers, they are also not just like they're not calling their utility company and say, I just want one fixed price for electricity. And I refuse to pay for usage. Like because then they can't buy electricity. So they're they're kinda like they already they're already purchasing other models that are fully consumption-based and they're fine with it. The only problem is that they don't have the visibility of what they're buying from you. So they don't want the risk.

So I would I would encourage you to look at it in four stages. So stage one is that you put up guardrails. So you have really good cost controls and telemetry, and you can and you can have a fair usage mechanism where you get to sort of throttle or slow things down if things go out of hand. Especially if you have extremely large potential consumers on the other end, you kind of have to have a kill switch.

In some way. And this can also, and then so that is the telemetry part. Contract frameworks are another where you need to sort of like the contracts need to be so that the that you explain to the customer that if something happens, you're gonna have to take action. And then that's the last part of the guardrails, is sort of the custom communication part. So the telemetry, the the contracts, and the communication, that's sort of your guardrails. And then you can phase two, launch something.

And then you can launch something with whatever pricing model you have, and it you can have a fixed fee version where you try to promote adoption, and that's fine. You can also with and you did you can distinguish between like what you do with small and larger customers. But the point is that once you launch this to then learn over time. So you will see different. Consumption curves and different values. And then I usually say, especially if you have a new AI product, you tend to go from undefined to defined value over time. Like you don't actually know how the product is valuable. But you will discover it as you go along. So you kind of have to sort of like do that pattern recognition like throughout a period with the customer. And then that also allows you time to productize some of these guardrails. So if you can build in measurement metrics and control metrics inside the product so that the customer can actually control, like measure the consumption in real time, have audit trails on it, have the visibility notifications, all these things, and control metrics so they can say who can actually consume the credits, on what product. Products, who can approve the overages, all these kinds of things. And then you can move into sort of the final phase where you do sort of the real monetization at some point. We say, okay, now you've been using it for a year, and this is how it works, and we have all these guardrails in place, and you have the control measures and so forth. Now it's sort of yours. So with these control, like measurement and control metrics, you actually empower the customer to handle the consumption risk. But without these toolings in place, they want So you have to sort of handle it in the contract with your guardrails to begin with, give them time, and then you can sort of push it onto their end at the at the end of it. And then at that time, you're also going to know what the product is actually worth. So you want to, whatever you're doing right now, you want to create an agreement that you can change at renewal in a meaningful way. So you have to sort of look at this as an exploration phase that sort of goes through these different stages, and you'll end up at

good monetization in sort of one two three years and what you're doing now is to prepare that.

Got it. Very helpful. Thank you. And then you said something about you know, you need a kill switch. And I'm guessing what you mean is like like there would be contractual terms in there that say like, you know, if you're using this product for things other than the stated use cases, or like if your usage is in excess of I don't know, some like really high value, then we need to have a conversation or we will like pull this kill switch. Is that essentially what you're referring to?

Yeah, so so any product has a kill switch, like whether you want it or not. At some point they just overload the service too much, right? So so you might as well just plan for it and then have so the the the the the the most sort of softest version is just like have a very vague fair usage policy in the contract. Some customers will push you on what that means and you should try to keep it as vague as possible.

Yeah. Yeah, totally. We're trying that out.

When when we implement fair usage mechanisms now with our customers, we actually tend to to to truly measure fair usage on dollars. Just have whatever the direct cost on the contract is in real time, if we can measure it and say as soon as a customer hits whatever their contract value, we start to throttle them, or they hit 50% of contract value, whatever, whatever the the increments are, we start to sort of slow them down, and then the kill switch comes at whatever whenever they're losing us X amount of money. But you can't tell them that.

Okay. No, you can't, of course.

Like if you put it in the contract, then they will immediately start to sort of pull it apart and then then then sort of like re-engineer the math around the unit cost and all these things. So so you cost cost like direct dollar cost as a control metric is fantastic, but not as something you communicate to the customer. It has to be in the background.

Yeah, of course. Totally get it. And then the other part of my question, like just as a means of competitive benchmarking, do other companies do this kind of thing? While they're trying to figure out I think they probably do, given you broke it out very nicely into like the three different stages. So you've probably seen this where you you kind of have to give the customer one price to start.

Everybody is doing it from claw cloud and open AI now. Like nobody's getting an all you can eat enterprise deal from Claude, as far as I know, right? So it's like yeah, so they are they are it's just they want that more than they want whatever you're selling them. Like I mean it was just being very like honest with. So so yeah.

Of course, of course they are. There's no question about that. So what you're telling me is that Claude and Open Air are completely usage based. There's no like sitting down with them and saying like give me a fixed contract for like I'll pay two million dollars up front and that's it, let me use unlimited. They will not.

You can get two million dollars of clawed or open AI, but they will definitely run on a meter in the background and they'll tell you when you need to buy more, right?

Yeah. Yeah, yeah, totally. So nobody is doing an unlimited all you can eat. No one's doing that right now.

I'll send it after Adica. There's a great article in the information about how Claude handles enterprise agreements and essentially like over a certain limit, they tend to give like fifteen percent discounts, I think, for the contract. But then as soon as you hit the usage that's guaranteed in your contract, you have to renegotiate. they're they're pretty strict with that. So I'll I'll send it over as in the information the other day. Yep.

Okay. Yeah, if you can, I'd love it. And then companies that are not clo cloud in OpenAI, what do they do in these situations? Are they willing to do like all you can eat contracts in certain situations?

Some, but again I said there's there's a difference between what companies do and what is advisable. Like so it's if if you do an an all-you-can-eat contract and you don't have a fair usage mechanism that allows you to actually have it not all you can eat, you're writing you're literally writing your customer blank check.

Yeah. Do you have examples of companies who have done this in the past, the all you can eat stuff?

I I haven't seen, like at least in the AI space, Radhaka, I haven't seen. And think of this way, like especially like when it comes to like your token costs or your GPU cost, it can really explode, right? And and one way to think about this, like what I at least not exactly all you can eat, but one way to do this is having a component of base fee and variable fee.

And base fee goes back to the same example that Ulrich mentioned that okay, you have these assumptions, you have these guardrails that you have built with the customer, and you know that this is what it could cost you. And your variable fee is the overages, like the which we we cannot like give at the same price. So you start like either paying for it, you get a true up bill from the vendor. So that's another way of thinking about it. Like you break it between your base fee and your variable fee, and you do like a quarterly look back or a bi-annual look back to see if your usage is actually trending based on your assumptions. Or it is like just like completely off from the assumptions.

Okay. And even companies in pilot phases of like new products that they're launching don't do this? Like how do you know? Jeff is shaking his head.

I would, I I know I'm not like, maybe supposed to answer, but like we did a bunch of this at Zendesk or like we moved to resolution pricing. Nobody knows what a resolution is. Like, like nobody knows if it's fully automated, those sorts of things, tons of variability. Like I would frame it like to, to Manu and Ulrich's point of like, there's like a committed usage. So it's like usage, not fixed fee. It's committed usage. There's an overage component. You can turn overage off.

where you can turn like overage billing off maybe to give the predictability like no big company is gonna sign up for overages. My experience is super rare. And so like you can turn that off, but then you'd need that fair use policy. It's like 50 % more, 100 % more, 300 % more, like whatever it is. and like we, had a bunch of that type of stuff, especially early on, where we would like effectively like wave overages, as long as you're within a fair use limit and like, you know, you pay a premium, you commit to more because of that. But, like I would, I would frame it as like, there's very little, all you can eat. It's always like, we will give you more than you think you need, but if you hit it.

We gotta have a conversation. Yeah.

Yeah, I I was just gonna add really quickly on our experience. similar to what Jeff mentioned, we've got two ramping profiles that we've instituted based on the buying I would say comfortability of our enterprise customers in the sense that if they're willing to commit to a lot, we will look at that usage less. And if they're will if they wanna stay low and if they're if they're willing to open the book every three to six months, then you can commit to less up front. And we will just agree that we're gonna look at this usage more often and then we will adjust your capacity up. But we've found two spectrums when you talk to our enterprise customers. They're essentially like, don't talk to me unless you're talking to me every three years, in which case you're like, cool, guess who's buying a lot and we'll look at this every year. or the other part is I'm happy to talk to finance every three to four months. And it's like, okay, cool, then you can commit to a less amount up front, you can really ingrain that production usage profile in so you're really comfortable with how you're using and spending. But we're gonna have a conversation every three to four months to see how your profile's going.

Okay, but the first category of customer that you described is also not all you can eat. They're you're just giving them a lot or like they're just spending a lot up pre committed.

So I think all of this is just selling commit volumes in different license format or committed usage, like nobody is doing all you can eat. So so so I think the the there is

Whenever I'm talking AI consumption, I basically look like I slice it into like three brackets. You have the kind of AI consumption that you just don't allow in your product because it's either the models are too expensive or the or the kind of tasks are too heavy, or whatever. So you just like this is not how we do AI, and we're just not not allowing it. Then you have the whole block that is monetized. You have commit volumes, uses volumes, credits, whatever. Like you're charging money for it, and you can have different sort of ways of have predictability or controls with the customer, et cetera. But but the fundamental is like if you if you if you use more, you pay more. And then at the very low end, you can have like unlimited functions. But they're used, but but the it isn't the pricing model. So it would be, for example, we have a like a creative asset client doing whatever. several hundred million and they have like small like AI powered edit functions that they just like have built in as the like for free in the product.

So, what you do with those is that those you govern with fair usage mechanisms. Like you don't you don't build them, they they're just like they're not part of the deal, they just like sit somewhere in the license. Like like some some some some solutions have like unlimited users, something like that. Like, okay, users technically have a cost. So if people like onboard a billion of them suddenly, they start to create user profiles, you'll stop them because there is a security issue or there's something else, right? But it isn't part of the monetization model itself. So I think those three layers. and they they will move over time. As AI gets better and cheaper, you might move more things into the unlimited bracket, but again it isn't the pricing model. And then the pricing model will govern other things, right? So that's how I think about it.

Got it. Super helpful. Thank you.

Awesome question, Radika. Nathan, I'm glad you chimed in. and Jeff, like I love it when people chime in with relevant experience. So yeah, no need to apologize there. Like if you've been in the same seat that somebody who asked a question is in and like have have stuff to share, like by all means, love it. Nathan, I'll read your question if you want to jump in and give any more context, feel free.

So Nathan's question, how to balance flexibility within a ramped contract while managing your risk exposure with AI products? And also also if you just want to give a little context into Big Panda and kinda like what you guys are selling.

Yeah. Yeah, I know. That's a I was like like Jeff on my putting question that I submit. So I'm glad it was somewhat aligned with the more of the detail I want to get into. So yeah, we're in the IT op space, and we have a universal subscription based credit model. So historically our primary product is driven by more system or stack activity and that historical usage has been relatively predictable. So we can forecast a multi-year commitment and we've moved away from overages into a subscription based model that we can basically

adjust based on periods of review on how folks are going and our economics are fine there. But the problem is as we've expanded into new AI capabilities that are driven really by how people and how agents use them, that forecastability, given how new the space and technology is, is really difficult. And so we're we're trying to get better at not only the forecastability element, but the sentiment of trying to get a commitment of a multi-year product. which is AI based costly for us and the relative forecast ability is difficult given how new it is. So curious advice there or any other experience across the board with other folks.

So okay, so the first thing I would do is I would give up on the idea of forecastability. Total dead end. So so you well, because you are you're never going to be able to truly forecast what actually matters, which is like the really hockey sticky consumption somewhere.

Like so so you can forecast that on average nobody wins the lottery, but like every now and again somebody wins the lottery. And that's sort of really where it matters. So so we had, I'll give an example. We had my co-founder, I I met him when when he was a client. So he was the P<unk>L owner of the world's fifth largest trading platform. So they were selling the trading platforms to banks, hedge funds, all these kinds of things. They had been doing it for a decade, and they had like consistently been trying to sort of predict how much business their clients would do so they could like structure these enterprise deals with them. And they couldn't do it. They had McKinsey come in, couldn't McKinsey's conclusion was you should stop doing it because you haven't been able to do it and you haven't gotten better in the last like 10 years you've been trying to do it. So it's like some things are just hard to predict because they have a lot of inherent variability in them. And what really matters is the power law distribution in the base that you're trying to measure. So if you're living in this sort of a power law distributed world, predictability just becomes really, really difficult. So you should focus a little bit more on is not That you shouldn't do it, and you can try to do it, but you shouldn't count on doing it as the way that you're going to actually control this. So you can absolutely do it, you can actually have it part of a CPQ tool and a sales process and a customer relationship, but it isn't sort of the thing that you use to sort of control costs and monetization. For that, you need something else. And so the way the way I structured this is to say you have sort of you have sort of four major guardrails. One thing is managing the customers expectation that things are going to change. Model capabilities will change, model costs will change, and customer behavior will change and we're gonna have to change with it. Like that's just life.

Then you're going to have fair usage mechanisms. So you're gonna say, okay, so when things change, we can we can have kill switch, we can have throttles, these kinds of things. They're also for the unlimited items inside the product. We don't need to talk monetization about that. That's just how we run security and like shared infrastructure in the thing we do. So you should just know we have it, and then don't be surprised if it if it occurs. Then the two last things is the customer contracts. So you should have more flexible contracting that allows you to actually change when something changes. So that means in like introducing new line items in your credit system, changing the credit pricing, like like doing these kinds of adjustments along the way without having to sort of trigger renegotiations is the really key part of you being able to be flexible as things change. And then the so What's the last thing? I missed my framework.

Is the is the last thing related to the actual contract change itself? Like the mechanism to change it mid-contract itself? I'm curious your thoughts on that.

yeah, and then no yeah, and by and by the way, and then the last thing is that that's what I mentioned before, these are the control mechanisms that you give the customer. So you need to sort of productize the measurement control optimization logic in the product. So essentially you're saying, I don't know how consumption is gonna work. Like I I retain the right to change some of the prices and introduce new product and line items inside the product. And it's a short contract, so I will allow you to churn if you don't want to be a customer anymore. So I think in at the rate of change we're dealing with, this idea of locking customers in for three, four, five, six years is probably not helpful. But You then say, but you would have to as the customer, you will have to own the consumption risk overall inside of your usage of the product because I can't. I don't know what the right consumption pattern is for you, but I can give you sort of the framework and the rule and the pricing. But in order for you to actually own this consumption risk, I have now built into the system the measurement metrics that you that you the measurement system and the control system and the optimization system. So this is also So the measurement system is real-time data with like with the actual sort of cost component so they can follow it and the notification system, the audit trails, all these things. The control measurement is they buy a four million dollar contract and they get to like subdivide the credits into different divisions and who can consume them, on what products do they allow them to be drawn down, who can approve overages, what's the approval flow. So it's essentially advanced roles and permissions just for the consumption part of your product. And it needs to be built. And then the last thing is the optimization part where they get to say, hey, how could I get more value out of using your product? They get to sort of model different consumption patterns, applying different models, using this infrastructure, that. And then sometimes it's just like cost optimization, but sometimes it's also the parts where

I guess we've all seen these kinds of little like ROI calculators that that salespeople have in their sales decks or in their like CPQ tools. So it's like, hey, if you whatever, you'll make whatever 10 bucks for every employee that runs in the system. So if you have 100,000 employees, you're gonna make a million bucks. Like these kinds of like little like little pieces of math. If you can build those like straight into the system so that they can actually drive consumption behavior in the system. So I'll give an example. We had a We have a Swedish AI provider, they do about on average maybe 400K contracts, and they run sort of large like classes of web assets, like think e-commerce shops and big networks. That's what they do. So they build into their system some sort of say, hey, if you have our AI like run optimization on like search words for all of your assets, we can on average like increase the total traffic by 5%, and that gives you this much money. But the cost is gonna be like 30,000 euros a month. So now the customer can say, okay, so I know that it's gonna be like 360,000 a year to run all this like continuous AI improvement on the assets. But if I get 5% more traffic on everything, that's totally worth it. So now that RI calculation is sort of built into the product where they can run the consumption. So if you have the measurement where they get the real time data in, they have the control where they get to sort of make up their mind and like put in guardrails, and they have this sort of optimization logic where they get to get like drive decisions in it, then you can sort of just hand them the rails and then the consumption risk is on them. That's sort of the fundamental idea.

Yeah, that makes sense. That makes sense. I think fundamentally that makes sense once you're in contract. Once the contract's been signed. There's the there's pr that's a protraction of deals up front with the sellers that are basically trying to size against multinational banks or healthcare systems or whatnot to say how much do you need for this new product across your base? And that's fundamentally I think the one of the stickiest parts right now. Once you're in contract and you've signed it, th those those make a lot of sense. I think one of the d tricky part now is when trying to get sellers up to speed and comfortable on forecasting, I know that's a difficult word, but basically sizing, maybe another word to use it, to size that environment against this new technology and usage profile which are inherently new. And I think that's that's a tricky proposition right now.

And and I think like right now, like everyone else with AI, do the best you can. Like like I I think and just start from there and then just be ready to change. Sorry, Manu?

And I think one one thing

Yeah, no, I think all all things agreed with Ulrich. And I think one thing just to add here, like when we are talking about balancing this risk, at least the way I look at it is like you need to separate out what's your commit certainty and what's your usage flexibility. As a vendor, you want comment certainty. As a buyer, you want usage flexibility. I'll give you an example. Let's say most of the hyperscalers today sell AI infrastructure in the form of cards, right? Which is the committed use where the customer goes and commits for like a one-year or a three-year period. Now, no Buyer wants to get logged into an older chip. Like let's say if Nvidia came out with like an A100, but today we are coming out with B300s. The buyers want to be on this latest chip. So your idea should be that you give flexibility to go across the latest hardware. But in return, what you're getting is the commit certainty that yes, this customer is going to commit for a three year or a five year period. So I think as long as we can have that very clear demarcation between the certainty that we get as a seller versus the user's flexibility. flexibility that the customer gets, I think that's a win-win for both parties to kind of balance out that risk, especially in the AI space.

That's great. Yeah, thank you. We've actually implemented a universal credit model, so credits split across products in that sense to reduce that risk and the flexibility there, which has been really helpful. But no. Thank you both. That was really helpful.

Awesome question. Chris, are you still with us? Yep, I see you on there. you had a a a different question. I think I'm echoing. I'm just gonna mute you real quick. There you go. Thanks, man. so Chris's question, real quick. what size team and titles do you require to support enterprise deals? so more of kind of like an org question. go for it, Chris. I'll let you jump in with more context.

You had a a a different question. I think I'm echoing. I'm just gonna

With more context. Yeah, so I've done enterprise deals before in the past with bigger companies. we're we're starting to get into the enterprise deal mode now. So we're just building out the structure of it and trying to figure out how big of a team we need to put together, who we need to bring into these type of enterprise-sized deals. You know, I'm assuming finance, product, obviously sales. maybe an analyst or two. So just trying, yeah, like you said, just trying to see what I need to bring in, kind of resources I would need, timing wise, what it takes to go through an enterprise deal. Really I said, starting from scratch.

Manuel, you wanna start this one?

Yeah, I would say like a simple way to understand this is like having an eighty twenty rule where

Yeah, I would say like a a simple way to understand this.

What I've seen is like 20% of your customers drive, 80 to 90% of your revenue, right? So the idea should be when we are looking at your org shot and we are trying to build like let's say a pricing team or a deal desk team, those 80% of the deal volume should stay within like all your scalable solutions within CPQ, within like there is no like bespoke treatment to those deals. Versus like those those large customers where your revenue is really concentrated, like your 10 to 20% by deal volume. But that's actually driving 80 to 90% of the dollar value. I think that's where you need to have like hands-on treatment, white cluff treatment for those kinds of deals. So as long as we can automate most of your deal volume, like the long tail, versus like having the real human focus on these very large deals. And I think that's where even building the AI systems within pricing teams becomes very essential because those AI systems can handle most of the deals. But those large deals still go to the human VR. like building like very complex, very custom structures. So I think that's how I look at it. Like as long as we can break down 9010 or 8020, I think that's a win in my eyes. And then we don't have to overscale the pricing team or or the supporting teams.

Yeah, so so I I completely agree. So we have a we have a concept which we call framework compliance. So when we launch new pricing for customers, we we agree up front like what is the framework compliance going to be? Are we gonna have eighty percent of all new sales like like land specifically within this framework with no adjustments, or is it gonna be like ninety percent of whatever it is? And and again Across all the projects we do, we see sort of, as Mano says, there's like an 80-20, which where so it's not it's very normal for let's say a customer with let's say a hundred million of ARR and ten thousand customers to have, you know, fifty customers run like half of the revenue, something like that, right? so so and that actually sort of also from a pricing and packaging perspective. Sometimes you need to do pricing and packaging. That is never gonna be used by more than a few handful of customers. Like it's like having different add-ons and different sort of like like like sort of infrastructure concepts and stuff and so forth that it's only ever gonna be used by 10 clients. But you need to sort of have it productized and conceptualized and sort of ready to go for those very specific contracts. I would say, though, that I would try and get as far as I can without. Spinning up these sort of deal desk teams and analysts and people whose job it is to handle and make exceptions. Because the larger that team is going to be, the lower your framework compliance is gonna get. So if you if you run out and hire five people to handle like bespoke contracting, they're gonna find contracts to make bespoke. So just by by increasing the team size, you're gonna have more and more contracts that are gonna be not closed within the framework. So so I I would almost say whatever you do, add it slowly. Right? So, so at and and then any kind of like this 80-20 customer pyramid where like a few of them are super big, but they're not a lot of them. You kind of start by just overlaying it on the org chart. So the very largest strategic deals, almost by definition, are always sold by the CEO, the founder, or whatever.

And then at some point it's like it's a CRO and then you can start to sort of to sort of like have one or two people maybe sort of like quarterback a few deals and sort of run project management across them. if if you need to sort of have sort of a cycle into finance or whatever it is. But I would I would definitely start small and sort of reassess on a quarterly or biannual basis before I started to sort of grow a big team. so the so a deal desk of one or two people to begin with and then go from there. I think that's sort of the yeah the the 30 second advice.

And and just one more thing to add there, like the more custom we go, the more stakeholders you involve. Like there could be accounting issues, there could be finance, there could be legal, there would be more red lines. So I think like we need to like balance that out because if every deal becomes an exception, then it's not scalable.

Great question. Great answers. I hope that was helpful, Chris. Awesome. cool. I think we have I think we have room for one more. And Simon, I think you had a question. how to multithread and manage the business tech exec stack stakeholders. So that's more of kind of like a a sales person question, but I would imagine Ulrich, you have thoughts on that. Simon, you want to add any additional color context to that one?

So if it was like connected to this sort of wallet strategy that I think Ulrich raised earlier.

I already answered it? Okay, I'll take that.

Perfect. awesome. And Anne Marie, I know you had a question. You had your hand up in the last couple of minutes. Do you want to do you want to jump in?

s sorry, I thought I'd lowered my hands. I I thought I learned a lot today. Ulrich is my fan. I have his book here. Ulrich, it's on the bookshelf. Just so you know, I have it physical and audio. It's the best book ever. I know I can't wait for it to come out. Yes, you know I'm your number one hero. I thought you guys all raised great

Issues and I've written a lot about usage pricing, including like we have to you have to almost be an accountant, you have to work side by side with an accountant and you have to model all the different scenarios because it's a function of math as well, like the 80-20 rule. 20% of your people could use 80% of your product when you start looking at usage patterns. So, one of the things I thought, Jeff, based on your question, when the Clients decouple your offering is really like stay elevated, talking about the problems and you know the solutions. So, for example, with when I was working at Gartner, we had a large client and they thought they spent too much with us, and we kind of convinced them they spent too little because we spliced up the pizza and we made a sort of a portfolio approach, and we literally talked the story of the value we were giving them, and by the time they were done, they realized the impact we were. making and then you want to reduce the predict the unpredictability. So one of the things I was thinking now that I'm doing my AI finance advanced course is that if we could offer them and we have a meeting with them and we make sure we partner together to make sure that everybody's staying in the box and then that we give them there's no surprises for them we work we work with them collaboratively and look objectively and give them as much transparency as possible because clients if They're going to trust us, they want to know that we're being that they have as much predictability as possible. That's it.

I I think I wanna I also know we're at time so I'm gonna I'm taking gonna take take that and sort of almost use it as sort of a like like a closing. So I I think whatever we are gonna we're gonna do with like large deals over the next sort of one, two, three, four years. I think it is I was also I was at a I was at a sort of a CXO like dinner yesterday. And I think the takeaway from that was that Like customer narrative and just getting closer to the customer and having sort of a buy into the journey that you're on together is going to be extremely critical for whatever pricing changes you're gonna have to do over the next like couple years. So the worst thing is surprises. And but since nobody knows what is going to happen, just agreeing with the customer that you know you're on a shared mission, you're gonna try to achieve this for or with them, with product, with whatever happens, is gonna give you like a lot of leeway whenever you have to then make a change. So so I think investing in that customer narrative and expectation management early goes a long way when you then have to come with with a new contract or a new new pricing change in any way.

Also to show them reports, you know, they there's a dashboard that you commonly look at together. We're in a partnership, there's no shocks.

Love it, everybody. I know we're at time. Thank you guys so much for joining. thank you for all the great questions. And Ulrich and Manu, thank you so much for sharing your expertise and insight. hope you guys have a great rest of the day. I'll follow up with key takeaways and resources, recordings, all that stuff. hope everyone has a great week. Hey, Farhan. Good to see you, bro.