What are the best practices for implementing multi-location and multi-year setups in CPQ?

Hi Chloe! Sorry for the delay but I wanted to give this answer proper attention.

This interaction can be difficult to capture and depends on some different requirements. Happy to kick this around with you more, but I’ll say a few things then respond to your questions.

Multi-system: Dealhub has an ability called multi-system that allows you to create tabbed copies of sections of your playbook. These tabs unfortunately do not communicate with one another, but can be used with logic to great effect. The primary use cases of a Multi-system are the following:

1. Multi-Year (When Step-ups, YoY increases, or just line items per year are needed)
2. Multi-Offer (Creating independent offers to be displayed to the customer on a document)
3. Multi-Location (Associating specific location details to line items)

If you choose to implement one of these into Multi-system, you will only be able to realistically implement ONE of these processes using that function. If you need to layer in another one of these, you will need to configure it as a single-system implementation that works within the other multi-system integration.

Okay, with that said, I’ll answer your questions (in Reverse) and give you some advice on your specific configuration.

• What key questions should I ask myself before deciding on the right approach?

  • You should ask the following questions:

    1. Do I need Step-ups or YoY increases? If so, you will need to use multisystem for each year/term of the contract
    2. Do you need address information associated with a specific location that you would need to query from the CRM?

    If the answer to #1 is yes, we’re forced into using multisystem for that, if they use continuous or 1 year contracts, then we’re free to use multisystem for multiple locations. This makes everything so clean, they can name their location, or query the location from a database in the CRM along with an address, both offer some great quality of life for associating location data

• How can I structure repeatable Question Groups (QGs) to handle this efficiently?
  For this process, if we don’t need to do multi-year, you don’t even need repeatable questiongroups, you can enable multisystem and those questiongroups will serve as the repeatable questiongroup. You shouldn’t need to add another dimension underneath the location unless you’re choosing multiple products, in which case you can set up a repeatable question group to capture that process.
  If you do need to use multisystem for multiyear, you would need to use repeatable questiongroups to define the location on a per-item basis by either giving a list of pre-determined locations or location codes, or you need to give the rep the ability to fill in a location name, then copy/paste or match that to the other products associated with that location. This is… undesirable.

• How should I think about multi-system dependencies (e.g., CRM, ERP, billing)?
  Dependencies in other systems are almost always going to be driven by the product and the pieces of information that are associated with that line item. You can populate those fields by leveraging proposal attributes. You can then choose when syncing where to send those attributes in the other system, either through the standard CRM sync in the products area, or using API directly into other systems. Without using API, customers typically curate their data through the CRM, then make sure they have the appropriate information to accommodate each external system using the CRM as a distribution hub. 
   

I know that was super long but this is a pretty complex topic with a lot of implications! Let me know if you have questions

​@Katie Bowen FYI