Select Page

CPQ & CLM: Maintaining a single source of truth

Dec 1, 2021 | Admin, CPQ Insights, Latest News, Salesforce CPQ

According to Lionel Grealou, “A single source of the truth is the practice of structuring information models and associated schemata, such that every data element is stored exactly once. From a business perspective, at an organizational level, it means that data is only created at the source, in the relevant master system, following a specific process or set of processes. SSoT enables greater data transparency, relevant storage system, traceability, clear ownership, cost-effective re-use, etc.” When data within an organization is siloed across different systems, it can become timely and costly to manage, and more importantly, it can interfere with the visibility into the holistic data required to make key business decisions. As part of your implementation journey, understanding where these sources of truth should reside and how to best manage the data between your CLM and CPQ systems is key.

A CLM system is a central database, repository, and single source of truth for managing your contracts and related metadata. A CPQ system, on the other hand, is a central database, repository, and single source of truth for managing your product SKUs, pricing, and discounts.  

This post will focus on some best practices on how to configure and maintain your CLM and CPQ systems to ensure greater transparency and traceability.

 

Contract Generation

Most CPQ systems, including Salesforce.com CPQ, include document generation capabilities to standardize the creation of contracts. Capabilities within CLM systems such as Conga Composer and DocuSign’s Doc Gen also provide robust document generation capabilities. If you have both CPQ and CLM systems, which document generation tool should you use? Considering the previous paragraph explaining the importance of managing single sources of truth, let’s try to address that question. 

When you create a contract from Salesforce.com CPQ, that contract is automatically stored within Salesforce.com. Let’s say one year from now you’re going through an audit and you need to pull reports within your CLM system to show you a holistic view of all contracts generated within the last year. Without leveraging any sort of integration to send the document to your CLM tool, your reports will be missing the contracts that were generated from Salesforce.com CPQ, resulting in reporting inaccuracy. On the other hand, when you generate a contract from your CLM tool, it will automatically reside within your CLM system. When you try to pull that report one year from now, your data will be holistic containing all documents. If getting your CLM data accurate for reporting is top of mind, it is best practice to generate your contracts from within your CLM system. Conga Composer and DocuSign CLM Doc Gen also provide additional capabilities outside of what is included with CPQ’s Document generation function, such as additional file formats and the ability to perform robust queries to access certain types of data, which should also be considered when deciding on which document generation tool to use.

 

Approvals

Most CLM applications, including Conga Contracts and DocuSign CLM, feature robust workflow capabilities for automating different types of approval processes. Capabilities within Salesforce.com CPQ, such as Advanced Approvals also provide robust workflow capabilities for automating different types of approval processes. So if I’m implementing both Salesforce.com CPQ and DocuSign CLM, which functionality should I use for managing which approval processes? Referring again back to my source of truth summary, let’s try to address that question. 

Workflow capabilities contained within most CLM systems are usually technically capable of managing a variety of different approval processes, including discount approval processes; however, let’s say you decide to manage the discount approval process within your CLM system instead of within your CPQ system. After the contract is generated it is sent through redlines and negotiations, whereby discounts are often negotiated, rejected, and approved. The version history of those discounts and what was edited now resides within the redlines on your contract; resulting in a lack of ability to easily access the discount approval version history within your CPQ system. On the other hand, let’s say you decide to manage the term-related approval process within your CPQ system. Before or after any products, discounts or pricing have been approved within CPQ, the Quote record is sent to your legal team for non-standard term approvals. Once approved, the version history of these terms now resides within your CPQ. Following that, your contract is generated from your CLM system. Without any manual edits or integration, the term edits are not visible within the physical contract or CLM system. As a result, reviewing the entire history and edits to the contract within your CLM system becomes a heavy burden on your Legal team. It is best practice to maintain and manage product, pricing, and discount-related approvals within your CPQ system and dedicate legal and term-related approvals within your CLM system.

 

To find out more about best practices for implementing CLM and CPQ solutions, please contact Simplus. 

 

 

0 Comments

Submit a Comment

Authors

Simplus logo
Simplus team
| + posts