They say it can take a product idea ten years from concept to mass-market appeal but that might be only an optimist’s viewpoint. Some of the best ideas in CRM right now have been marinating for at least that long and for some, much longer. Two great examples are analytics and CPQ that companies like Oracle and Salesforce and others have embraced with passion. Interestingly, each technology has traversed a path that needed other technologies to become fully mature.
Analytics—and by this we mean business intelligence, data mining—an old term for what we now call machine learning—and big data needed a lot of hardware improvements to make itself prominent. For example, way back in the 1990s Kendall Square in Cambridge, MA, next door to MIT, became known as AI Alley for all of the startups there that were going to enable us to know customers’ minds before they did. Those pioneering companies are mostly gone now but their ideas generated big R&D throughout the tech sector.
One of the major drawbacks of any kind of advanced analysis is the need for processing power on specific data. To do that you need fast CPUs but also, your data can’t be static and sitting on a disk. So the AI movement influenced not only speedups for CPUs such as multi-processors and federated computing but also in-memory databases and very dense memory.
So of course it took twenty years to make all this happen but today we’re reaping the benefits of all that investment and research. Now we really do have the ability to probabilistically know what customers in the aggregate will think and we can act by putting next best action suggestions on a smartphone. That’s pretty cool.
Analytics have come a long way but the ultimate benefit will likely be felt in the IoT as machines increasingly communicate with machines with rich data streams that have to be monitored for exceptions.
CPQ or configure, price, quote software is even more of a now or in the moment idea. It was once a standalone category that could be grafted on to SFA for companies that needed it. But every company needs CPQ and without it many are reduced to relying on spreadsheet apps that often collapse under their own weight.
Consider the spreadsheets involved in proto-CPQ. We all developed spreadsheets in-house to deal with needs not addressed elsewhere for the product catalog including prices and descriptions. Businesses also needed a spreadsheet for each deal, which would be updated multiple times within a sales process. Quarterly updates to the product spreadsheet and random updates to quotes invited all kinds of problems.
Sales reps are known for their ability to seek out the shortest distance to close and we love them for it. But often the path went through using old quotes modified for new deals that often used old product catalogs and price lists and possibly the wrong discounting. In this scenario, management has to patrol every bid, every deal, and that’s getting to be hard to do. Management would rather be promoting the new product line with new pricing and other things that add greater value.
There’s also the issue of turning the catalog lose on a website so that customers can configure their own solutions. But you can’t begin to do this unless you can build business rules into the process such as Product A is always sold with 2-Product B’s or 1-Product C plus services. Other forms of front office automation, like SFA, make it possible for reps to handle increasing territory responsibilities. This decreases the number of reps needed but leaves their managers with the same amount of work reviewing manually created quotes. The front office strategy today is to manage the exceptions—SFA with analytics and good reporting makes managing the territory easy. But spreadsheet-based CPQ is not a good fit for analytics so CPQ becomes the weak link in an otherwise improved sales process. Spreadsheet CPQ is impossible to manage by exception leading to slow turnaround on quotes and lost deals. To manage quotes by exception, the same as you manage a territory, you need a CPQ system.
Not surprisingly, this is where analytics and CPQ cross paths. Analytics tools are great at finding the exceptions based on the business rules we set up. Rather than a manager scanning all deals or offers, a rules and analytics based CPQ system can simply flag outliers such as overly generous discounts or incorrect pricing. There might be legitimate reasons for the exceptions but there should also be easy ways to find and deal with them without having to sift through the majority of plain vanilla deals too.
More than just saving labor or improving accuracy, a business that can more easily pivot on a customer’s quotation request and do it first, is in a better position to win. It’s a form of business agility, an idea much in the news today. Agility is supposed to be about flexibility and the capability to change and evolve rapidly to meet market demands accurately without incurring a great deal of overhead. Business agility is important because, while it might be possible to manually respond to a single special need, it’s not a good idea to base a business model on it. Specifically, responding to special needs—good! Doing it manually over the long run—not so much.
Last point, if business agility is important to your business then software agility ought to be important too. This means, where possible, using solutions built on the same platform so that they use the same objects and data naturally, without having to rely on massive integrations. In my experience, many point solution integrations take a toll on IT that should be avoided if you expect to maximize your business’ agility.
CPQ and analytics have come a long way over decades to provide us with some of the needed components of a truly agile business approach today. Spreadsheets have barely changed. In a more competitive world it makes great sense to ensure that every part of your key business processes (there’s nothing more core than sales) is supported by a system, not a spreadsheet, and the best way to do this is with platform based components like CPQ.
(Cross-posted @ Beagle Research Group)