Imagine this: you’ve worked hard to finally be able to afford your dream custom road bicycle. You placed a custom order six months ago with a salesperson you trust.
The day has finally arrived. It’s New Bike Day! Everything is on track so far.
Arriving at the bike shop with anticipation, you ask to see the bike. Suddenly things get awkward and the salesperson looks at the sales manager and back at you.
There’s a slight problem, he says. These outfitting customizations that you had requested didn’t fit your bike. We weren’t able to do what you wanted. But look! It’s gorgeous. Don’t you see how this is better than what you wanted, if you really think about it? We went ahead and used a standard customization package. Take a look! I know it’s not what you ordered, but does it really matter? 9/10 customers say they prefer this package, so it should be all you want and need.
You’ve already paid for this bike and waited months for this moment. What do you do?
CPQ implementation project failure
Here I have provided a meta example of CPQ not being able to handle complex product and pricing configurations. First of all, the salesperson’s CPQ product failed his shop, failed him, and failed you, the customer. This is wheelie unfortunate.
Let’s go another layer deeper. Did you catch it? The custom road bike as an analogy could be replaced with the instance of a CPQ implementation. Your company has been sold a CPQ product that is supposed to meet all of your complex product and pricing structures. You’ve planned out the implementation with your systems integrator, but deployment is messy. It’s been 9 months… or two years… and the CPQ product your company was told would make your sales quoting process more efficient is nowhere to be found. Is it the fault of the system integration team? Or…could it be a CPQ that is not performant?
Not only have you NOT seen an ROI since you deployed your new CPQ application—assuming you were actually able to deploy, the CPQ has not brought the desired results to your sales and quoting process. To bring this meta analogy full circle: it’s not been an easy ride, it’s an 18% grade climb. Or worse yet, the implementation ‘failed’ and your bike simply broke. These new handlebars aren’t helping you get a grip.
Now enters the question of sunk costs: if it’s still operational, do you try to keep riding anyway? Easier to say than do; the hardest thing about trying to ride a broken bike is the road. Road rash, anyone?
Or, do you order another bike, one with all the customizations you needed in the first place?
Veloce CPQ: built as a solution for the most complex enterprises
I’ve been in the CPQ space for the last 10 years and have had the fortune of being part of numerous functional teams. I’ve been on the team that builds the CPQ application. I’ve sold CPQ and I’ve implemented it as well. Based on my experience, a company that needs a CPQ application is experiencing sales growth and needs the benefits a tool like CPQ provides. These are companies that have a proven track record of selling their products and running their sales team. They buy a CPQ tool to support, streamline, and enhance their proven business.
It all sounds great, until they try to implement the CPQ and discover that many of the most complex pricing scenarios are not able to be configured properly. In many of these instances, they are told that they need to change their business to fit the ‘CPQ process’.
A CPQ tool should meet your business needs
Being told your company’s pricing structure is too complex, or that your business needs to change some of its sales and quoting processes is a red flag that the CPQ you are working with will not be able to meet your business needs.
If you’ve been told your business will need to change to fit the CPQ tool, find a CPQ tool that will fit your business process instead. Veloce was developed from the very beginning for the most complex use cases. Book a conversation with our sales team today.
