Once you have implemented your Configure / Price / Quote (CPQ) Tool you will have to keep it up to date. While this sounds easy enough it represents a challenge for a number of companies. Personally I encounter the following two cases regularly. Both cases can represent a serious challenge to your business and so it makes sense to have a closer look at them and determine their PROS and CONS and find a better way.

There is no documentation : This happens mostly with companies that have a small CPQ Maintenance team (e.g. 1-3 SME’s) and a simple product model

PROS:

  • easy maintenance (e.g. someone calls and the changes are made right then and there)
  • quick turn around of changes (e.g. quick fix and test and then the changes are released to production)

CONS:

  • usually only the person that performs the maintenance knows how the product model works
  • instead of using standardized solutions, a new solution may be implemented for a previously encountered business problem

There is a lot of documentation: This happens mostly with companies that have a large CPQ Maintenance team (e.g. 20+ SME’s) and a complex product model

PROS:

  • clear documentation of all product model changes is available
  • the same solutions are used for the same business problems

CONS:

  • turn around time of changes can be very slow (e.g. days/weeks)
  • usually additional resources are required to enable this process

To ensure you do the right things (meaning your operation is effective) and your team can perform with the least amount of time and effort wasted (meaning your operation is efficient) you need to prepare for CPQ Tool Maintenance. The earlier the better! Address at least these four basic questions to prepare for that.

1.    Who is maintaining your CPQ tool? Like most companies you probably want to maintain your CPQ tool with your resource and not always ask your CPQ Vendor or a Consulting Company to come in and maintain that tool, correct? If yes, you have to have these Subject Matter Experts (SME’s) on your team. Also keep in mind where these resources are located (e.g. for quick changes you probably need someone onshore who can do that). Use the documentation that makes the most sense for your team and is regularly used.

2. How is your CPQ tool maintenance connected with your New Product Introduction (NPI) Process? Every time a new product is introduced or a change to an existing product is made that change needs to be reflected in the product model (yes it could also be in a table). You should develop and update your NPI Process so that every stakeholder knows what they have to do and when they have to do it.

3. Should you document any product model changes outside your CPQ tool? Yes, and here are three reasons why

–   Product Managers provide critical input for the product model and they need to guide and understand how the product will be setup and sold with your CPQ tool. In many cases they are not technical resources.

–   Support Team members are not technical CPQ experts but need to determine if a reported business problem is an issue or expected CPQ tool behavior. They can’t quickly go into the CPQ tool and determine that but benefit from a business oriented document that describes expected CPQ tool behavior in business terms

–   Technical Implementers (e.g. IT, Sales Ops) need a document that shows how the product model was changed, by whom and when. This can also be used to resolve disputes between Technical Implementers and Product Managers

4. Who is providing support for your CPQ tool? see point 3 above. If you work with onshore and offshore teams the documentation process is even more important to prevent any confusion.

If you determine that you need to document your business rules outside of your CPQ Tool you should consider the following four steps

1.    Have a RACI discussion (Responsible, Accountable, Consulted, Informed) with your Key Stakeholders (Sales, Sales Ops, Product Mgmt, Finance, Legal, Marketing, IT) This is to agree on Roles & Responsibilities. It should be short (e.g. 2-3 hour meeting) discussion that provides a common understanding about who is doing what.

2.    Determine what level of documentation you need (e.g. you may want to document your product/service rules but you do not want to add any pricing information) and what SME’s are tasked to set them up

3.    Develop a business process flow to maintain the required documentation and get sign off from Key Stakeholders

4.    Implement KPI’s and measure Key Stakeholders on compliance to ensure your teams adhere to the agreed processes.