News & Resources — News Announcements

Key Considerations for Salesforce CPQ MDQ Implementations

Posted by Renee Kelliher, Senior Consultant

What Is MDQ?

Multi-Dimensional Quoting (MDQ) provides additional functionality around subscription products to allow flexibility when selling products over a fixed term. Typically, subscription-based products are sold at a fixed quantity and price for the duration of the quote term so a change to the quantity or price is seen across the entire term. With MDQ, the subscription term is segmented, allowing the salesperson to adjust the quantity or price of each individual segment.

MDQ Overview

Products can be configured to use segment lengths of years, quarters or months. Alternatively, products may be configured to allow user-defined segment lengths. Along with time-based segments, MDQ products may also include one-time prices, such as activation fees.

When MDQ products are added to a quote, a quote line item record is created for each product and segment combination.  The below screenshot represents how MDQ monthly segmented products would appear as separate line items.

top-considerations-for-mdq-renee-1

Common MDQ Use Cases

MDQ is used when there is a need to sell products over a period of time with individual characteristics for each time frame.

Here are some common use cases for MDQ:

  • Multi-year deals with the ability to ramp up quantities

Ex.: You sell a 3-year deal in which the client plans to increase the number of products purchased each year. A ramp up quantity scenario may look similar to this:

Year 1 = 100 units @ a price of $200.00 each

Year 2 = 200 units @ a price of $200.00 each

Year 3 = 300 units @ a price of $200.00 each

  • Multi-year deal with the ability to adjust pricing for each time segment. *Note that this is common practice to account for an increase in price for subsequent years.

Ex.: You sell a 3-year deal. The quantity of the subscription product is estimated to be the same each year. Your company has a standard price increase of 5% each year. Therefore, you need to adjust the unit price for years 2 & 3 such as in this scenario:

Year 1 = 1,000 units @ $200.00 each

Year 2 = 1,000 units @ $210.00 each

Year 3 = 1,000 units @ $220.50 each

In the above examples, only the quantity or the price varied for each year. With MDQ, it is possible to vary multiple characteristics such as quantity and price for each segment.

Key Considerations for MDQ

Plan your Bundles Strategy

The use of bundles, features and options is greatly impacted by MDQ. Any Product that is an MDQ product (i.e., contains a segment) can be a child but cannot be a parent in a bundle. This impacts how bundles are used in instances where MDQ is implemented. When planning an MDQ implementation and using bundles, keeping these tips in mind will help you avoid some of the pitfalls.

  •     Do not utilize nested bundles when the middle product is an MDQ product.
  •     Do not utilize bundles when the parent product is an MDQ product.
  •     Utilize bundles with 1 level vs. nested bundles for MDQ products.
  •     Utilize product rules vs. product options for enforcing configuration dependencies and constraints.
  •     Consider whether multiple products for the same sku are needed.

Consider Product Rules vs. Bundles and Constraint Options

In Salesforce CPQ implementations where MDQ is not used, features, options and option constraints (all part of bundles functionality) are utilized to enforce product dependencies and constraints. With implementations that include MDQ, there is a possibility that other functionality in addition to bundles will need to be leveraged to enforce product dependencies and constraints.

  • To enforce product dependencies, replace the use of nested bundles with product rules.  Ex., Use case: When Product A is added, Product B is required.  This use case can be solved with bundles and option constraints. However, if both Product A and Product B are MDQ products, then a bundle should not be used. Instead, use a product rule to add Product B automatically when Product A is added.
  • Product Validation rules can be used in place of nested bundles to support Option constraints.  Ex., Use case: When sales reps sell Product C (a lap top), they should always select a power cord. They can select either Product D (US power cord) or Product E (International power cord). However, they cannot select both D and E.

To support this use case, you could build:

  • Product validation rule that prevents users from selecting both Product D and E on the same quote
  • Product Alert rule that notifies the rep when they try to save a quote record that contains Product C but does not contain either Products D or E.

Careful Consideration of Product Settings

One of the key benefits of MDQ is the ability to quote multiple segments (such as multiple years) with independent qualities for each segment.  In order to support this functionality, products may need different settings than non-MDQ products. In preparing for an MDQ implementation, it is critical to understand use cases around product for the first year as well as subsequent years.

Some key use cases to consider are:

  • Can the product be only on the first segment but not on others?
  • Can a product be on any subsequent segment but not on the first segment?
  • Can products be added mid-term?
  • Can a client cancel or reduce the quantity of subscription products once the contract is signed

Aggregates and Summaries with MDQ Products

Careful consideration must be given when planning and designing configuration strategies that utilize Aggregates or Summaries with MDQ products. In other words, you must consider whether the summary or aggregate should be across all segments (Ex., for all 3 years) or for individual segments.  In some cases natively, Salesforce CPQ calculates based on the total contract which may cause an artificial inflation of the quantity count or $ amount needed.

When planning an MDQ implementation, keep these considerations in mind:

  • You may need to utilize rollup summary fields or summary variables to aggregate data by the segment (each year of a multi-year contract).
  • When writing price rules that take some action based on a sum of a quantity field or $ amount field, separate price rules (and summary variables) may be needed for each segment. This is dependent on if the intent of the summary should be based on just one segment or all segments combined.
  • Be aware that discount schedules with Aggregation Scope set to “Quote” or “Group” will cause all segment quantities to be summed when determining the tier to use, which may not be your desired behavior. When setting up schedules, identify if the intent is to assess the discount tier based on the quantity of product purchased for just segment 1, segment 2, etc. or if the intent to discount is based on the total count across all segments.

Plan Product Data Population

When implementing Salesforce CPQ, you will need to either create or update Product records in your Salesforce instance , depending on whether Products are already in Salesforce or not.  The easiest way to update or create products in mass is to utilize a tool such as the Data Loader to mass import or update product records. However, MDQ segments cannot be loaded via import lines.  Remember to allow time in your project to create Price dimensions (segments) for products manually.

*Note: This article is assuming that Salesforce CPQ is not already implemented. If your company is already using Salesforce CPQ and you are adding the MDQ functionality, it is very likely that you will have to re-configure or revise your Salesforce CPQ configuration and products in order to be able to accommodate MDQ.  Stay tuned for future articles regarding preparing an existing Salesforce CPQ Instance for MDQ Implementation.