CPQ fundamentals: Your big three building blocks

In my last CPQ fundamentals post I talked about selecting the right team for implementing CPQ.  With your dream team in place, it's time to dive into the core functionality of CPQ. But where do you start? Within Salesforce CPQ, there are 8 domains: product catalog, configuration rules and constraints, pricing models, guided selling, renewals and amendments, order management, quote templates, and approvals. The first three are your big three domains and should be tackled in order.

Product catalog

The most important piece of CPQ is understanding how your product catalog is structured. Without this fundamental basis, it’s not possible to build or understand how these products will work together as pieces of the “C” of CPQ: Configuration.

‍Your product catalog is the most important and fundamental part of your implementation.

‍Product Catalog will be the first input to the entire CPQ process. This is where you can set up products to act as subscriptions, which will define not only if they can be renewed, but how their prices will be prorated for multi-year, or partial term quotes. This is where you determine if variations of a product are truly different items, or things that can be described and priced by attributes like color, size, regional variations, etc. You embarked on your CPQ journey to transform your business, so take the time to consider how to make your product catalog easier, rather than recreating existing processes and structures.

Oftentimes CPQ can simplify and dramatically change how your products are modeled. This is your opportunity to start fresh and simplify your product catalog. The end goal is to improve both the end user and customer experience by making it easier to select products for quoting and ultimately present them to prospects. I’ve seen customers reduce their Product Catalog from 140,000 SKUs to 35 Product records in CPQ.

Considerations for your product catalog

• How can you simplify your product catalog with new CPQ functionality?
• What legacy SKUs are truly different products that need to be created in CPQ?
• What legacy SKUs are ways of describing your product that can be achieved with product attributes (e.g. color, size, regional variations)?
• What legacy SKUs were created to accommodate different pricing that can be automated with pricing and discount rules?
• Is there a valid reason for maintaining a process from the legacy system or is it just the way it’s always been done?

Basically, if you have multiple SKUs that all result in the customer receiving the same product and service, consider consolidating them.

Configuration rules and constraints (aka bundles)

In regards to CPQ, “bundle” is a loaded word. Everyone has their own idea of what this is before they actually ever see them. DELETE THIS TERM FROM YOUR CPQ VOCABULARY! Instead, speak about “product families”, “configurable products”, “attribute-based products”, or “suggested/required add-ons”.

Bundles are not single sets of products sold for a single price. They are used to configure and ensure the technical validity of any products or combinations of products your company will be selling. If you do use the word “bundle,” be sure to add “design” to the end of that. Bundle design is how your sales team will present products to the market. This is their tool for presenting multiple options to customers who value/need different things in regards to your products.

Consider the salesperson experience when using these product bundle designs. Your sales team needs to be able to pull quotes together quickly, easily, error-free, and with all the correct suggested items for the ultimate customer solution. These need to be concise and direct to give your sales team exactly what they need to meet your company’s business objectives.

Considerations for configuration rules and constraints

• How do products work together to provide customer solutions?
• What products are dependent on others (i.e. required add-ons) to function properly for customers?
• Can we make upselling easier by suggesting add-ons?
• Are there any products that should not be sold with other products?
• Does the list of options require more than 2 scrolls? If so, how can we simplify the bundle design?

Pricing Strategy

Now that your products are correctly configured for a quote, it’s time to give them prices. There are a lot of easy, out of the box price setting capabilities within Salesforce CPQ that can work to set margin based pricing, customer specific pricing, tiered pricing, and many other standard strategies.

It’s important to think about how you will set your starting prices and how you may or may not allow discretionary discounts. When you automate your prices, this will be the first price that your sales reps are given to lead with to their customers.

The basic catalog and bundle design can impart a lot of good pricing data, but may not be the end-all-be-all for your company. Where you can consider the “C” of CPQ to be the technical validation of a quote, the “P” can be considered the commercial validation of a quote. It’s best to start working on adjustments to the pricing after you get a good start of it with your simplified Product Catalog.

Considerations for pricing strategy

• Do you offer tiered pricing or volume-based discounts?
• Are there customer-specific pricing requirements?
• What is the starting price for our product and what is the greatest discount permitted without approval?
• Are legacy pricing strategies only being used to avoid problems due to lack of a tool?
• Are there rules that can be eliminated now that a system is in place to correctly calculate, prorate, and co-term prices?

Your Product Catalog and Configuration Rules are key items to implementing your pricing structure, and together these three domains form the foundation of your CPQ project. I'll discuss the remaining 5 domains in a future CPQ Fundamentals post, but if you simply can't wait, check out our Salesforce CPQ Gotchas and Best Practices webinar.