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.

Project ID: 40644850