Salesforce CPQ Bundle Recomposition

Salesforce CPQ

Briefing: Configurable Bundle Replacing Pre-Configured SKUs
Business requirement

Situation today

We maintain a catalogue of pre-configured SKUs in Salesforce CPQ. Each represents a fixed, engineering-defined variant. When a sales rep selects one, the configurator only offers the options bound to that specific SKU. The option set is a subset, not the full portfolio.

Problem

Reps cannot deviate from a standard variant without abandoning it and starting over from a different product. Any customer requirement that sits between two pre-configured variants either produces a manual workaround outside CPQ, or triggers a request to engineering to release a new SKU. The catalogue grows with every edge case, and quoting time increases rather than decreases.

Target behaviour

A rep starts from a familiar standard variant — the same names and codes they use today — and, from that starting point, sees the complete option set and can change anything: add, remove, or adjust quantities. The standard variant becomes a starting point, not a cage.

Business outcomes we expect

Fewer new SKU release requests to engineering Shorter quote lead time for non-standard requirements Smaller, cleaner product master to maintain across Salesforce and JDE Visibility into how often reps deviate from standards — direct input for pruning the catalogue.

Technical requirement

Chosen direction

Replace the pre-configured SKUs as structures with one generic configurable bundle carrying the full option set. The former SKU becomes a preset that pre-selects options inside that bundle. No copying of configuration between two bundles at runtime.