Welcome back to another episode of the RevOps Hero Podcast. I'm your host, Chris Strom, and my guest today is Joanne Cheng, and we are going to be talking about something called CPQ. CPQ, what is it? How does it work? Who should use it? How it fits in the whole revenue operations life cycle here. So thanks for joining us, Joanne. I'd love to first hear a little bit about your background and experience in RevOps and how you got involved in CPQ specifically.
Yeah, Chris, thanks for having me. Really excited to be a part of this, my background is in sales ops and revenue operations. I have a little over 10 years experience working at small to large companies, including hyper growth funds such as Salesforce and RingCentral. While I've been involved in CPQ at almost all companies that I've worked at so far, there's been a CPQ system. For instance, Salesforce implemented Apttus, otherwise known as Conga today. And then at the time, they've also purchased SteelBrick, which is now known as Salesforce CPQ. And then I was at RingCentral where they had a custom-built CPQ, and also implemented Salesforce CPQ at a later stage.
So I've been pretty exposed to the implementation process, the build versus buy situations, as well as all the glorious pain points of both. But that's been all in the past and things are moving very, very quickly, as you know, Chris, with the advent of more PLG, or product led growth versus a sales led growth. And our favorite two letter acronym, AI, which is really changing the game and landscape of CPQ. So really happy to dive into that.
Yeah, let's get going into it. First off, we'll start with the obvious starting point of, we've been saying this phrase CPQ. What is CPQ?
That's a really good question. What is CPQ? Well, CPQ, Chris, stands for configure price quote. It's basically a tool that helps sales teams create accurate quotes for products or services. That is instead of building quotes manually in Excel or email, CPQ automates the process, especially useful when there are lots of options like add-ons or even custom pricing rules.
So configure price quote, and it's for which step in the sales process again?
Well, it's basically after the opportunity closes in the CRM, where CPQ usually lives inside a CRM, a customer relationship management tool such as Salesforce or HubSpot. So as mentioned, you do start with an opportunity in CRM. And then once that opportunity close one, then you use CPQ to configure the deal, the C in CPQ, and then apply pricing, the P in CPQ, and then lastly, generate a quote, or Q in CPQ. The quote does get saved back on to the CRM, so the full deal cycle stays in one place after opportunity closes. If your CRM is basically the brain, then CPQ is the hands that build the deal. So hopefully that helps.
Yeah, that helps. So we talked about what is CPQ, and then the next question from there is who should use it? Who should use CPQ? Maybe who should not use CPQ?
Yeah. Not every company is ready for CPQ. For instance, if you are not having issues with the ordering process, you don't need a CPQ. If there's not too complex of pricing models such as SaaS, you shouldn't need to use CPQ, or even discount rules, you shouldn't have to, or if you just want to use it to report also of ARR, there are ways off of the opportunity where you use custom fields to bring that reporting or the metrics in. I would say if you do have complex pricing or even discount rules, you'd probably be a good fit for CPQ. Otherwise, products like configurations, like size, or region, or license type, those are good potential pain points to add a CPQ, or even manual quoting process, as mentioned, you don't want to do quotes off of Excel, or off Sheets. You want to do it in the system that sales reps are using.
And I would say think of SaaS companies as mentioned, even manufacturers or services of businesses with custom packages. Those are really good companies to have CPQ. And then if you are choosing CPQ, there is a bit of an opportunity loss. Without CPQ, it may slow down the whole sales cycle. And reps, their job isn't to do admin work. And so their job is to continue to sell, and we want to relieve them of making pricing mistakes, any admin work. Also, if finance or sales leaders may not be approving deals fast enough, their job isn't also to make approvals, necessarily, or even for legal. So deals can get stalled or the competitor may be faster with their quoting. You don't want to lose a deal because of a slow quoting system. Also, if data gets lost between systems, like emails, off sheets, spreadsheets, and ordering platforms, I think it's time to implement CPQ.
Yeah, I think what you described for opportunity losses is really important. So just to recap, some of the opportunity costs for not using it are pricing mistakes from the reps, deals might not get approved fast enough. The competitor gets the quote out more quickly as your deal is stalled up in internal communications, and then data sometimes gets lost between your spreadsheets, and the emails, and version one, version seven, and all of that, the finance system, work order, and anything in between are all places where the process can break down and cause some real opportunity costs for you.
Yeah, that's a good point. You want to centralize, especially CPQ, understand that finance has a piece in it, but sales also have a stake. So you want to centralize within the CRM, and having the reporting be seamless as well. So I think CPQ would be great for that.
So let's go from there into, I think a good next topic is say a company says, "Boy, it sounds like we could really use CPQ. What do we do from there? What are our options? What's the landscape like?"
Yeah, as mentioned, Chris, things are moving quite fast because of the advent of AI and more product led growth companies. As mentioned, I've been at a company that had their own custom-built CPQ. They did it because they were a tech company. They wanted to build their own internal products, but also more complex pricing like usage and metered pricing as well. So they built it in-house. However, nowadays, there are companies that can do that too. So happy to go through that. I can start with more legacy CPQ companies. As mentioned, Salesforce is a top one. They bought SteelBrick and it's native to Salesforce, so that's the advantage of a CPQ, otherwise known as Apttus. They've rebranded their whole company. DealHub, Oracle also has one, SAP. All the big enterprise level tech companies such as Salesforce and SAP, Oracle all have their own. But as mentioned, the landscape's really moving fast, and how does PLG and AI are influencing that?
For instance, I don't know whether or not it's because of AI, possibly, but I don't know if you heard in the news, Salesforce is actually sunsetting its legacy CPQ, otherwise known as SteelBrick, and gradually focusing more on what's called revenue lifecycle management, otherwise known as RLM, which actually includes CLM, the contract lifecycle management. And happy to dive a little deeper towards the end. That's after the CPQ on the contract lifecycle management side. There's also billing, ordering, rep rec, all the stuff that is CPQ and then thereafter. So Salesforce is emphasizing that revenue lifecycle management tool instead of just a basic CPQ. So that's changing. And it also helps to better align with more modern needs as mentioned, Chris, like PLG, product led growth uses pricing at more automation. So I don't know if that's news to you. [inaudible 00:10:28]-
The whole space is kind of news to me, so I'm learning a lot here.
Yeah. Within last year also, the big companies have also purchased smaller companies' CPQ, for instance, ServiceNow is also going into the CPQ space and have acquired a company called Logik.ai. HubSpot, as you know, does compete with Salesforce, but they also acquired a CPQ company called Cacheflow. MaxDeal also acquired RevOps.io. So there's a lot going on. There's a phenomenon going on with this purchasing of smaller companies, CPQ companies. I think the PLG and hybrid selling models that is PLG, along with sales led growth, as well as AI may be the influencers. For instance, AI native companies are pioneering new pricing models that legacy CPQ systems just weren't really built for. For instance, from token-based meter billing, to hybrid subscriptions, AI startups demand more of a quoting tool that are fast, flexible, and built for the rapid evolution of AI products. If your CPQ can't keep up, it does slow down the revenue-generating system and you're creating friction in your revenue engine.
That's why more AI native companies are choosing lighter, faster quoting systems that match how they sell today. So a couple of companies that are out in the news out there, really pivoting from the legacy CPQ companies like Nue, spelled N-U-E, they're designed for more modern SaaS companies that need to handle nonlinear deals such as upgrades, downgrades, user-based billing, and without the heavy laggage of the CCPQs, it's also great for PLG companies, where it enables scalable quoting without slowing down the fast-moving product led orgs. And it bridges the gap between self-service revenue and assisted sales. Basically, it can do both the hybrids, PLG, product led growth as well as sales led growth. Both Nue and DealHub use AI as an additive as well to the product versus an AI native. I would say 99% of the companies need to offer user-based pricing now because of AI in products. The way they sell is not just by contract, but by usage as mentioned. So you really need a CPQ that can be a little bit more flexible. If your product has AI, then you must have variable costs, and not just a fixed cost.
So another company that's out there is called Outlit, spelled O-U-T-L-I-T, which is founded by Josh Earle and Leo Paz. They're totally rethinking CPQ for today's fast-moving sales teams instead of starting with forms or rigid workflows, Outlit begins with a conversation, kind of like Gong, and pulling in transcripts, CRM notes, Slack threads, and past deals to generate structure quotes in just minutes. So it's pretty cool with this AI age. A rep doesn't even have to necessarily type in or do admin work. They can actually talk. And then whatever they say can be grabbed, and they built out into a quote. So it's really, Outlit is really building a more modern go-to-market and Outlit brings speed, context, and automation to the process that hasn't really changed in a year. So that's a landscape right now. Are you excited or what, Chris?
Man, it's almost too much to keep track of for me, it feels like. I hadn't even heard of Nue or Outlit before this conversation. I guess I'll have to look them up after this.
Yeah, and I know we'll be deep diving into implementation as well, but Nue is also the CPQ that OpenAI actually chose. And happy to talk a little bit more about their implementation process. This is what I've heard before, but yeah.
So we talked about a lot of the pre-built solutions, so to speak, and then something we were talking about as well was buy versus build, buying one of these solutions and implementing it versus building entirely from scratch. And I'd like to hear your thoughts on buy versus build in CPQs.
Yeah, I think with a lot of things you have to weigh if it's worth buying or building, it is the same kind of similar thought set. However, when it comes to CPQ nowadays because of all these newer companies out there, that buying is not a bad option. I think before as mentioned, I was at a company that built their own CPQ custom solution. It was almost necessary for them to build because they were engineers. They were a tech company anyway, so they had the bandwidth, and maybe at some point they can sell it, too. I think that was the thought process, but also because of the complex pricing models that they had.
But nowadays with new or as mentioned, Outlit, it may not be necessary to even buy. So you do get the faster time to value. You can focus some of your energy into other parts of the company, and then just offload the building to a different company. And unless you have very unique business models that you really, really want to do it yourself, otherwise there may be a solution out there already. I would say most companies nowadays start with a bot solution and then customize it over time. So that's my input as far buy versus build.
I was at a conference last week and I talked to two different people totally separately. One was at a company building a packaged CPQ product to sell to other companies, and then another person had just finished doing an internal custom build themselves. So yeah, just a couple days ago met a person on each side of the build versus buy approach. But yeah, the company that built their own, I think he said it took at least nine months to build, nine to 12 months, I think. And then they have to ... Maintenance and upkeep is all on them as well. So that's definitely, if you choose to build route, you have to know that's the trade-off if you go that route.
Yeah, and nine months is actually standard, I would say, average. There's a Forrester, I would say statistic. It's about that time. And I agree, if you do build all your knowledge is going to be in-house, I think good documentation might be helpful because if that knowledge leaves the company, that you don't have documentation, right?
Yeah.
Everything moves out the door, too. Whereas the buy, for instance, if you buy from Salesforce, you know that there are in-house help. You can call the error, submit an agent ticket, and they should be able to help. It is definitely weighing the pros and cons on long-terms and what you're trying to get out of it.
So speaking of timeframes and considerations like that, I'd love to hear about what the implementation process itself is like. Can you tell us a little bit about implementation?
Sure. I would say it's pretty standard when it comes to any other system implementation. You definitely want to do discovery, design, all the software development, life cycle, build, test, train, and definitely roll out. But one best practice or a couple best practices along with those phases, I would say get the sales team involved early and often because that's the tool that sales will be using a lot to make money, to create, generate quotes. And so even at the initial discovery phase, you want to get them spelling out what are the pain points of the current process for the system, and making sure we're solving for it as much as possible, and automate any manual processes possible, as well as using AI for those that have AI built in. Also getting the- [inaudible 00:19:52]
Use AI for what specifically?
Well, there's Nue. Nue actually has a AI component to it. And they used it to help implement and analyze OpenAI's company. And so they were able to reduce the amount of time from average, a few months, as mentioned, nine months, down to only eight weeks because they had an AI component to their product. Their product is AI driven with automation within Nue's platform, which helped facilitate the auto generation of product configurations and pricing rules for OpenAI. So it really helped streamline the setup process and reduce the manual effort. So that's Nue, right, because of the AI driven automation. But if you don't have that, or even if you do have that best practice is always to also get the sales leaders involved, have them be selling the product that's going to be implemented. You want to get the sales force, so to speak, excited about CPQ and how it'll solve their pain points, et cetera. So I would say those are some of the best practices. Get sales users involved, hear their pain points, get sales leaders to buy in, and communicate out as well as during the training phase, or the rollout phase, or even before it, during the testing, have a couple reps, super users test it out, have an iterative feedback loop where the quick wins that I know it's in testing phase, but they're able to solve some of the quick wins by relabeling certain fields or a sales path, et cetera. Those are quick wins that would help the sales rep along. And then have them demo it as part of the rollout or the training phase.
So then you know the sales users are going to be adopting. You don't want to implement a very expensive tool and not have them adopt. So you want to see the ROI. And to help drive the ROI is to get sales involved from the get-go. And in regards to typical implementation time, it typically does take three to nine months, and the cost to implement can be 200K to 500K, and that's a Forrester study on CPQ implementations.
And that's not even custom-building your own, that's rolling out at a large size company or medium to large company that's just implementing a pre-existing solution?
Yeah, that's the average timeline. And it really depends on the complexity, just like you said, if it's custom or very complex, it may or may not take longer, just so you know.
Yeah, I was talking to another person I know who runs a Salesforce consultancy, and he was telling me that on average their typical CPQ implementation projects, they're literally 10 times larger than their typical Salesforce Sales Cloud implementation projects. And I was shocked. I couldn't believe it.
Yeah, I think because of the complexity with pricing and approvals, I can imagine. Because a typical Salesforce one, a lot of it's already there. You don't have to custom build anything, even for configurations. So yeah, that just to stick does make sense, Chris.
Oh, yeah. You agree with that assessment as well?
Yeah, I agree.
Okay. Interesting. So if you want to implement CPQ you better just know what you're getting into before you start, it sounds like.
Right. Unless you'll purchase new, it sounds like they have some AI driven automation, so that's something to consider, that we're able to do OpenAI in just eight weeks, you know, just two months.
Yeah. I guess I'll have to check them out myself.
Yeah, see how AI is really driving a lot of stuff and reducing the time to do anything nowadays?
Yeah. And then for the implementation, I know you had mentioned some stakeholders, but could we recap again the different stakeholders involved typically and what their goals and needs are?
Aside from sales reps and sales leaders, finance does have a stake in it because they're also the ones that have the guardrails on discounting and revenue accuracy. Although they're not the main users of CPQ, they'll do the approvals unless the approval's already baked in for a certain amount of discounting, like the large discounts, and ensuring that they're still profitable, the company is profitable finance will be approving. And so you want to include them too. Legal, yeah, legal may be caring about it on the quote language or contract terms, so less of a stake, but not as strong of a stake as say sales and sales leaders, but definitely still has a stake in it.
Ops and revenue ops people like me may help because we're also focused on process efficiency and reporting. We want to make sure that whatever is on CPQ is reportable from ARR to maybe the time it takes to approve a deal, we want to measure and make it even more efficient. And then IT of course, is definitely a stakeholder ensuring that the data flows between the systems, like obviously Salesforce, your CRM, or even HubSpot to CPQ, to a CLM, to the ordering system, and billing system, and revenue recognition systems. But again, you definitely want to get sales reps and sales leaders in at all phases of the software development lifecycle in the project.
Yeah. And that's a great segue into the last thing we'll talk about here. You mentioned CLM versus CPQ, so I'd love to hear about that. What is CLM? How is it different, or the same, or an expansion or extension of CPQ?
Yeah, so CLM is contract lifecycle management. That's what it stands for. It's a big topic on its own, so happy to do another one in a future episode. And as indicated, once the quote is come and sent out, you want to make sure the contract itself that needs to be signed and sent back to us, that's the system CLM can handle. It basically takes over after the quote. It manages the contract generation, the red lines, the approvals, some legal, and whatnot, and the e-signatures, even the renewals. Why it matters, it does prevent duplicate approvals and manual entry, meaning that if you had some approvals on CPQ, you don't want to have it on CLM. That's going to drive everyone crazy, including the approvers to sales. "Why are we duplicating the same approval process?" So you want to streamline as best as possible, and it does speed up contract turnaround too, if you do implement CLM.
Lastly, it does align sales, and legal, and finance on the same data and complements CPQ by helping include the loop between sales and legal. And the best practice is if you already have the data on CLM as well as CPQ, then don't have sales reps enter them on CLM, automate them over on CLM. So you want to make sure when you're implementing CLM, that data flows through, and then not have sales reps or anyone to be entering the same data that's already there.
Plus, on the reporting side, where are you going to report? You want to report in the same system that you're already using, unless there's new metrics on the CLM side, then you can report off of those. So yeah, all the stuff we just mentioned, CPQ can be handled and then some basically on CLM, that includes product configurations, pricing terms, billing info, signatory contracts, and approvals. And because CLM has the potential to speed up contract turnaround time, it'll help you lock in revenue even faster, so more to come. Right? But that's basically it when it comes to CLM.
Got it. Yeah, I think that's a great idea to do. We'll have to do a followup episode going into CLM specifically. And then, I mean, there's so many other related topics, too, like you mentioned revenue recognition, and how the finance system will connect to the CRM system, and the processes of handoffs between teams for all of that. We could do plenty more topics to talk about in a future episode together.
Yeah.
Cool. But I think this has been a great overview of a CPQ itself and how it fits in the cycle. There's a lot of interest in CPQ these days. I was just mentioning I talked to two separate people last week who were both independently doing CPQ rollout at their companies. I'm talking to some people later this week who are working on a CPQ system of their own. So it's a hot topic these days for sure, in the RevOps world.
Yeah.
So I'm glad. Oh, go ahead, Joanne.
Oh, no, sorry to interrupt. I've been talking so much that there's just so much that I'm speechless right now, but I was ...
Oh, yeah.
But yeah, it's been great chatting about all things CPQ, and then CLM in the interim.
Yeah, I've learned a lot myself here. I think a lot of the people who listen or watch this will learn a lot from it as well. So I'm really appreciative and thankful that you took the time to come on and record this with us, Joanne. So thanks for doing that.
You're welcome. Thanks for having me. And I really appreciate this conversation, Chris.