Standardising doesn't mean every exception disappears.
That's a misconception I see often in CPQ projects. As if the end goal is: as little customisation as possible. But there's a big difference between two types of customisation.
One type creeps in unnoticed. An exception here, a special request there, all to close a deal. Nobody ever decided this should be part of the offering — it's just there, because at some point it was easier to say yes than no.
The other type of customisation is deliberate. It's a part of your product that you have consciously decided to offer, precisely because it's special. Because it solves a problem that a standard product doesn't, or doesn't yet, solve. And because the customer experiences it that way too — and is willing to pay for it.
"The first strengthens your proposition. The second mostly just costs you time."
That second type of customisation isn't a problem. In fact, it can be commercially very valuable — as long as it's completely clear why it's special, and why a standard solution won't do here.
The problem only arises when you let these two types blend together. When unnoticed customisation gets just as much room in your configurator as the deliberate kind. Then you lose overview, time, and ultimately margin — without your customer getting anything extra in return.
The question I often ask companies, then, isn't: how do we prevent customisation? It's: which customisation was deliberately chosen, and which crept in unnoticed?
How do you make that distinction — or does it blur together in your organisation too?