the Enterprise Monetization Podcast, Sandeep Jain sits down with Sudhakar Jukanti, Head of GTM Systems at Confluent to discuss how Confluent manages its Usage-based Billing
Welcome to the 11th episode of “The Enterprise Monetization” podcast. And this is your host, Sandeep Jain. In this podcast, we invite thought leaders from monetization space that is CPQ and billing, so that you can learn about challenges, opportunities, and best practices in monetization. Today, I'm super thrilled to invite our guest, his name is Sudhakar Jukanti. Sudhakar is an expert in Quote-to-Cash, his experience spans across like 20 years. Currently, Sudhakar is the Director of Go-to-Market systems at Confluent, which I'm pretty sure all of you about. Prior to that, Sudhakar was at companies like Apttus, Deloitte, and Oracle where he dealt with things related to Quote-to-Cash. Sudhakar is also LP at GTMFund as well which is a fund for sales and go-to-market professionals to invest in companies that build tools related to that area. Sudhakar, and I met three, about maybe four years ago, on a cold reach out, when Sudhakar was working at Apttus. And I was doing research in Quote-to-Cash. And that first conversation turned into those multiple conversations. So Sudhakar, welcome back. Super excited to talk to you.
Thank you Sandeep. Great to be here. I always enjoyed our conversations on this space. I really thrilled to be here.
Awesome. All right. So before we go talk about Quote-to-Cash. Let's talk about you first. Can you share a quick fun fact about yourself?
Yeah, sure. So there are a couple of things happening these days. Every weekend, I'm doing either one of the two activities. One, I'm doing a lot of practice hikes for my grand canyon rim to rim hike, which is next week. Second, my younger son is into Rubik's Cubes. He goes to competitive tournaments and taking him every other weekend to these tournaments. Then connecting the dots one of my nephew in India he does the short films. When I explained about this, he has a storyline about a Rubik's Cube name ‘Father and son hike’. He and I are currently working on a story. We want to do a short film by end of the year. That's where I'm spending my weekends off.
This sounds very fascinating. My son is also in Rubik's Cube though. I don't think he's in competitive thing. He's trying to get there. But I understand the whole drama around you know, saving each second, microsecond here. So it's cool. Wish you luck for your massive hike next week.
Yeah, sure. Thank you.
Awesome. Sudhakar, can you also provide some perspective on the journey that you took to get to Confluent?
Yeah, absolutely. So I'm in the space roughly about 20 years, I've started my first job with Oracle premiere in the pricing, pricing and order management team where I've built the pricing engine for Oracle that kind of sold interest in pricing use cases. So I started my journey as a developer in pricing team then later moved on to Deloitte, implemented pricing for many, many customers and later implemented Quote-to-Cash. I'm really fascinated about how the technology solves the business challenges. In 2014, I was looking at a transition to cloud as that's a new thing in the world at that time. Then I came across a company called Apttus, a CPQ company, building around CPQ. Then I spent about seven years in Apttus played various roles. I lead CPQ practice in professional services, pretty much touched every complex team the company has sold either in implementation capacity or pre sale or support or working closely with product and engineering teams. And later on, I've wanted to move it make a change to a different domain. Being adapt as I've seen many companies, I want to get into an internal IT role. Currently I'm at Confluent. I manage to Go-to-Market systems for Confluent primarily around Salesforce CPQ and financial force type of systems, but essentially delivering the value for the business partners in Sales Ops Deal Desk customer success, peers, and education.
Awesome. So let's go deep into Quote-to-Cash now. Can you talk, and you talked about your role at Confluent but can you tell like, how's the team structured the Go To Market team because sometimes there's RevOps team, there are engineers, I've seen even product managers. So can you give a sense of how this is within Confluent?
Yeah, sure, absolutely. So our team is structured around business system analyst, I primarily manage team of BSS and Program Managers. And I have BSA for each business domain, one for Sales Ops and one BSA for dealers, one for PSME, and other for customer success. And I also work with the engineering teams, which are managed by one of my peer. And we have an engineering and architectural team, my team works very closely with the engineering team, and also worked with our business to get the project enhancements and deliver it to them.
So this engineering team that you talked about Sudhakar, is this like Confluent engineering team, or is this an engineering team within IT where I believe you're part of?
Right, it is engineering team within IT.
Got it. And how big is the team?
So we have roughly, including contractors, the engineering team, around 20 to 30 people.
I see. And these engineers work on tools like Salesforce, financial force, the things that you talked about earlier?
That's correct, Salesforce CPQ, financial forces, etc.
Got it. And is that the model that you describe? Because the reason I asked this question is, when I talk to customers, they're trying to figure out how to architect their team, or how to structure your team, because you need engineering folks, you need product managers sometimes and IT, is that the best model you think is out there?
Right. I think the way we further structured. So recently, we have started an Agile transformation journey, we had an Agile coach to look into our processes and help guide us on what should be our future way of working. And the recommendation came from them is to have individuals scrum teams, the scrum team consists of a product manager, product owner from business primarily, and the BSA from my team, and an architect and developers, I think this scrum teams type of model, I've seen it other companies do, that kind of helps us to deliver at the speed of business. It makes us nimble, it makes us able to react to the change and deliver in time for business.
Cool. And you also talk about your peers owning the engineering team. So can you talk about little like, how your team not like managing down but sideways? And of course, how is that structured?
Yeah, sure. So my peer managers team of architects, and engineers, and based on the business requirements, my team does the analysis and work with the engineering team, and which also consists of QA team, and we get the stuff delivered, that will work with business for you at individually take it to production.
Got it. Cool. Can you describe the Quote-to-Cash stack at Confluent?
Yeah, sure, definitely. So I think if we look at our sales motion, like we sell primarily through direct channel, as many companies do. We also sell through marketplace, like multiples consisting of the Google Cloud, Azure, AWS will sell through that channel. And we also sell through our SA partners, or our various partners, SA, SA’s, and ASVs. And we also have PAYG motion, Pay As You Go, customers can sign up and start using content as solution. So to cater to the various channels of operations, the toolkit we have is we are heavy Salesforce shop, we also use Salesforce CPQ, NetSuite for finance, and our product end team build some in house tools to support some of these use cases.
So you are actually the first B2B Company that I'm speaking with in this podcast that's pressing all the levers of Go To Market. So you have self-serve, you have sales lead, sales motion, you have partners, and then you have the marketplace as well. So your Quote-to-Cash stack must be very interesting. So tell me, what do you do for partners? Like how do partners quote from for Confluent?
Yeah, sure. So we are in the initial stages of the journey. So currently, we have a partner portal where the partners can submit the deal that deal which process is more automated, but the quoting process is still done inside CPQ. We haven't exposed our quoting tool to partners, we are not there yet. But currently, they work with our field teams to get the quote out to the customer.
Got it. And the reason I asked this was this, because what I've heard is partners have this indirect workflow. So I was curious if they you have a direct workflow. Marketplace, how is that thing structured because that's what I've heard is that it's very manual process today, where you get these usage reports from these different cloud vendors and then you take these usage reports and put this in your financial or accounting system. Is that what it is done at Confluent as well?
Right. So it is kind of evolving, as you know, even the marketplace partners themselves, you know, considering AWS, Google or Azure, they're also ever evolving their processes, and how do we interact with them? There are certain manual operations that we currently have what we're working on a huge consumption transformation initiative to automate many of those processes.
Got it. What about self-serve channels Sudhakar? Is that hooked directly to NetSuite or do you use a different billing system? What about quoting on self-serve?
Right. So our self-serve is primarily credit card driven. It's a developer persona, if they want to try Confluent, they can log into our website, we give free credits up to $14 for anyone's to try our solution. So beyond that, if they want to use more, that's charged, the billing will be done through credit cards on file and information will be fed back to NetSuite for the financial transactions.
I see. Is there a separate billing system where you manage the self-serve or…?
No, it's embedded in NetSuite.
Got it. Okay. So tell me, so one of the biggest challenges for you, when you look at the scope to Quote-to-Cash stack, and I think you mentioned about improvements that are happening in marketplace in partner workflow. But if you have to name like three key challenges, or three top of the mind thinks for you, what would those be?
Yeah, sure, differently. So as a company, we are a consumption based company. So we are evolving our business process around consumption. So being in the technology space, the number one challenges for me is to build a system for a business that is evolving. And there are not many vendors out there who can address all aspects of consumption into end. So that's kind of a number one challenge, or how do I build the technology stack for a business that is evolving and support all the use cases, then the ecosystem around consumption is not fully baked, for example, working with marketplace partners, the marketplace partners themselves are building some functionality to make it easier for vendors like us to work with them. So now, once they have builder’s toolkit, how do I ensure that the technology stack has building works well with those partners and delivers the results for our business. So that's the number one challenge that we have. And I would say number two, is around having the renewal information accurate. As you know, in the business in CPQ, there are a lot of transactions that happen, then how do we ensure that any given point of time, we are getting the right renewal information’s, if we were to do renew, do we know the right product, right price, and right terms, etc, we have some challenges around that. Along those lines, we are in the journey to build an entitlement system. So that kind of covers or tracks everything that customer actually entitled to in terms of the substitution information, support information, or provisioning information, or also for internal teams, if they want to understand a customer, and what is the information they need to have an intelligent conversation with the customer. So that's kind of renewals find entitlement is the second challenge that we have.
Understood. So renewals, I'm assuming is primarily done with Salesforce CPQ because that's where the information is. Is there any specific challenge or is it just like the data is spread in like 50 places? So how do I get it together, or is it like a tooling problem like, or is it a data problem?
Right, right. So it's more of you know, as we are evolving the business, so not every business processes automated. Like, for example, for the consumption business process, we have done the new sale fairly well. But the expansion scenarios or the multi-year scenarios, we still have some manual process. So now, when you are looking at this customer holistically, because of some of this manual process, the information that we have is not always accurate, we need to do a lot of manual processing to get to the right level of information.
So it looks like there is a process and a data problem because the process if it is manual, it will create a data that's not can be easily collected. Okay, understood. What about entitlements? Is it a separate product that you're building inside with your engineering team?
No, we are still in the analysis exploration phase. It is at this point at an high level we're thinking to expand the CPQ contracts that we have and add additional data elements to support the entitlements we have but ultimately our goal is that if anyone at Confluent wants to talk to a customer, we want to have everything in place for them to have an intelligent conversation with customers. So we have just started the journey, we are still in the defining phase.
One of the things that I've heard again and again is in this Quote-to-Cash stack, is the data model of one tool is not compatible with data model of another tool. Is that your experience as well?
Yeah, I think working at Apttus, that's definitely the experience, because Apttus had everything built on one data model. And we have seen the advantage between CPQ and billing primarily being on one data model, how effective it was to support all of the CPQ process, not only new sales, but amendment, renewals, expansions, multi-year deals, it made the billing really elegant, because the source data is fed through with a CPQ. But when I started implementing it other places, primarily having CPQ in one, tool and billing in other tool, I've seen a lot of integration challenges to feed data from CPQ to billing. I honestly believe that having everything in one data model will take advantage.
Understood. And with this, in your particular case, when you're looking at different tools, is there an internal thought about let's get to one data model, or is that what your entitlements would do as a data model or is just entitlements only because the data model will be Salesforce CPQ and NetSuite, I guess?
Right. So I think we will be expanding on the current data model that we have. So currently, we use Salesforce CPQ contracts primarily. So our thought process at this point is to enrich the contracts data that we have, and add additional elements that's needed for various tips.
Got it. And Sudhakar, a lot of people that we speak with, and a lot of listeners of the podcast, our high growth companies that are just, you know, getting and biting their teeth in this Quote-to-Cash stack. What strategy would you recommend to them? Because they are, I'll give you an example. Like I was talking to another company yesterday, they're doing the CPQ through a Google Docs and an order form, which is I believe everybody does that. Invoicing is manual. They're like scratching their head as to what to do for CPQ billing. What would it be your advice to them? And it could be like, hey, CPQ and billing, keep it separate or keep it together? Any guidance that you can give to the audience?
Yeah, sure, definitely. So being adapters working in this domain for many years, I've seen many CPQ implementations. And the number one advice I would give is to look at this project as more business transformation projects rather than a technology project. And the reason I say this is, many times when you don't start the transformation and just jump into technology, you really don't understand the depth of the use cases. Just as an example, in CPQ world, the new sale scenarios are pretty straightforward. Many of the companies or many of the tools does the new sales process very well. But then when you add the complexity around amendments, complex stuff renewals, that expansions and you tie that with [inaudible 18:15], you tie that with solution itself, when you add all of these scenarios, when you layer this, the business scenarios becomes very complex. And many times even the business teams are not super clear on, how does that flow should work or should look for them considering all the nuances? Now, the resultant outcome is that, as a company looks for metrics, CPQ is a source of most of the financial metrics. And when you are looking to calculate those metrics to get to the right metrics without really understanding the depth of this process, then it'll be challenging. So many attempts, the project goes in circles, you start with something, you think it's working, but when it goes to these complex scenarios, and then it doesn't work. It will go through multiple iterations. I've seen many companies where they have done CPQ implementation two, three times to get it right. So my suggestion would be to document every aspect of the complexity of the business process, see if we can simplify to an extent. And also think of all of your metrics, what metrics you want to generate out of CPQ and ensure you're capturing enough through the transaction to support your metrics.
That's a great advice Sudhakar in terms of thinking it from a requirements, cleaning up requirements, and what you need from your CPQ perspective. But in terms of architecture, so like the companies I'm speaking with, they are thinking about self-serve, there is a CPQ for direct sales, usage billing, invoicing, this self-serve billing, what's your guidance on how to solve these problems?
Sure, sure, definitely. So I think from an architecture standpoint, I think we should have a common engine that supports various channels. Like for example, no matter how you get the transaction in, the flow from a quote configuration to pricing, generating order form. And following through subsequent renewals expansions, I think that flow has to be standard, then you have to layer in a channel in front of it. Okay, how does this look like if you have indirect inlet? How does this look like if you have a partner inlet? How does it look like you have a self-serve? And if you don't have a common engine or common flow, if you have complexities or many nuances around the flow, then it becomes very difficult to expose this engine to various channels, don't you need to build different solutions for different channels. Now that will limit you from adapting to change that if you have to add any new feature, you have to think through that in order that feature work, or you may need to do it at four places to support four different channels. So from an architecture standpoint, always have a common engine that covers the core aspects of the business like record configuration, pricing, discounting, order form, and renewals, I think if you have the quote laid out, then you can have the nuances on the front end, channel specific nuances on the front end, that would help customers.
Got it. And Sudhakar, if you have a system with multiple tools, and you're doing any pricing change, or packaging change, what's your suggestion of how much time would it take to make those changes? Like, what is the best practice that people should aim for? Is it like weeks, days, months like what's that? And I know, it's depends on the scope of change as well. Like, if people are listening is like, okay, this is the benchmark that we should hit. Is there something you can share on that?
Yeah, definitely. So that's a great point. So whenever that app test when we were implementing it, various customers said, one of the common challenges we hear is that, hey, our [inaudible 22:05] process is so long, it takes literally months for us to introduce a new scheme. Then when you bill on it, and that's this genuine problem. But then the details are fake, it is not a technology problem, right. So for any company to introduce a change in the scale, or change in pricing, pricing is a little easier, but add to introduce new skills, it really needs the cross functional collaboration from how do you sell to how do you market? How do you do support to the product? How do you build it? Then how do you drive enablement? How do you do a level [inaudible 22:41]? How do you generate in advance? So to get alignment on the requirements from all stakeholders is probably the one that makes more time, then building in the system. So to your point, what should be the, you know, ideal time? I would say if you can do anything between four to eight weeks, that's a good sweet spot in my experience. What if you are introducing a brand new category of product that needs a different revenue recognition pattern, for example, or a different pricing or discounting structure that may come along, but anything between four to eight weeks is just enough.
Got it. And Sudhakar, I don't think we covered this point earlier. But Confluent, I think you said is the usage based model that we all know of. So what do you do for usage billing? Have you built something internally, or do you use an external tool for that?
Right. So for usage, we have built in house solutions, so our Product Entity built internal systems that kind of captures the usage and data usage. And once it is done, it's sent to NetSuite for invoice.
Okay. Do you have any thoughts on because I think it's mostly the popular question you get yourself is build it or buy it. Any thoughts on how people should consider either of these options?
Right. So usage is always a very tricky aspect of the architecture. So the reason is, it is tied so closely with the product. So, no matter what product you sell, when you're in the usage model, you need to track the usage and the tracking has to tied with the core product that you're selling. So if any vendor that's coming in, it will be difficult for them to get all the information that's available in the product. So to your question of buy versus build, I think at this point as we speak, the consumption business is still evolving, there are not all the nuances of consumption is [inaudible 24:45] up. For example, how do you comp your reps? Each company does differently. There is no gold standard not defined format on those aspects. Similarly there are many nuances of consumptions are still being evolved. So from a technology company standpoint, I've not seen any tech companies solving all of those nuances. I mean, they don't know to be honest, because the business itself is always. So once we reach at a stage, like subscription business today, many aspects of subscription are mailed out, it's relatively easier to build a technology solution for a subscription business. But for consumption business, I think the business is still evolving. Once we reach a stage businesses can a business process or stable or standard across industry, then if any company builds a tool at the time, probably might explore to buy but based on the current state of things, I would incline towards billing it.
Understood. And Sudhakar, are there any intricacies? Because if I would assume anything related to usage, billing, or quoting that a company should be aware of this like, Confluent would understand this, because you guys must have seen it all. Are there any interesting scenarios around usage, quoting or billing, that it may not exist. It may be like, it's all simple. But are there any uniqueness to this usage use cases that you can share with audience?
Yeah, sure, definitely. So one thing that comes to my mind is when you are doing expansions, for example, with customers, one of the key aspect is how much customer already used, and that information keeps on changing, depending upon day of the sales cycle. As sales cycles, typically tend to between weeks to months, depending upon what point you started the transaction, the usage, information could be different from what time you close. So having the dynamic nature of information while doing a sales transaction, is kind of makes it really interesting. Even for customers, they don't know how much actually they need to expand, as they don't know when actual the deal will be closed.
If I were to understand what you're saying is, at the time when you close the deal, you thought you need ‘X’, but when you actually close the deal, your usage has jumped to ‘Y’, what you're saying is you're quoting or how you sell usage should account for this delta?
Exactly. And the delta is more dynamic. If it's a static, it's probably you can have some logical formula to do it, as it's dynamic. How do you kind of incorporate that into your coding process? It's kind of interesting use case.
And I just thought of this thing. So for enterprise customers, it's probably a prepackaged thought through deal. But for Pay As You Go, P-A-Y-G customers, it's like, here's a credit and you use it, do you see any challenges between supporting both workflows, usage workflows, or differences or similarities?
Right. So Pay As You Go is primarily more of a land motion. So this helps you to get new customers. But as customers become big or use more, then they will transition to the commit based model, because they will get better pricing with commit, as even companies when they commit for a larger amount, you’ll give better discounts. So I think in terms of challenges, and both of them in a way are different workflows currently. And in terms of the revenue that we get from commit versus PAYG, there's a huge difference. It's primarily commit. So as we have different workflows for both of them, but I don't see any challenges that such.
Got it. And with this commit business, I just thought of another question as well. Is it ever to business models there? One is that I'm a customer, I come to a company called Confluent or anybody else. And I say, Look, I'm going to spend $100,000 with you this year. And so I'm doing a commit, but I'm gonna pay you at the end of the year, or is pre by usage where I say, well, I'm giving you $100,000 cheque right now. And I'll use as much as I want in this year. So which one is this, is this arrears, or is it like P&L?
Yeah, it's both. It's both. That's very penetrating of CPQ or Quote-to-Cash, why it is complex is, the nuances around how do you sell them in your question. We do support both type of models. But when you layer then we layer that with multi-layer that makes it even more complex.
Is there one preferred model that you think companies should be doing or is it like, it depends on what the customer wants?
Yeah, I mean, ultimately, we need to serve our customer’s needs. Some customers like pre-paid (with inbuilt discounts) and some customers prefer pay-as-you-go (lower amounts). So I will say, multiple options, whatever works for customer, we choose that.
Understood. And Sudhakar, what are your top priorities for you and your broader team in general, for the next quarters?
Yeah, sure differently. So one of our priority is consumption transformation, as I mentioned, so build that toolkit to support all of the consumption use cases for our business, that's one. Second, automation, we are looking at our current processes and tools and identifying the opportunities to automate, we have a lofty goal of saving couple 100,000 hours, by next year, we are working towards that journey. Then, third one, we survey our internal teams every year, through culture lab, we get the scores on whether the teams have right tools available to support or do they have the right process to help themselves. So we kind of look at the scores every year, and we benchmark against their peers, and we try to constantly improve scores for our field teams. So that's another priority for me in coming soon.
Got it. Did you say when you say automation, did you said a couple of $100,000? Is that what you want to save by doing automation?
It's a couple of 100,000 hours.
Hours.
Yeah, man hours that needs to be saved.
Got it. Got it. And this is for automation, around quoting billing?
Exactly, yeah. All class of the company.
Got it. And actually, I should have asked you this earlier, what's the scale of Confluent like selling like, how many salespeople you have? And how many SKUs you have, or what you're selling just so that audience have an idea of the scale of the problem?
Yeah, sure, definitely. So I think we are around 2000 people company, roughly 1000 People in sales. We have 1000 sellers. And in terms of products, we have broadly two category of products, one, our subscription product, which is Confluent Platform, the other is a cloud product Confluent Cloud. But we have couple of SKU’s to support these two categories. And in addition to the quote products, we have SKU’s in professional services and indication that we sell as well.
Got it. And Sudhakar, a related point. Can you give us an idea on the metrics, what people should sort of track when they're putting these systems together? Like, what are the things that they should be looking at just held up these systems?
Yeah, sure, absolutely. So I think, one key metric is to capture deal velocity. How fast you are closing the deals, each step of the process. Are you making it fast enough to close the deals? Deal Velocity is number one, then number two is the number of quotes touched by the list like how much automation you have in the flow, that you don't need the list function to manually review the quote and bless it to automation around the quotes touched by the Deal Desk. Approval cycle time is one metric, I would say, then, Risk and Compliance, like how many list errors we have in terms of quoting or invoice generation, etc.
Got it. And Sudhakar, so that people understand these things well, could you give a sense of what these numbers typically should look like? So when you say Deal Velocity, is it a, I always get confused about this, by the way, is that the time when as a salesperson, I start creating a quote and stop what starts to the time that customer accepts the quote or when I send, is it like from a salesperson purpose perspective, or is it, how much time does it take to close the entire deal?
Yeah, I think it's a salesperson perspective. You know, starting from when you initially start opportunity to all the way to the closure, so how much time it takes.
Okay, and so is it about like, how, what is the right way to track this is like days, hoping not months, but is it like should be minutes for sending out quotes, like what's the right way to look at this benchmark this?
Right, right. So I think it varies depending upon the segment you're selling to between commercial and enterprise, the type of complexity and the durability, but ultimately, the goal would be, are you showing improvement in velocity in those segments, year over year? I think that's probably the better way to track percentage increments yearly.
Understood. And looks like we've got the 10 minute warning. So let's talk about the second metric. You said number of quotes just by Deal Desk. And this Deal Desk is like a hot topic at every companies because you have to have hire somebody. And could you give a sense of if everything's are the processes and technology are actually aligned, what percentage of deals should be touched by Deal Desk, like if there's more than that, then the red alarms or the red bells should go off and you need to come and fix the tooling or something like that?
No, definitely. So I think that's an interesting point as Deal Desk as a function typically gets involved in many of the deals, if not almost all the deals, I think as a process, we should always look at going the deals flow through as much as they can. So in terms of percentages, it varies by complexity of the business, but the segment the dollar amounts, etc. But at least there are certain scenarios of business that should just go without being touched by Deal Desk. As an example, when you're doing a flat renewals, you are renewing exactly the same terms as the previous deal, then those kinds of deals should not get touched by Deal Desk. And also if the quote is in the within the boundary of limits set by Deal Desk in terms of the discount thresholds, the dollar amounts, the segments, those has to naturally flow without being flagged.
And tell me what a Deal Desk could actually do on a quote, they would look at the discount and see if it is out of whack, or they edit the quote like what are the things that they would spend their time on?
Yeah, so Deal Desk, they're the experts on how a deal to be structured. So not all A's, may not be familiar with the intricacies of the right way to sell to your customer. So Deal Desk kind of guides them on putting a right quote together. And of course, as part of that they're looking at, you know, what they're selling the right products, or the right price, right margins, etc.
So it's not just an approval thing, but it's like taking a look at the deal holistically and say, oh, you should selling this product, your discount is too high. You should probably do a rap deal, things of like that.
Exactly.
Understood. And we talked about approval cycle time. Is this like, days, probably hours, I guess, maybe it's about measuring what you have, and see if it is going down or up?
Right. Approval is an interesting piece. Because when you start the CPQ journey, many other stakeholders, they want approvals. But when you measure approvals after one or two years after the implementation, at times, I've seen approvals becoming so much that people just approved without actually looking into the details. So you need to hit the right balance between sending the approvals but not sending way too many approvals.
Got it. And related to that, I know we talked about usage earlier. But what would be your guidance to RevOps teams that are thinking. Should we go usage, or should we just hit a pause on it and look at it later when the tooling becomes more commonplace, I guess? So should you or should you not go usage billing?
I think, personally, I think usage is the future. If you look at the evolution of selling models, you know, we moved from perpetual to subscription, now subscription to usage. And our CEO Jay calls it as an intellectually honest business model, where customer is paying for what they're actually using. So in the subscription model, you have scenarios where you sold, let's say 100 seats, but you don't know how many seats those customers are using. Customers may paying more than what they're using. But in the usage based model, customer is paying for exactly however much they're using. And that gives a huge advantage for customer and the companies as customers seeing the value on what they're paying, and we're collecting the money for what they're using. So I personally think usage is the future. The toolset is evolving. So is the business model. But eventually a couple of years, I think people will figure out on what's the right way to structure teams, RevOps, etc. I'm sure the technology will catch up and available for business to use.
And besides usage Sudhakar, is there anything else that you expect to see changing, or revolutionizing in this world?
Yeah, sure. I think the product lead goes broke, the PLG model would also become more prominent for any companies that they can at least sell without the sales teams to begin with. It's more of a land of motion. If you can use PLG to land and then you can go to your enterprise sales team further expand motion of the sales. I think PLG will become more prominent in coming years.
Got it. So Sudhakar, this was an excellent conversation going over usage, and CPQ and billing. But before we let you go. Do you have any recommendation on a resource like a book, a podcast or maybe a blog that you would recommend to our listeners?
Yeah, sure, definitely. So one of the books that I've read as a huge influence me as a leader is book named Trillion Dollar Coach. This book about a gentleman named Bill Campbell. Bill Campbell is a person who coached teams at Apple, Google, Amazon, likes of Steve Jobs and an entire Google executive team. And in his book he talks a lot about people management, lot about how do you personally connect with your team? Starting from how do you conduct your one on ones? How do you take your one on one seriously? There are so many examples of how Bill kid for his team, that's a huge learning for me. I highly recommend this work.
Awesome. Sudhakar, thank you again for your time today.
Thank you, Sandeep. It's nice talking to you.
