All too common story: you buy a CPQ system from a leading vendor but your implementation ends up largely custom code. We’ve seen implementations where the CPQ product is barely used and 60-90% of the solution is custom code. You start to wonder why you bothered with a vendor when you could have used your IT team to create a custom application that solves your problem - without all the hassle of learning - not to mention paying for - a vendor technology.
And let’s state this clearly: going outside the product with custom code is a very bad practice and something Veloce will never do.
In case you’re wondering why custom code is a problem let’s point out a few of the important problems custom code creates. Custom code is uncontrolled versus standard product code. Most likely it was written by a 3rd party like a systems integrator or by a contractor working for the systems integrator. After project completion whomever wrote that code is long gone. There is little accountability when the code must be updated later. And it’s highly likely this type of code will have to be updated in the future. Why? Because it was done without knowledge of how the vendor technology will evolve over time.
Your custom code is - by definition - out of sync with your vendor code. This makes vendor upgrades problematic and at best unpredictable. Upgrades are supposed to deliver improvements. But when your deployment is full of ex-product customizations, upgrades to the product can break your application, often requiring excruciating and expensive mini-projects off their own to align your customizations to the upgraded product. Again, it begs the question why you bothered with a vendor system in the first place.
In problematic CPQ implementations we’ve seen, custom code is frequently the leading culprit for major performance problems. In one CPQ implementation in particular, the custom code written to handle pricing functionality caused the application to take over 1 minute to run pricing. The CPQ application end user has to wait a full minute before prices appear on the screen. And this is for a company selling around 10 products (!). Honestly, this company would have been much better off writing their own custom application than buying that CPQ system.
Custom code may solve an immediate problem but it creates much bigger problems for future maintenance. Since it is by definition outside the product codebase, it will naturally be out of sync with whatever happens with the product. And just as products require regular updates, custom code requires care and updates as the application changes over time. But in the case of custom code there is no product team taking care of it. And as mentioned before, the author will generally no longer be around to make these changes. In fact, it’s highly probable there will be no one with even familiarity with this code.
Truth is, custom code reveals weakness in the product design. And it is typically done to make something work today but is not designed with the future in mind. At Veloce, we have seen actual CPQ deployments with leading vendor technologies for major companies where implementation teams have “hardcoded” custom user interfaces and even pricing logic with product information (literally SKUs are written inside the code). The customer actually has to pay someone to update the code to add new products to their CPQ tool. Frankly, it makes us sad to see CPQ botched to this level.
The very first step in avoiding custom code is to avoid the need for customization in the first place.
If you have been following this series, in our last post we showed how our solution does not require customization to solve a very complex configuration problem that would be very difficult or impossible for leading CPQ technologies to handle. If you missed that last post, need a refresher, or simply love reading about elegant CPQ solutions it’s here.
As illustrated in our last post, we believe our core configurator can handle virtually any configuration problem without customization.
We have incorporated every configurator technology approach from Solver to simple rules validation in our engine capability set. We understand there are multiple ways to solve product configuration problems so we offer the option to use just the right technology for the right problem.
A second reason we can solve most problems without customization is the expressiveness of our product model. Veloce product model is generic, infinitely flexible, and thus allows for the definition of any logical or mathematical expression. This is different from many vendors who only support a limited set of rule types.
The power of our Solver to find solutions on its own without explicit instructions plus the exhaustive expressiveness of our product model means we can solve any CPQ problem without having to resort to custom code.
With that said, we know from over 20 years experience that CPQ in the real world runs into requirements vendors never thought of. So no matter how good the vendor platform is, there will be times when customization is required. This is in part due to the nature of rule and constraint modeling. Some problems lend themselves much better to a simple procedure. We don’t want to force implementation teams into creating a convoluted set of rules when a simple procedure is the best solution.
Knowing that, we have created hooks to extend our system within our framework that are controlled and work within our engine or UI. Our built-in ability to customize our solution is very different from uncontrolled custom code frequently used to augment the capability of leading CPQ systems.
We offer tools to customize your application in all three key elements of your application: 1. User Experience, 2. Product model (the logical model of how your products are configured), 3. Pricing.
User Experience customization: Veloce has a User Experience Design Tool that allows your team to quickly deploy a template-based UI. We have a step by step wizard to create your template UI. That template UI is organized into UI components that your UX team can modify or extend with standard web development protocols: HTML, CSS, JS and AngularJS. With our UX Design Tool your UX team can create any user experience they want.
This is very different from what leading CPQ vendors offer. The market leaders provide a single auto-generated user interface that is coupled one-to-one with their product data in Salesforce. That means, if they need to provide any sort of customized view, the implementation team needs to create a custom visualforce page in Salesforce. There’s no other way to do it.
Once you step outside the product with such custom pages anything can happen. In our experience, we have seen multi-million dollar CPQ implementations suffer this fate. Customers go live with a custom page which solves the immediate problem. But later the customer finds out that any modification to their product structure requires changing the code to their custom page. Nightmare scenario for system maintenance.
At Veloce, we thought about the need for customized views and customized user experience flows from the get go. From day one we created a clean separation between our product data and user interface. This means you can create any number of UX templates and use them to create different user experiences for any number of sales channels. In this way, we support any sort of user experience customization within our product, because our product is designed for this very common need.
Product model customization: for problems that require custom configuration logic Veloce has a built-in method: the custom constraint with custom goal. Our framework allows your development team to define a custom constraint with custom goal as an extension of the standard set of constraints available for use in the model.
For most deployments this will never be required. However, when it is needed, we allow your team to extend our engine within our framework. We also offer support services to ensure your custom constraint adheres to our standards for efficiency and even check if custom constraint is the best solution for your problem.
Pricing customization: Veloce Pricer supports all standard pricing methods required to solve your pricing problems: ie. simple rules, complex rules, volume tiers, usage tiers, and even ARR calculation. All out of the box.
However, for custom pricing logic we offer a built-in method to create custom pricing procedure that is similar to the custom constraint with custom goal available for configuration logic.
With these built-in mechanisms we offer out of the box to extend Veloce, your implementation with Veloce will never have to rely on custom code outside the product. Let us repeat. Never.
We provide these mechanisms within the product because we are aware that they are often needed to achieve advanced customer requirements. And we are highly aware of the multitude of problems CPQ deployments can run into if they go outside the product. These built-in customization hooks ensure everything in your application stays within the bounds of our product. This has huge benefits for the long term health and maintenance of your CPQ solution. For example, your application will not break during an upgrade of Veloce.
And in nearly all cases, due to the richness of Veloce’s advanced configurator and pricer functionality, the only customization you will need with Veloce is in the area of user experience. To that end we provide a full toolset to support this in our User Experience Design tool. Leading CPQ vendors do not provide such a capability. And unfortunately for their customers, this is one of the leading reasons they end up going outside the product in the first place.
Salesforce CPQ is a very popular CPQ solution on the salesforce platform and there are a lot of happy customers using Salesforce CPQ. Just like any software solution, there are always some corner cases and limitations that are beyond the reach of Salesforce CPQ.
I have been in the CPQ space for the last 20 years. Starting in product development, I was involved in developing two market leading configuration engines. One at Trilogy, a CPQ pioneer, and the other was at Siebel. They are very powerful engines and are still in use to this day.