Blog 4: Implementing CPQ Software
Bas Könst has been selling Merkato CPQ software for over ten years now. He points out: “For a decade, we’ve continued to develop based on feedback from more than 150 clients and thousands of users. Naturally, we’re convinced of the quality of our software, but that’s just us tooting our own horn. However, I dare say that we offer one or multiple solutions for every sales-related challenge on a technical level. Yet, the success of Merkato hinges on its implementation, and unfortunately, that doesn’t always go smoothly. In this blog, I’ll dive into why implementations sometimes don’t proceed flawlessly. I’ll briefly touch on the technical aspects but mainly focus on the “soft factors” (those affecting company culture).”
The Designated Person
Let’s start at the beginning of the implementation process: with the employee designated to populate the configurator. An engineer who happens to be good with Excel often has little knowledge of the sales process. Naturally, this engineer views the project through an engineering lens, resulting in a technical configurator filled with technical queries about horsepower, axles, and bearings. We’ve observed that the functional questions that should arise in a sales conversation often don’t in this scenario. Issues can also arise with employees experienced in programming since setting up a good configurator has nothing to do with programming. Employees still thinking in databases and codes tend to complicate things unnecessarily or want to access the database or create routines – all things that are no longer necessary today.
Our ideal scenario involves collaborating with an employee who operates in the field between engineering and sales. Someone who understands how a customer thinks and how a sales conversation is conducted but also has a basic understanding of how the products are constructed. This person doesn’t need to have all this knowledge in-house – as long as they know where to find it within the organization. Many companies have created a specific role for this purpose: the product manager.
The product manager hears from marketing what the market needs while also having a connection with the technicians who must come up with solutions. Essentially, someone who can link the commercial BOM from my previous blog to the technical one. In my eyes, this is the ideal candidate for implementation.
Acceptance
The first challenge has been addressed, so onto the second. As mentioned, communication between the configurator, sales, and engineering is crucial. But even if this goes well, a lot can still go wrong. Acceptance and support, as well as commitment, may be lacking. Countless volumes have been written on this topic.
Here, too, the solution is quite simple: the implementation works best when the configurator is implemented as the only way of preparing quotes/orders. From now on, everything must go through the configurator: even custom quotes, “quick budget quotes,” quotes that seem similar to previous ones, and quotes for clients we’ve known for a long time.
Our configurator is more than just fancy quoting software. Merkato is a true gatekeeper ensuring no impossibilities are sold. It brings control and calm. That’s the goal, the reason we embarked on this project together. The configurator is the means to that end.
Unfamiliarity Sometimes Breeds Contempt
Some companies are wary of the arrival of a configurator unfamiliar to them. Unfamiliarity sometimes breeds contempt. We often see that the responsibility for setting up the configurator is placed on someone nervous about the idea of new software, who might not even welcome it. It’s therefore wise to appoint someone who is also convinced of the benefits, conveniences, and opportunities. The implementation process will then undoubtedly proceed much faster and with more enthusiasm.
When employees seem skeptical or even negative about the arrival of a configurator, it can help if someone with status or decision-making authority (also known as “the boss”) has the final say in the process. As mentioned, the responsibility for setting up the configurator is too often placed on someone who isn’t looking for change. The top-down message “We’re going to work with this, unless we find crucial flaws” is then misinterpreted as “Look for reasons not to work with this.” That’s what we call ‘discussing Christmas dinner with the turkey’.
Common pitfalls or even slight forms of resistance include searching for new, supposedly essential functions during the testing phase that were never previously discussed. Lack of flexibility can be fatal to the implementation. It’s therefore important to be aware of this and continue to communicate the benefits and possibilities. If our configurator improves 98 out of 100 processes, it’s a pity if the last two spoil everything.
Workflow Confusion
Often, the ‘old’ workflow is fairly simple: if a salesperson tries to sell outside the box, they must ask for permission from engineering. Not only is this method cumbersome, but it’s also incredibly prone to errors. Misestimating the costs for custom work or adjustments is the reason for margin loss. The second simplest workflow is if an employee wants to give more than a certain percentage or amount of discount, they must ask the boss for permission. In a Word or Excel-document, the discount can simply be adjusted as needed, and the rationale will follow later. Those days are over.
Unfortunately, we frequently encounter somewhat negatively charged questions from salespeople about whether the configurator limits their freedom. This is, of course, an interesting question. If freedom means behavior that doesn’t correspond with the goal (fast and error-free processes), then indeed, the configurator brings bad news.
But it’s not about the messenger. It’s about the message, the goal. If everyone supports it, the implementation is a celebration for the entire organization. Because every business rule means less chance of errors and less need for control. And that’s exactly why we do it: to help great companies with our amazing software.