From Catalog to CPQ: Quoting complex product configurations 

There has to be a defined path for them or the configurator will simply be bypassed. The usual pattern is a special-item route that captures the request, prices it provisionally and flags it for engineering review, keeping it inside the same quote rather than pushing it into an email. If the exception path is inconvenient, sales will quote specials outside the system entirely, and the quote data becomes unreliable.

Pricing drift, usually before anything else. Copies of the master sheet spread across laptops, each with a slightly different discount table or an out-of-date option price, and nobody can say which quote used which version. The compatibility errors come later and are more visible, but the pricing inconsistency does the quiet damage, because it shows up as margin erosion that is very hard to trace back to a cause.

Each revision needs to be a version rather than an overwrite, so it stays clear what was quoted, when, and at what price. The reason is not tidiness but disputes: customers reference the version they liked, which is rarely the last one sent. Version history also makes win and loss analysis possible, because you can see whether the deal was lost on the original configuration or on something changed halfway through.

Option definitions, compatibility rules and option-level pricing, in that order. Most implementations underestimate this because the product knowledge exists but has never been written down: it lives with two or three experienced people who have never had to state it as rules. Extracting it is the bulk of the project. The software is rarely the constraint.

Engineering owns what can be built, sales owns what may be sold, and those are different rule sets that are frequently confused. A valid combination that the business does not want to sell at that price is a commercial rule, not an engineering one. Keeping them separate matters because commercial rules change often and engineering rules rarely. Merging them produces a rule base only one person understands, and that person eventually leaves.

This is the question worth asking of any CPQ evaluation. If the configuration has to be re-keyed to create the order, you have automated the quote and left the error where it always was. The integration should carry the selected options through to the order and drive the bill of materials and routing from them. Ask specifically what happens on a revision, because that is where re-keying usually reappears.

When the number of valid combinations exceeds what a person can hold in their head, or when quoting requires checking whether options are compatible. A catalogue of fixed SKUs does not need CPQ. Products with options that constrain each other do, because the failure is not slow quoting but quoting something that cannot be built. If your sales team routinely asks engineering "can we actually make this", that is the threshold.

The ERP configurator exists to drive production: it generates the bill of materials and the routing once an order is real. A CPQ configurator exists to sell: it runs before the order exists, in front of a customer or a distributor, and it needs to be fast, forgiving and presentable. They overlap in rules but not in purpose, and the common mistake is expecting the production configurator to be usable by a salesperson on a call.

The benefit is real but different. A manufacturer is constrained by what can be built, so the rules protect production. A distributor is usually constrained by what can be sourced and at what cost, so the rules protect margin and lead time promises. A distributor quoting from several suppliers' catalogues has the harder data problem, because the source data is someone else's and changes without notice.

Contract pricing has to be applied at quote time, not corrected afterwards, because a quote sent at list price and later adjusted damages credibility with the customer. The complication in distribution is layered agreements: a contract price, a volume break, and a promotion that may or may not stack. Deciding the precedence order between them is a commercial decision that has to be made explicitly before it can be configured.