I have worked on Salesforce CPQ projects for a number of years, from brand new implementations to undoing poorly done existing implementations for companies that are start-ups to companies that can have thousands of Salesforce users across the globe. My experience working as a Business Analyst/Product Owner and as a build lead in Salesforce CPQ projects mean I have seen the good, the bad, and the ‘what went on here.’

I frequently support customers and other admins with their Salesforce CPQ issues/questions in the wider community on Trailhead and Linkedin. I have seen firsthand and have heard horror stories of projects that do not always go smoothly, but it’s important to learn so the hard work has been done for you and I’ve come up with a list of challenges you are bound to face and how you can overcome them. You can consider this a ‘cheat sheet’ so you don’t have to make the mistakes yourself. 

‍

‍

‍

1. A complicated sales process. 

What I mean by this is that there are too many exceptions to the process that they become the norm. We have all been there during a business merger or onboarding of a new business unit, where they tell you they are unique from the rest of the business, so they do things slightly differently or why they cannot conform to existing business processes.

‍

Solution: Know your "Ws."

Why Salesforce CPQ? Who should the system make life easier for? What challenges do we face that Salesforce CPQ should ease or eradicate? When do we need this all by? 

By undertaking a high-level analysis of the platform, you can use this as your north star metric whenever a feature prioritization is required during the project and timelines are changed, stakeholders are changed, and, more importantly, as the business grows while you are implementing CPQ, as this changes the challenges you face.

If you have a complicated sales process, question who it serves, there may not be a profoundly conscious reason, and going with the status quo does not help the business. So if you are implementing a system like Salesforce CPQ, be a rebel and constantly question why things are done the way they are.

If you’re working with an external Salesforce CPQ consulting firm that is responsible for requirements gathering, they should be leading the charge with the questions during the requirements phase, and at the end of it, you should see a list of well-written user stories for the business to prioritise. 

If your consulting company is there to provide extra resources for the build and is not project managing the build, then  it is important to have a Business Analyst/Product Owner/Salesforce Team Lead from the business to help direct the questions and gain more from requirement gathering sessions. 

‍

2. Data here, data there, data everywhere. 

You have data in a lead management tool that marketing uses to prospect clients, data in your Salesforce, and data in your different finance systems, like NetSuite. It should be clear-cut what is housed where, but these isolated systems were implemented at different times, and the lines of their usage have blurred over time. 

‍

A data issue can become exacerbated when implementing Salesforce CPQ as you will need to determine definitions of what a product is. For example, a product to the sales team may be what they have agreed to with their customers, and perhaps with a breakdown of each individual component. A product to the Billing department may be the high-level bundle. So you need to identify what these, sometimes disparate, systems require from CPQ. 

‍

Solution: Identify who is responsible for which system.

Know what data you require from the different systems and what they require from Salesforce CPQ, the timeline the data is needed to do testing checks, and at what intervals a data hygiene check should be done. 

I would, for example, want to identify who is responsible for my billing system and what lines do they show on an invoice. A product in my billing system does not equate to a product in CPQ as we might want to add details such as a free managed service line to show the customer that they are getting a deal, but the business does not invoice. 

Or perhaps the business sells a platform service with their products that the price is rolled up into another product that the customer does not see, but finance would like a breakdown to allocate the revenue against. Knowing what the expectations of Salesforce CPQ are from the different teams will help you identify what sort of data should be created. 

Once the different teams have the data they require from CPQ, it brings us to the next challenge.

‍

3. Data migration (aka CPQ deployment)

Data in Salesforce CPQ makes up a large part of the implementation. So not only is getting the correct data a challenge but migrating it from sandbox to production during the project lifecycle is a pain in itself. You will have a vast amount of data to keep track of, from the products to the price rules that dictate how much an item is sold for and the price it should be updated to when interacting with different products.

Data in Salesforce CPQ is not as simple as standard objects because if you migrate a CPQ Price Rule incorrectly, it will impact every quote in the system before the issue is identified, and resolving CPQ data retrospectively is something that would have to be done out of hours when users are not creating or updating quote records to ensure the right price shows. 

Let’s use a basic Salesforce CPQ data migration example. Say I have a  Price Rule, and this Price Rule adds a discount to the quote when a specific subscription line is added. The Price Rule will also have other associated records, such as Price Action and Price Condition. So in my example, I have 1 Price Rule record, 2 Price Conditions, and 1 Price Action. 

There are many things that can go wrong during my data migration of these records that are linked to each other via a lookup. If I forget to migrate any one of those records listed, the two main consequences would be either the discount would not get added at all to the relevant quotes that have the specific subscription line, or the discount could get added to every quote in the system regardless of if the subscription line was added or not. 

Let’s make it worse by imagining the issue persisted in my production environment for the morning before I realized the issue. I would then have to migrate the data again and then retrospectively resolve the open quotes in my system to show the correct pricing; this is before I take into account any opportunity that has been closed won with the wrong amounts. So an item of work that should take less than an hour to migrate would take an entire day or two to identify and resolve. 

So, what is the solution to a data migration issue? 

‍

Solution: Know what tools and processes you will use before the project starts. 

Every implementation team should follow a process by which the organization's data should be migrated and have a unique identifier for every data record created for Salesforce CPQ objects. The implementation team should have agreed-upon tools to support the data migration process. I recommend something other than Excel documents to keep track of this. You want a tool that gives you transparency and allows you to track your data between organizations. 

After you have migrated data, the last thing you want to see is a price book entry that differs between your dev and your sandbox orgs, where you perform user acceptance testing (UAT). Do not get me started on the complexity of being unable to see who made the change and why! 

Knowing what tools to use for Salesforce CPQ is challenging as customizing CPQ relies predominantly on data. So, you want a tool that can migrate your data records for objects like price rules as well as a tool that can support migrating metadata like flows you have built for CPQ. 

4. Salesforce CPQ working with your existing processes. 

Even if you implement Salesforce CPQ correctly, you want to check how it works with your lead management system and ensure you can still invoice a customer accurately. You want to ensure this new implementation does not adversely affect the existing customer lifecycle.

‍

Solution: You want to test the end-to-end process. 

Incorrect configuration leads to real-time issues you may not pick up during UAT and ultimately hurts user adoption of the process. End-to-end testing is necessary before a roll-out so you can test data mapping as well as any integrations. End-to-end testing should cover items such as:

1. Lead creation
2. Lead mapping
3. Opportunity creation
4. Quote creation
5. Opportunity stages: Closed Won and Closed Lost
6. Contract creation
7. Customer Invoiced
8. Amendments
9. Renewals

There are many different types of testing, so you want to ensure your project has clear testing guidelines you expect the implementation and broader business to follow. The tests you run can range from peer review of the technical work to QA testing from a specific user, UAT, integration testing, and regression testing. Each testing stage should meet particular objectives and sign off before continuing the process.

‍

5. Finding your perfect match.

Having the right implementation partner is as essential as using Salesforce CPQ, if not more important. In the same way, deciding if you want to drive an automatic/manual car is more important than the make/model.

‍

Solution: Be really clear on the skill set your implementation partner should have. 

Are they there as subject matter experts or to support the internal team with the build? You want a consulting company that will say no to you and challenge your assumptions about your business as much as they say yes to your feature requests. 

An implementation partner that has worked on Salesforce for years does not mean they are a good partner for a Salesforce CPQ implementation, as it comes with its own challenges. But equally, a partner that has years of experience in Salesforce CPQ implementation does not guarantee the consultant working on your project does. 

Some questions for you to ask the implementation partner are:

1. Do you have experience implementing new and/or existing Salesforce CPQ implementations?
2. What experience do you have implementing Salesforce CPQ for a business like ours? What specific challenges did they encounter with them?
3. What challenges do you think we will face?
4. What’s the average time a Salesforce CPQ implementation takes for clients similar to us? This will help you gauge if they have understood your set of requirements and challenges and also help you understand when to expect a return on your investment. 
5. Would we have a dedicated resource(s) for the entirety of the project? What is their experience with Salesforce CPQ projects? 
6. What service do they provide for CPQ projects? Are they there just to build, or do they provide a full consulting service that includes requirements gathering, writing user stories, project management, and testing?

‍

‍

Conclusion

That is a lot to consider for a project, but if you get this right, the payoff is substantial. Correctly building your Salesforce CPQ project enables your sales users to be guided through your sales process easier and allows them to focus on their relationship with their customers rather than learning the bureaucratic aspects of selling a product. 

Salesforce CPQ is not right for every company, but for those that it is, getting the initial implementation right is a key factor to success.