If your CPQ implementation has failed — whether causing logistical headaches, falling behind the times, or just not useful for its intended purpose — there’s good and bad news (and then more good news).

The good news: You’re not alone. CPQ failure is increasingly common, as market conditions move away from what legacy CPQs can handle, so you join many others in looking for a way forward.

The bad news: Many common workarounds for CPQ failure don’t work. In fact, they often make things worse and demand even more of your time and effort.

"Many common workarounds for CPQ failure make things worse." 

The (second) good news: You can learn from companies that came before you to figure out why your CPQ has failed. And recent innovations in the industry can give you a viable way to re-implement CPQ and stick the landing for good. 

Failed CPQ implements can often be traced to four specific shortcomings:

• Adoption: Some or all users and teams ignore the CPQ as it doesn’t meet their needs.
• Isolation: CPQ and billing don’t talk to each other.
• Inflexibility: Complex custom rules and workarounds make any changes difficult.
• SKU Proliferation: Adding more SKUs becomes a major management burden.

But you can’t move forward until you get the lay of the land. Let’s review why each of these scenarios occurs, why common workarounds can make things worse, and what to do instead.

__________________

Of the various kinds of CPQ failure, this is likely the most readily apparent. The product fails to meet sales reps’ needs, so they don’t see a point in using it. Unfortunately, this is more common than you might think.

Quickly-scaling companies often need to get a CPQ in place fast. But a rushed implementation skips over a few important considerations: namely, making sure that the product will meet company needs over time.

"A rushed implementation may not consider whether the product will meet company needs over time." 

In this situation, stakeholders may skip over a thorough discovery process, attempt to integrate a CPQ with other systems that don’t mesh well together, or fail to invest enough in the sales enablement process. 

This kind of hastiness often leads to one of two outcomes, either of which makes sales reps unwilling to use the CPQ system:

• It’s too complicated for sales reps to easily integrate into their day-to-day work.
• It is very good at one thing that matters (for example, quoting subscriptions), but falls short at other things that matter (such as handling mid-term contract changes and renewals).

__________________

Why the common workaround doesn’t work

If the sales team doesn’t like working with the CPQ, one solution is to hire a specialized team for the CPQ work instead. This gives rise to an order desk, which brings a few liabilities of its own:

• The order desk ends up as a bottleneck for sales. Any time an account executive needs to help a client with mid-term changes, for example, they can’t move forward until the order desk has time.
• Concentrating CPQ knowledge within a dedicated team creates an “expertise sink” — as time goes on, that team becomes the only group that knows how the CPQ works, or how to fix issues.
• And, crucially, order desk job satisfaction tends to be low. Having the know-how doesn’t make an unwieldy CPQ any better to use.

__________________

How to address the issue effectively

The most effective way to solve adoption issues is to have a CPQ that actually meets the sales team’s needs. This typically will require a re-implementation with a different system, or (ideally) avoiding the problem in the first place by thoroughly preparing for the initial implementation. If sales reps complain during initial testing, you need to take that feedback seriously, because forcing reps to “get used to” a system they dislike is only going to make things worse over time.

"You need to take negative sales rep feedback seriously." 

You also need to plan out your CPQ for more than just your immediate problems — since it will take months to implement (at best), you need a solution for your company’s future state. If you aren’t comfortable making those predictions, then it’s likely best to implement a system that can handle all possible pricing models you might adopt.

__________________

If your company offers a single product, with a single price, sold once per year, CPQ and billing will likely work fine together. After all, there’s only one kind of message for the CPQ to send. But if your customer lifecycle is any more complex than that, and your quoting and billing systems have any kind of gap between them (which is inevitable if they aren’t handled by the same system), that gap is going to sink the chances of your CPQ working as intended. 

That’s because (as many companies have discovered the hard way) what legacy CPQs output is not what billing needs as an input. Bridging this gap demands time and effort while introducing a risk of error. And this risk is only intensified as companies add new forms of consumption, custom pricing capabilities, and other alterations. This is an especially significant concern for billing systems that handle product-led growth (typically Stripe), as they don’t integrate well with traditional CPQs.

When CPQ and billing are isolated, finance teams may discover that they can’t actually bill for what sales has quoted the customer. This (naturally) frustrates customers and takes confidence away from the sales team. Miscommunication between CPQ and billing can have a more severe and direct impact on the bottom line through revenue leakage, where the company fails to bill customers for some or all of the revenue it has actually sold.

"Disconnected CPQ and billing is a major cause of revenue leakage." 

__________________

Why the common workaround doesn’t work

The way companies deal with isolation between CPQ and billing largely depends on company size.

Small companies typically compensate with restricted integrations (in other words, limiting the CPQ to only what billing can accommodate), which cuts off a substantial amount of CPQ functionality. Large companies typically allocate staff to make manual adjustments as needed for CPQ and billing to work together. Some companies opt for a more elaborate workaround that changes the kind of data that CPQ can create to better align with billing, but this generally ends up being prohibitively complicated and expensive.

"Companies often compensate in ways that cut off substantial CPQ functionality." 

Despite the effort required for any of these options, none of them make mid-term changes any easier to handle, or allow you to fully safeguard against revenue leakage. And more importantly, they all force your go-to-market motion to stoop to the lowest common denominator.

If you can only adjust CPQ to the extent you can adjust billing, CROs end up shackled to what finance can do. And the result is a limit being imposed on revenue growth.

__________________

How to address the issue effectively

The most direct way to address isolation is to implement an end-to-end system that includes both CPQ and billing functionality for direct and product-led growth, as this makes it possible to close the gap between the two while easing the required management challenges. The other approach is to accept and work with the limitations of the disconnected or loosely connected systems that you have in place. This means designing pricing from the ground up with billing in mind, and/or staffing your team with enough people to smooth over the disconnect (which can be expensive at scale).

__________________

Legacy CPQ systems (like Salesforce CPQ) were designed for a different set of business problems, from an era before multi-channel land-and-expand sales motions and usage-based pricing models became so common. The only way to make legacy systems solve modern needs is to add complex and opaque pricing rules — which are hard to create and even harder to change and maintain.

As a result, only experts can implement or improve this kind of customized CPQ, which creates a bottleneck for a process that by nature needs to happen as quickly as possible. Business users don’t understand the underlying logic fueling these custom rules, don’t try to make any changes, and instead work around the system in ways that may produce unexpected results.

"When experts are the only ones who can implement or improve a customized CPQ, this creates a bottleneck." 

If no one is comfortable updating the system, then the CPQ can’t adapt to changing times and needs. And even setting that aside, a tangle of obtuse rules can lead to errors and reduce accountability. It’s very hard for finance to verify revenue flow is fully accurate, and customers don’t get transparency into how their costs are being handled.

__________________

Why the common workaround doesn’t work

Attempting to remove complex rules after-the-fact is typically impossible, so there’s no real workaround. That said, some companies choose to side-step the issue by limiting the complexity of the system as they put it in place.

Unfortunately, excessive simplicity causes many of the same problems as excessive complexity. For example, when sales reps don’t have the ability to customize discounts, the only possible workarounds (such as billing a 10-month subscription as a discounted 12-month subscription) can directly lower ARR.

"Excessive simplicity causes many of the same problems as excessive complexity." 

__________________

How to address the issue effectively

Once you’ve established a complex set of rules for your CPQ, it will be very difficult to change them in a coordinated and predictable way. If your business is relatively stable in terms of your sales motions and pricing models, you should make the effort to avoid complication by simplifying pricing where possible and thinking through every use case. If, on the other hand, your business model is likely to grow and change, you’ll need to implement (or re-implement) a CPQ designed to enable rapid changes and testing.

__________________

Introducing new pricing options through a legacy CPQ requires regression testing. And it’s hard to justify doing it when creating a new SKU is a faster and simpler option. But over time, an explosion of SKUs can be an organization’s downfall. 

SKU proliferation is a real problem in modern SaaS, with SKUs becoming so granular as to be specific to individual pricing tiers and even specific customers. In extreme cases a dedicated staff member needs to maintain SKU catalogs as a full-time job.

"In extreme cases a dedicated staff member needs to maintain SKU catalogs as a full-time job." 

Even so, there’s a risk that someone in the go-to-market motion may pick the wrong SKU and derail the quote-to-revenue process. Even if that doesn’t happen, having all of these SKUs complicates the RevRec process (for finance specifically), and causes challenges with data syncing (across the company).

__________________

Why the common workaround doesn’t work

Some companies do accept SKU proliferation as a fact of life. This requires staff across the go-to-market motion who are experienced with SKUs, not to mention exceptionally patient.

Only larger companies will typically have the bandwidth needed to ensure sufficiently experienced staff are present in sales, RevOps, and leadership teams to serve as stewards for the SKU catalog. In addition, the surplus of SKUs leads to exponentially complicated expansion and renewal motions, plus confusing data as customers switch from SKU to SKU through their lifecycle. 

.

"The surplus of SKUs leads to exponentially complicated expansion and renewal motions." 

__________________

How to address the issue effectively

Make sure that you have purchased the right type and version of CPQ for your needs, and are fully capitalizing on features like tiers and attribute-based pricing to minimize SKU proliferation. Trying to resolve SKU proliferation with a legacy CPQ entails the huge time-sink that SKU proliferation was intended to avoid. Recent innovations in the CPQ space have made it possible to flexibly configure pricing models at any scale without the need for new SKUs.

__________________

As you can see, once you’ve implemented a standalone legacy CPQ (like Salesforce CPQ), any possible workaround for CPQ failure is going to cause challenges of its own. That’s because legacy CPQs are designed for physical goods or complex service relationships — which was highly adaptive 10-15 years ago, but not great for the modern emphasis on land-and-expand in SaaS.

If you’re not in a position to take on a potentially counterproductive workaround, the way forward is instead to implement a new CPQ solution specifically built to handle the pressures placed on modern CPQ systems. 

.

"If you can't tackle workarounds, the way forward is to implement a new CPQ solution built to handle modern challenges."

As a leading revenue lifecycle platform, Nue has taken into account all of the ways CPQ implementations can fail, to create a solution that offers unprecedented reliability and flexibility for CPQ and billing across the entire market motion.

Nue addresses the most common causes of CPQ failure in several ways:

• Adoption: Nue maximizes the chance of sales rep adoption because it can handle all kinds of sales motions and pricing models — and it has an intuitive CPQ interface built from the ground up for sales reps (along with a billing interface built from the ground up for finance). 
• Isolation: Nue consolidates the CPQ and billing processes in a single solution with a 360-degree view of the customer. This eliminates the risk of CPQ failure via isolation while empowering RevOps to eliminate revenue leakage.
• Inflexibility and SKU Proliferation: Nue can natively accommodate any kind of pricing adjustment, mid-term change, or bundling strategy without the need for extensive regression testing or SKU proliferation.

Learn more about Nue’s quote-building capabilities, or see how other companies have leveraged Nue to avoid the challenges commonly associated with a CPQ system.