Philipp Stelzer: Hello, and welcome to another edition of the RevOps Lab podcast. Our guest today is Gabe Rothman, and I'm also very happy to say hello to Janis who also joins us for this episode. Hello to both of you.

Gabe Rothman: Hey, guys. Great to see you again. I had a good time meeting you guys at the RevOps AF event last week. So, yeah, it was a good time. Good to catch up so quick. Good to be back on the podcast.

Janis Zech: And, Gabe, great to see you again.

Gabe Rothman: It was awesome. Yeah. Yeah. I mean, you just said it. Right? Like, we met at the RevOps AF twenty twenty four conference in San Diego. Yeah. Really good. Just a few days. Actually, last week. So I'm, like, not jet lagged anymore, nearly. Like, still, like, a little bit. Five percent jet lag is still there, I think.

Janis Zech: Yeah. And, yeah, I think we were really blown away. We got to know you. We didn't know you before. I had, like, a really good night with you at a bar, but then also sober, more sober later, at lunch. And you showed us really the structure and diligence of how you run comp planning. You also did a session at RevOps AF that was well received from what we heard from other attendees. So we figured, hey, you know what? Let's invite you to the podcast because comp planning is always a great topic, and it's not talked about enough, I think, particularly from a relative perspective. So we wanna dive a bit deeper into that. But before we begin with comp planning, who are you, and how did you end up where you are right now?

Gabe Rothman: I didn't know we were gonna start with such, like, broad philosophical questions. It's a hard one. Now I am vice president of operations at a company called Rescale. Rescale is a software orchestration platform for running computer simulation on cloud based high performance computing. So I know that's kind of a mouthful, but the analogy I generally try to use is, pardon me, if you're say a big automotive company of which we have several, and you want to run crash test simulation on AWS, you can use our platform to do all the orchestration between the simulation software and the cloud infrastructure. Analogy I like to use just to put kind of a finer point on it is if you think about your laptop, right? Your laptop has a processor, it's got an operating system and it's got applications. Obviously it has more than that, but like those are the three of the big ones. And the operating system does all the stuff in between the software application and the processor, right? It starts programs up, it shuts them down, it allocates memory and processing power and does all the stuff. You can sort of think of us as the operating system for running high performance computing based simulation in the cloud. And what else? Who else am I? I guess a little bit of additional background. I've been in the operations slash RevOps space for, I think, twelve years now. And I started at a consulting company called Blue Wolf, which is now an IBM property doing mostly like Salesforce implementation consulting. And I landed there as my first job kind of in the tech space after a four year stint as a insurance and construction litigation attorney, which a long time ago, but suffice it to say it wasn't for me.

Janis Zech: So just a short note on that. I think you're the first litigator — litigator turned RevOps person on the podcast.

Gabe Rothman: Yeah. Hey. You know, it's a — I will say that while I, unless I absolutely had no other choice, would never ever go back to being a practicing attorney, I don't regret the education. Law school is really interesting. And, actually, law school and even practicing as an attorney teach you a very sort of transferable skill set when it comes to the operations world. You know, operations is all about problem solving, about breaking down issues into their component parts and figuring out how to build them back up in the most efficient way. A lot of what you learn in law school, at least in American law schools, is the thinking part of how to be a lawyer. They really teach you how to think like a lawyer. You obviously learn a lot of information about the law, but the fundamentals are, you know, how do you think like a lawyer? How do you think strategically and logically? And how do you break down problems in order to solve them or craft an argument or whatever it might be. So it's also helped me in my personal life. My wife and I have avoided getting screwed, so to speak, a few times because of my legal background. So it's been good that way.

Janis Zech: Yeah. Nice. Yeah. I think, yeah, definitely rare to hear that. And I think also much more common in the US, that you have these, like, transfers. So, like, you study, you know, law, but then you transfer at some point into business. I think much rarer, particularly —

Gabe Rothman: We also have more lawyers.

Janis Zech: Yeah. Lots of lawyers. Not sure if that's a good thing.

Gabe Rothman: No. It's not. Yeah. We have a lot a lot a lot of lawyers.

Janis Zech: So yeah. I think what's super interesting also about, just going back to Rescale, right, it's a very technical product from what you described. I mean, I know, right, it's consumption based in terms of the pricing and the billing model, and it's also probably quite high touch. Right? So, this is a product that needs to be explained. This is not a PLG motion, or low touch, high velocity, like small deals, but probably something bigger. Right?

Gabe Rothman: We'd like — well, I actually shouldn't say we'd like it to be. We would like there to be a PLG applicable version of it at some point, but it'll never be not for the enterprise. It'll never be a PLG motion for large enterprise companies unless some, like, fundamental things change the way that industry, that ecosystem works. But yeah, I would say that it is very high touch. And so what we're doing sort of flips the percentage of touch. Right. So if you do it yourself, it's ninety percent high touch and ten percent sort of plug and play. We're sort of reversing that. Right? Like we're helping you do about ninety percent of it through our platform and then the other ten percent is implementation time and loading different software applications that you may wanna use that aren't necessarily like natively supported. Like if you have specific or a custom software application, some companies build their own simulation software, that kind of stuff. So, yeah.

Janis Zech: Yeah. Got it. I mean, this is why you buy software. Right? Like, you try to increase efficiency, enable processes, enable workflows without adding overhead, hopefully. I mean, that's the ideal outcome, at least, I would say. Not always the case, but, yeah, you should try.

Gabe Rothman: Yeah. So the talk that you gave at the conference, it was comp planning and complex scenarios, I think was the title. The complex scenario referring to the complexity that you experience at Rescale or — I think so. Right? So because, like, you have the consumption, you have the high touch, so it's a complicated process. Different people are involved. So that makes comp planning, of course, a lot more complex.

Janis Zech: Yeah. I mean, certainly my goal in that presentation was to use the complexity of our business as a framework to help the attendees kind of think about how they might do that for their business, right? Like obviously everyone's business is different. If you attended that session and thought you were just going to like plug and play, like run a comp planning playbook based on what we did, that probably won't work well. But if you attended and looked at it sort of through a broader lens and said, well, what can I take from this? Or what can I learn from this? And how to think about solving that problem, right? How to think about the challenges that we might face in our company that we really need to be cognizant of, then it was probably useful.

Gabe Rothman: But yeah, the complexity in our business comes from several sources. One of them you pointed out, we're fundamentally a consumption billing model, which has a whole set of challenges that come with it. But also there's a component of our business that creates — not an issue per se, but we have to basically think about gross margins fairly intensely because we pass through cloud infrastructure as part of our product. It's bundled into our product. So we have to pay for that, obviously. And as a result, we need to be very sensitive to the impact that that can have on our margins. And in particular, it creates a situation where we sort of don't actually know what our margin on any given deal is gonna be until the end of the deal, like until the end of the contract, because different core types have different price points. So the price points that our customers are running their jobs on vary depending on what they're using. And our platform fee does not vary, at least once it's contractually determined, right? So the amount that they're paying us to use the platform, which is also billed on a core hour basis. So if you have someone who runs all of their compute on something that costs zero two dollars per core hour and our platform costs, say, six cents per core hour, then it's, at least in the context of those two things, it's seventy five percent gross margin on the platform piece. But if the price of that core type drops to fifty percent, right? So we don't know what that's going to be. So we have to run a lot of what we call like prescriptive margin analysis during the deal making process. So those are just two factors that really contribute to that. And we have to be sensitive to how we manage them. I think one of the points that I made in the presentation is that just because you have a hammer, it doesn't mean that everything needs to be nailed, right? You don't have to solve everything with comp plans and you shouldn't. You should really think about, in fact, perhaps not even trying to solve problems per se with the plan itself, but really focusing on like, how do we incentivize the behavior and the resulting growth of our business, using these plans.

Janis Zech: One note on just what you said. I think this is something that most AI first companies are actually facing right now, that you often still price it quite traditionally. Right? And then you have underneath APIs that cost you depending on what you actually, how it's actually used. And I don't mean the infrastructure, more like the application layer, which I think makes it really complicated from a compensation perspective. So you mentioned, right, you mentioned that, like, it's consumption billing. You mentioned that the gross margin isn't a hundred percent clear. You also have a long sales cycle. You close the deal, and then there's a gap to go live, and then actually you don't know what the deal value will be, you know, even at month three, or is that also reality for you?

Gabe Rothman: It is. We as we talked about, we're a pretty heavy touch implementation, and that's by design. We have a lot of customer success and support resources and even an engineering team within our engineering department. They do a lot of stuff, but one of their major mandates is supporting the software layer of our ecosystem, at least as it pertains to our products. So there's a lot of support. So usually we're pretty good at limiting like time to value in terms of getting a customer implemented. But yeah, I mean, you mentioned the sales cycle is long and then once we're live, we don't actually know when a contract is going to end either. So that's a big complicating factor in the kind of billings versus bookings analysis when you're talking about designing comp plans. Because we're a consumption based model. Well, let me back up. So we try to structure our business as like a subscription kind of recurring revenue model for a whole host of reasons, not the least of which is that's what the investor community kind of wants to see from SaaS companies. So we sell our products on one, two, three year contracts and beyond. The problem is that if you sell a one year contract, it's not really a one year contract. It's just an expiration date, right? They give us a predefined amount of money that we load into our platform. And then as they consume, right, we just bring down — we call it a deposit. We just bring down the deposit. So as a result, in all likelihood, the minute you sign that contract that says, this is a one year contract starting from — you know, today's June fifth. So you have until June fourth of next year. The minute you sign that contract, your projections about what they're going to consume, the contract end date are immediately wrong. Almost certainly immediately wrong. Because consumption doesn't happen in a linear manner, right? Customers will go for long periods of time without doing anything on the platform because they're spinning up a new project and they're setting up their models and they're doing investigation to support the new product that they're building out or a new feature that they're building up. And then they'll run a flurry of jobs over, you know, maybe as little as a couple of days to a couple of weeks. And then it might go quiet again or relatively quiet. So it's spiky. And the other thing is that generally speaking, because there's this expiration date looming and they can — how long they can use the current deposit — they will generally, if they understand during the sales process, they really bought the billing model, they'll generally underestimate their usage. Right? There's no harm for them in just having to sign a new deal early if they've budgeted for it. So a lot of times you sign a one year deal, and they burn through the deposit in nine months or six months. And then you have to sign a new deal. And then a lot of times after they've done that, they have a better sense of what their usage is gonna look like. And so they might increase, right? If they sign a hundred grand for the first contract and they burn it in six months and they want the next one to last close to a year, they might renew for two hundred thousand dollars at six months, which is in a broad sense, a fantastic problem to have. That's great. We'll always take more money. From a comp planning perspective, it's a challenge because if you wanna comp on bookings, right — because if just to make the thought experiment easy. If you sign that customer on Jan one for a one year deal and they burn through everything by July one, and that was a hundred k, and then they sign a two hundred k deal on July one to take them through July one of the next year. You've booked three hundred thousand dollars in the year. But when you go to look at it from a, especially when you look at it in a renewal versus growth context, in a new business context, it's a little bit easier because you don't have like a renewal component. You're not trying to parse out how much did they grow and whatnot. But even that being said, this problem still exists in the new context. And the challenge is that when you comp on bookings, we're going to comp on three hundred thousand dollars of new business in the context of a new customer. And say, if it was in a renewal context and their renewal target was a hundred grand, right? So that goes to renewal and then you're comping them on two hundred thousand dollars of growth. Well, from a billings context, like a run rate context, they didn't book two hundred thousand dollars of growth in the current — well, sorry. They did book two hundred thousand dollars of growth, but that's not two hundred thousand dollars of run rate by definition because that consumption is going into next year. So you have to balance these issues of, well, from a bookings perspective, we're kinda gonna overpay. Right? Because the base commission rate on expansion, say, is higher than the base commission rate on renewal. And so the challenge of comping on bookings being that there is this moving target that you have to account for. So the upside of comping on bookings, which is the model that we've chosen, is that it's very AE friendly. And our goal is to have AE friendly comp plans for a host of reasons. One of which is we have long sales cycles. Another is that our product — it's not, I wouldn't say it's difficult to sell in that, like, we don't win a lot of deals. We do actually win a lot of deals, but it is a long process. It's arduous. And we need plans that keep our AEs happy and keep them motivated to stay as resilient as possible, right? So if you comp on billings, it's great for the company. Comping on billings is super easy. Or even more revenue, right? If you just took the approach of running sales comp on just like a monthly basis based on the previous month's billings, you can kind of break it down exactly as it happens. You know exactly how much is new and exactly how much is renewal once it happens. The challenge is that the commissions are delayed. Sometimes substantially. So it's sort of like weighing those two things. And we've put a bunch of stuff in place to try to mitigate the risk around the bookings comp model.

Janis Zech: I have many questions, but let's start with maybe a few. So number one, what happens if you sell a hundred k deal for twelve months, but they only consume fifty k. Right? Do they still have to pay the fifty k? Because that would be an issue if you have a commission tied to bookings. Right?

Gabe Rothman: They do. So, again, our model says that you give us X amount of dollars, you have Y amount of time to use it. And if you don't use it in that amount of time, it goes away. We do have an extension process. And historically, we've been fairly liberal with it for a number of reasons. We're a small company. We're getting bigger, but it's very hard to tell, you know, a company the size of Ford — actually, Ford's not a customer. It'd be nice if they were. Not yet. We're working on it. But it's hard to tell a company the size of like Ford to shove it. Right? They'll be like, well, sorry. You're just out of luck. So we've been pretty flexible on it. We've been getting more stringent in allowing, or I guess not allowing people to do that. But obviously it's in our interests to make sure that customers don't over commit for that reason. And we do a pretty good job. So again, but you do point out something that is another challenging thing to balance in our sales cycle, which is obviously we want to get as much money as we can upfront, but we do ourselves a disservice if we sort of convince the customer to over commit. So our sales process is very consultative.

Janis Zech: I have a follow-up question on this. I mean, obviously, it sounds to me as a customer I would be stupid if I commit to one million if I don't know if I spend it and then have to pay it. I'm incentivized to keep the volume realistic, and that kind of balances the commission of the rep out. Right? But then how do you incentivize expansion? Because I assume that's a really important piece of the pie. Right? And is that from an ownership perspective, is that still owned with the AE that runs the deal, or do you already have a handover? How do you organize that? Because I think that directly impacts the comp of the team. Right?

Gabe Rothman: So to answer your second question, AEs own their accounts, you know, with the exception of maybe if we do, like, a territory shuffle, that type of thing. AEs own their accounts in perpetuity regardless of the contacts. We wanna maintain consistency in that relationship. And from, like, a renewals and growth standpoint, we do, as I mentioned, have a pretty engaged CSM team. In terms of the incentive structure being sort of like slightly perverse relative to our desire to get as much money as possible, that is true. But the levers that we use to try to motivate customers to give us more money upfront, you know, within reason, are pricing, discounting on the platform fee. We have something that we call a deal desk credit, which is basically just a chunk of money that we put in their account, which is actually the preferable route for us. Just because it's easier from a contracting perspective. It doesn't persist contractually. So it's a little bit easier to deal with. And then, you know, there's a host of other stuff. We can give discounts or free training, or we can have a dedicated customer success engineer that we can throw in or discount to make it more palatable. So we use all of the different pricing levers to try to keep the customer from completely under committing, right? Because again, to your point, the last thing we want is something that ends up looking more or less like a pay as you go model, right? We do have that. Like customers can give us a credit card and just month to month pay what they want. But we like to think that we create enough incentives for customers to commit upfront. And that's been borne out. I think our pay as you go model is less than five percent of the business. So, yeah, it's been working well in that regard.

Janis Zech: I think with, you know, complex systems, something I remember back at university, this was one of the topics. You know, you have complicated systems, you have complex systems, then you have chaotic systems. I'm assuming it's not too chaotic at Rescale yet. Right? Maybe that comes at some point. But there are also principles, I think, you can apply to manage complex systems. Right? Like, what I'm saying is, like, a complex system does not need a complex solution. Right? Maybe that's actually, like, a really bad idea to follow such an approach. And I think you alluded to that in your talk. So I'm curious, like, what kind of principles do you apply to manage a complex system and actually reduce the complexity for comp planning specifically?

Gabe Rothman: Yeah. So there are kind of — and as you mentioned in the presentation — there are four kind of first principles that I identified. The first one being to limit complexity. And the reason to do that, or one of the reasons, maybe the biggest reason to do that is again, to come back to another first principle, which is that comp plans should be designed to drive seller behavior, right? At a fundamental level, that's what it is, right? You're trying to tell the sellers through the plan that we want to emphasize these things in our sales cycle this year. So if you design a plan that tries to do too many things, it has, you know, tons of different accelerators and spiffs and all sorts of different ways that the AE can make money. It sounds cool, right? Oh, if I do this, I get a one point five X accelerator. If I do this, I get a two X. And we have SPIFFs to sell this, this, and this. For one thing, it's noisy and it can actually prevent the AEs from focusing their efforts. And if you don't build it right, you could even create unintended conflicting incentives in the plan, right? So our goal is to identify maybe two, maybe three things that we want to motivate the sellers to do and really leave it at that. And then anything that doesn't fit inside of that narrow construct, we're going to solve in other ways, right? So mentioned deal desk credits earlier, right? Deal desk itself is one way that we do that. We have our deal desk set up in a manner that is somewhat unconventional. What most companies refer to as deal desk, we call sales support. And so that's a function — both functions are on my team — but sales support is a function that does typical sort of like transaction process support. They're helping with quoting, they're closing out the deals, making sure everything is like buttoned up before we close it out. They're helping the AEs get through approval processes, that kind of stuff. Deal desk is a strategic pricing function. And their job is to support our AEs on our most complicated deals, biggest deals, the ones that have the most gross margin risk, for example, because those big deals sometimes require very deep discounting, right? And so as an example of something that we could have put in our comp plans, but didn't because we don't want our AEs spending time on it, is gross margin, right? We could have had something in our comp plan that says, you get a spiff if the aggregate gross margin of your deals across the year hits some percentage. But that's going to create a ton of work and wasted effort on the AEs. They're going to want to know in every single deal. They're going to want to know the margin profile of all of the infrastructure that we sell. So then we're going to have to have tooling that allows them to sort of like back of the napkin calculate what the margin profile would be based on a perspective usage pattern. It would create a whole bunch of superfluous, unnecessary work on the part of the AEs. So instead of doing that, we basically just say we have this strategic function called deal desk. They know the pricing for everything across the company. They know all the bundling rules. And they have their own tooling that we have built that allows them to calculate prescriptive margin on the fly. And then we basically just said — we just put a term in the plan that says very explicitly — so this is actually another point, which is that there's no reason to hide the ball in your plans. Just be completely transparent. Even about the bad stuff, especially about the quote unquote bad stuff, right? So we just have a term in our plan that says, hey, if you're selling a deal that is above — I forget what the value is — above some value and the prescriptive margin profile falls below a particular threshold, the company reserves the right to make a manual discretionary adjustment to the commission. And it's fine. They know it. We know it. It's clear. They're not surprised after the fact. They know that that's gonna be the case when they close the deal because they work with deal desk. Right? So that's an example of how we limit complexity. Right? And it's an example of what I said earlier, yeah, just because you have a hammer doesn't mean everything needs to be a nail. Right? Solve these challenges in the way that makes most sense for the business.

Janis Zech: Right. Yeah. It's a great example. There's three other first principles. I'll try to be a little more brief on those.

Gabe Rothman: The three others I talked about are being outcome oriented, not overcommitting. In the presentation, I said bend reality to your will. And that last one, it really just means that, like, the world is your oyster in a sense. Like, there aren't any, like, hard and fast rules in doing this. And so don't get mentally constrained by what you think comp planning is or should be. You know, there's this notion that people wanna build plans that the AEs can't game. Right? People are worried about people trying to game the plans. And I think that that is a Sisyphean task. Right? It's like, you can try and you might succeed a handful of times, but eventually someone is going to figure out a loophole in your plan. So my point of view is just embrace that. In fact, any good AE is likely to sit down with their plan the first day they get it, read it, and figure out how they can make the most money through that plan. I mean, it's their job.

Janis Zech: Yeah. It's their job.

Gabe Rothman: And so the notion of AEs quote unquote gaming a plan to me is sort of a semantic distinction because that's literally what you want them to do. Right? There's a pejorative sort of implication in the term, you know, game the plan, but that's literally their job, as you mentioned. You want them to do that. So just design a plan or design a game that has the outcome that you want, right? Instead of trying to like do all these things to make it ungameable, right? The other two are sort of interrelated, you know, be outcome oriented and don't over commit. You know? Ultimately, I try not — we as a business, so that's my team and finance in particular — we try not to worry too much about any individual AE. So in other words, like, if an AE completely annihilates their plan one year and just gets paid a really absurd amount of money, which actually happened last year, and an AE gets paid a lot of money, that's okay. And maybe that's good for a number of reasons. Right? Not the least of which is that other AEs see that that's possible. As long as that doesn't destroy your variable compensation budget. Right? That's what matters. Who cares ultimately how it's distributed? I mean, obviously you don't want a scenario where you've got two or three AEs making a ton of money and then nobody else making any money. That's not good. That's a people problem. You're gonna have AEs leaving. But at the end of the day, all you should really be concerned about is developing a fair plan that will not, even in outlier scenarios, completely destroy your variable compensation budget. And then on the first principle of not overcommitting, it's really just making sure you sort of like leave yourself outs, right? So I mentioned that deal desk provision, right? That's an out that we have, right? It gives us flexibility to say, hey, this deal is problematic from a gross margin perspective. So we need to make some adjustments here. We have another term in our — not our contracts — our comp plans. That's very straightforward. It just says this comp plan is not a contract. Like, you acknowledge that it's not a contract, and we reserve the right to change anything about the plan that we want anytime for any reason, right? We don't do it. I can't recall a time where we did that, but it's there. And the point that I made in my presentation that I would also make is that a lot of times comp planning is deciding between a lot of not great options. And so in this case, right, the reason that, or one of the reasons we have that provision is that a people problem, while not good, is way better than a legal problem. Right? So if you change someone's comp plan arbitrarily at some point — and it's probably not arbitrary, there's a reason for it — but if you do that and the AE gets pissed off and quits, that's bad, obviously. That's not great. You don't want that. But it's way better than getting sued and having to defend a lawsuit. Right? So just kind of like another way that we try to think about things, right? So try to keep things flexible, give us discretionary options, right? So what we try to do is we're very, very clear about the mechanisms and scenarios in which we might try to exercise one of these provisions. And then to some extent, mostly because the times that these things come up are almost always edge case scenarios and you can't really predict all of the edge cases, we leave flexibility in the resolution layer. Right? We don't prescribe how we're going to resolve that problem because we don't know what the problem is necessarily going to be until it happens.

Janis Zech: Yeah. I love this so much. I think, you know, if you think about your general billing and pricing model, it's fairly complicated, I'd say. But then you keep the comp plan simple, fair, transparent, and you're essentially hedging your downside as a company, which I think is also important, right, to your point. And then often, I mean, the business changes. Your comp plan was created a few years ago, and you might need to adjust it. Right? And if you adjust it in a sensible way, everybody will understand. There's no, you know, no sales leader or RevOps leader that wants to piss off everybody and make everybody leave. Right? Why should you do that? You lose. Right? So but I think it's a great example of like, okay, the underlying business is fairly complicated and sometimes even in a way that you cannot predict, but then you create those processes around it. I really like those examples. One more question I wanna ask, and then I think we can close it off. But one thing I'm curious about is, so which tools are you using to manage that comp plan? Because I think that's just good to hear for our listeners.

Gabe Rothman: Yeah. In alignment with our sort of comp planning philosophy, we're pretty scrappy in the tooling. We don't have a lot of — in fact, we don't have any dedicated tooling. We don't have a commissions calculation tool. And for the planning exercise itself, it's Excel and Google Sheets, right? We're working with finance to build out our annual plan starting about mid year. So we'll probably be starting that here sometime later this month. And we're building out our pipeline and sales — excuse me — sales target model, capacity model, all of that in a giant — I think we were using Google Sheets last year. And then we design the plan sort of calculator, not the commission calculator, but like literally when we go to create the plans, right? There's a bunch of different variables that we have to figure out, you know, especially around like commission rates, you know, so figuring out an AE's commission rate for this or that based on like the total portion of their variable comp that's available for this component of the plan and their target, right? The math is pretty easy. I mean, depending on what it is, can literally be the amount of variable — or rather the target divided by the amount of the variable comp that's assigned to that target. But we use Google Sheets to build out the plans so that we, you know, when we're ready to send them out, we've already got all the data and we can just, you know, merge it into a PDF and email it out. The commission calculation side, we used to use a commission calculation tool and just didn't have a great experience with it. And that happened about mid year. So instead of trying to figure out a new tool, which would have taken at least a month or two — in fact, I think we were in August when we decided this tool is not working for us. So that would have taken us into October. And at that point, what's the benefit, at least for last year, of having the commission tool. So we took a stab at building our own commission calculation tool in Salesforce with the understanding that if it worked, we would then make it our source of truth in twenty four. And it did. So this year we're using a completely Salesforce native solution that we built in house.