I read somewhere that an average person in our time makes over 10.000 decisions a day. Most of them are micro decisions, such as whether you should have sugar in your coffee or not, which milk you should choose in the grocery store, whether you should wash your car today or later this weekend, or which TV-channel to watch. They may not be important decisions, but they add up.
Not only do we have our own set of issues to consider. Our commercial surrounding pushes decisions our way and asks us questions all the time. Have you, for example, ever wondered why there sometimes are chocolate bars by the magazine stand in the super market? Because you already made the decision to stand strong and avoid the isle with all the sweets – and now you have to decide again! Sooner or later, we all cave in and make a quick decision that may not be the best one.
The reason I bring this up with you is because your customers make several decisions (both big and small) when they consider the customization of your product. The decision you make when you choose a CPQ-solution will have millions of implications in terms of every choice your customers will make using your application, and how they feel about it. So, if I can give you only one advice, it would be:
Learn the difference between imperative and declarative rule engines.
The difference will definitely affect how your customers feel about customizing your product.
Imperative rules engine – sequential questions
I know, “imperative” and “declarative” are not the easiest words in the dictionary. So let me explain what they really mean. An imperative rules engine is a CPQ-solution that funnels the user through your application using a set of sequential questions, which means each question subsequently filters the next questions and answers available. You encounter this functionality everyday in very simple “configurators” and it may, or may not, be a source of frustration. Imperative rule engines are common, easy to create and usually cheap. However, you can find them in “advanced” CPQ solutions as well, and this is where you need to be aware.
A simple example of an imperative rules engine is a purchase of a customizable computer in an online shop, like Apple.com. You start by selecting a computer type, which is followed by a question about screen size you can choose for that computer. This question is in turn followed by a question on the size of hard drive you want, and so on. Each answer funnels and limits the amount of answers you have available for the subsequent questions. A problem arises if you, for example, want to have the fastest processor available on the market – an option towards the end of the configuration. If that configuration is not available based on your previous choices, the configurator will force you to start all over again.
Having to start all over again is a very common side effect of an imperative rules engine, but it is of course something we all hate doing! You invest time in your selections and you do not want to wait, or worse – eradicate, all that work when you realize an important feature is not available for who knows what reason!
The more decisions you need to make to purchase the product, the more time invested will be lost if you have to start all over again. I.e. the more options you have, the more time and effort is at stake. On the other hand, for simple solutions like booking a flight ticket where the time invested is not as much, you get a good trade-off between functionality and price with an imperative rules engine.
Declarative rules engine – choose whichever option, whenever
A declarative rules engine, on the other hand, is a more intelligent CPQ solution. It cannot typically be made in-house but rather needs to be purchased externally. A declarative rules engine always consider all data at all times. You create rules (sometimes referred to as constraints) that “cut” through the data and limits the selection no matter where you start.
Using the same example of a customizable computer, let’s say you are a photographer. You carry your computer with you at all times and the most important feature for you is that it is light weight, with a maximum weight of 1.5kg. Additionally, it should be fast enough to run Photoshop. You may not care about the brand, screen size, memory or anything, you just want your most important features included, and you want to find a computer that meets that need. If you decide you want a MacBook Pro, on top of that, the declarative rules engine will let you know which trade-off you face: “You cannot select a MacbookPro because it is heavier than the maximum weight option you selected.”. Then it is up to you to make an informed decision.
Which rules engine should you choose?
The computer example is of course a simple example for educational reasons. As a trade-off between price and functionality an imperative rules engine may actually be a better option for a simple computer configuration issue like this one.
If you are not just looking for a solution to a simple problem, however, you really should be looking into a declarative rules engine for your CPQ solution. The reason is that your customers will be making decisions you may not be able to foresee and in an order that does not follow the same “logical” path your engineers have created. We are all used to make decisions based on our own preferences and we all frown when a computer tells us: “This option is not available”, without letting you know why or what you need to do to make it available. The more complex your product configuration is, the more time it takes to configure it. And the more exceptions you have, the more you should consider a declarative rules based configurator. With products like this it also probably means your customers are more important and invest more money in your products. These are not customers you want to hand a ”Option not available” message to!
So, if you can take the time and effort to make an informed decision about a CPQ-solution that really helps and guides your customers, you are helping them in their everyday decision process. Hopefully you can reduce a good portion of the 10.000 decisions they make every day. The result is likely to be less frustration among your customers, and fewer calls to your customer support.