This post will explore what to consider when evaluating Salesforce, generically and, more specifically, CPQ or Revenue Cloud.

**A quick callout: I have not used many of Salesforce’s clouds. My perspectives are primarily based on Sales Cloud, Service Cloud, and Revenue Cloud, with the occasional Experience Cloud and Marketing Cloud.

First and foremost would be to understand the age of the org – is a year old or is it 15+ years old? Why is this important? Well, the older these systems get, the more complexity they tend to build up. Complexity and customizations should be one of the first places to start. Understanding if the org being acquired has documentation on what has been built and how many team members it takes to run the show will give you a decent understanding. The goal here is not to understand what is going on down to the field level, but rather, when looking to bring this system into your own structure, what difficulties might it bring. The more customized and complex a system is, the harder it will be to port over.

Other things to look for at this stage are the complexity of the tech stack that has been integrated into Salesforce. Do they have 30 different applications that they have connected? Do any of those apps overlap with what you might already own? These are important to keep in mind as they could either increase or decrease your licensing cost upon acquisition, as at least initially, you will be required to bring those license costs over.

From a license cost perspective, it is also essential to understand what percentage of users have a license and what kind of license they have been granted. Salesforce has different license types, each with its own price tag. They are also not known for being happy about decreasing the ARR of the contract value even when an acquisition occurs, so understanding what kind of impact the license costs from both the CRM and extended apps will have is critical to comprehend ahead of time.

When evaluating the people it takes to run the system, it’s important to note whether those people are in-house or consultants. Is the work constant, or does it ebb and flow when there are projects?

Additionally, upon receiving any documentation, it should be questioned if anything in particular was heavily customized and requires specific in-house knowledge to maintain. We all know that when an acquisition occurs, there are layoffs, and people simply leave, so knowing this ahead of time could possibly save some headaches.

Particularly true in the CPQ world is examining how the product catalog has been structured. Do they have SKU proliferation or 100 different price rules and product rules that all go in a specific order? Is the process for generating opportunities and renewals streamlined, or is it ad hoc based on the rep completing the order?

Lastly, another item that arises from everything already discussed is the data itself. Much of the above concerns the underlying infrastructure that makes up how the CRM runs, but another crucial factor is how the data is. Is it complete? Is there a time period by which the data is unusable? Has the data, particularly billings data, ever gone through a compliance round?

These questions and thoughts are essential to evaluate ahead of acquisition as they can all lead to unexpected expenses and time needed to unravel them post-acquisition. Of course, even if the answers are negative, the pros of the actual purchase may outweigh any of these findings, but it should still be a step in the process.