One of the hallmarks of business software these days is the need to take features farther. Many vendors seek to gain a competitive edge by adding features that are not core to the problems their solutions were designed to address. Often, these capabilities end up overlapping with other solutions. While this can be good at times – CRM’s efforts at providing marketing automation certainly had an effect in driving progress in dedicated marketing automation solutions, for example – it can also cause confusion and drive up costs while providing little reward.
Adding “extras” that don’t add anything for the customer has its advantages for vendors. It projects the image of a product that’s constantly seeking a technological edge, and it may tip the scales in a “feature bake-off,” although buyers increasingly recognize that the bake-off approach is a flawed methodology that frequently leads to the wrong choice.
CPQ is not immune from this, especially in an era where it’s gaining major traction outside its traditional markets. Gartner predicts that CPQ will see a 20 percent annual growth rate through 2020 – and vendors are eager to grab a piece of this expanding pie, often by lumping in features that are not core to CPQ.
If you’re looking at CPQ, there are some “table stakes” features you should focus on, some important-to-have features that may meet your specific needs, and an assortment of other features that are of dubious importance.
Let’s start with the must-haves. No company’s product mix stays the same for long, so it’s important that your solution can be configured easily by line of business workers, not by IT. Look for a solution with a configuration workflow that’s intuitive.
Next is pricing. If you sell through channels, your CPQ needs to be able to handle multi-tier pricing. You also need to be able to handle customer-specific pricing for deals with unique terms and conditions. Winning a deal based on special pricing should not result in CPQ becoming a more manual process each time you deal with that customer. And, once a deal is proposed, an automatic approval process driven by CPQ is critical to maintain the velocity of the sale and to ensure the deal stays within profitability parameters.
Any viable CPQ solution needs to help with guided selling by actively providing up-selling and cross-selling options. This is critical for companies with highly-configurable products or that depend on accessories to maximize the value of each deal.
Modern CPQ must be available to mobile users. It must provide a consistent branded look and feel to every quote. And it must connect to sales content repositories in order to immediately deliver the most appropriate and effective content for every deal.
Then there are some features which may be less apparent but which are no less vital for enterprise-level CPQ. First off, the application should enable the data collected in the system to be analyzed to reveal metrics that sales managers and product managers can use to improve the sales process and evaluate the product mix. Next, the solution should be able to handle large numbers of products in the cart, and deep levels of nested configurations, without suffering a degradation of performance. There’s no sense in using an automated system to save time if the solution’s inability to process data becomes the new bottleneck.
These are the basics. They need to be present in the solution, and they need to be well-developed.
Then there are some things that are turning up in CPQ solutions that provide a limited value and can distract from these basics.
Built on Force.com platform
Because CPQ complements CRM very well, many vendors build applications on Salesforce.com’s Force.com architecture. These “native” applications integrate neatly with Salesforce and spare users many of the integration expenses of non-native applications. But going native also has some limitations.
While CRM is data-intensive, CPQ is compute-intensive. CPQ relies on complex algorithms that re-compute configuration solutions in real time with every user click and also (in parallel) compute the pricing that goes with that configuration. At the same time, the CPQ solution may also generate a complex proposal, contract and bill of materials.
That requires a lot of computing power – and the Force.com environment is a shared computing system. That means many companies run their applications simultaneously from the same compute engine. To ensure that an application in the environment doesn’t use up too much computing power (and thereby negatively impact the performance of other applications), governor limits are imposed on each application in the environment. That can limit the performance of CPQ and somewhat negate the performance improvements that are CPQ’s reason for being.
As a result, most native CPQ applications are targeted at the SMB market.
To be as effective as possible, CPQ needs to have access to and be able to update virtually any data in the CRM system. But it’s not mandatory that a CPQ application be built on a CRM vendor’s platform for it to be tightly integrated.
For deeper integration between CPQ and CRM systems, look for services from enterprise-grade CPQ vendors. All of them are adept at this. But don’t stop with CRM. As CPQ systems continue to evolve, integration with other applications in the lead to money process are becoming more important. Integration with commission calculation systems, motivation systems, learning systems, contract management systems, and coaching systems will continue to drive additional value to CPQ users.
Integration with Price Optimization
Price optimization analyzes large data sets to predict the behavior of potential buyers in response to different prices. Companies use price optimization models to determine pricing structures for initial pricing, promotional pricing, and discount pricing.
Price optimization uses calculations to visualize how demand varies at different price points and combines that data with cost and inventory levels to develop a profitable price point for that product or service. This model is also used to evaluate pricing for different customer segments by simulating how targeted customers will respond to price changes with data-driven scenarios.
All of this seems very useful for sellers – and it is. But its place is not within CPQ for three key reasons.
First off, price optimization works best when you’re selling commodity items. That covers everything from raw materials to airline tickets to hotel rooms. These are items that don’t typically have a great deal of complexity, meaning that your product mix isn’t particularly complex – which negates the purpose of having CPQ in the first place.
Second, if you have a complex mix of products, it means you’re going to have a very diverse and varied set of data about sales. Your deals are likely to vary dramatically in product mix and pricing, which will create a unique and useful data set – but one that isn’t particularly useful in price optimization since you won’t have enough data about identical or nearly identical deals on which to base predictions.
Third, the analytics used in price optimization represent a powerful investment in terms of money, talent, and time. We’re also in the midst of an analytics revolution. The extra money you spend on a CPQ solution with predictive analytics may yield modest improvement in results while also forcing you to stick with an analytics engine that becomes rapidly obsolete.
The usefulness of offline support is dependent on how the vendor describes it. If it’s described as the ability to enter proposal data into forms while disconnected from the internet, it makes sense as a feature. If the idea is that full-fledged CPQ will work offline, it does not. That would require the vendor to cram the entirety of the application and the associated databases onto a device, which would tax the abilities of most laptops today. Since CPQ data is stored in the cloud, working entirely offline makes little sense; it’s far better to allow salespeople to input data for syncing when they can reconnect.