CPQ is, first and foremost, a sales tool that enables sales teams to quickly and efficiently generate quotes. However, we rarely talk about the go-live process and how to navigate it successfully.
Muys explained that Salesforce CPQ is different from what you usually do in Salesforce. He went on to state that typically the behavior of Salesforce applications is controlled by what we call metadata— objects and fields and workflow rules—or potentially by code through Apex classes and triggers. That code might be actually created via declarative processes like Process Builder and post 2022 via Flow, but behind-the-scenes it is still the same code. CPQ on the other hand works differently in the sense that it is indeed metadata-driven behavior.
This data is actually what you create to implement the logic that will be executed by different Rules Engines. There is pricing NGA, a configuration engine, renewals engines, and so on, and all this is controlled mostly by data with a little bit of help from metadata.
So what do you have to look at when you go live to support your Salesforce CPQ implementation? Let’s take a look at post go-live considerations, common issues that are often overlooked, and finally how to debug any challenges that arise.
POST GO-LIVE CONSIDERATIONS
The very first thing you need to consider is adoption. No one wins or benefits from your CPQ implementation if adoption is nonexistent, there will be no ROI. You’ll want to come up with a plan in advance to promote and train anyone that should be using the application and then monitor adoption carefully. You can do this by creating adoption dashboards. Another consideration would be to align sales team KPIs to adoption of the tool.
Next up is user feedback. Prior to implementing you likely connected with IT to collect initial feedback, post go-live is no different. After deploying Salesforce CPQ to the rest of your user base, make sure to collect feedback again, both negative and positive. User feedback is like gold, because it lets you know what works and what doesn’t work. Once you’ve collected your user data you can effectively action opportunities for better productivity using the solution.
Muys iterated the importance of collecting user feedback, and went on to focus on just how to do that. He states that you should not only create a feedback mechanism, but encourage and enable users to easily weigh in. Muys poses one such mechanism–your help desk. He reminds us that the help desk is not just there to help your users when they have a problem. Instead, it’s also helpful when collecting important feedback, so that you can keep improving your solution in the future.
The final important consideration is to take ownership of your CPQ solution. If you work with an implementation partner to do your first implementation, go through a knowledge transfer session with them to make sure you understand what they’ve done. This will give you more freedom to operate without them if needed.
Now that we’ve reviewed the key post go-live considerations, let’s take a look at common post go-live issues.
COMMON POST GO-LIVE ISSUES
There are three main issues that we come across in our CPQ post go-live implementations. The first pertains to requirements. Post go-live you might discover that you missed some requirements. Requirements are very hard to collect, and often may have been overlooked during your requirements gathering workshops. Additionally, you may realize that some of your calculations are incorrect. Despite going through acceptance testing (UAT) this can and does happen. Primarily we see incorrect calculations as it relates to pricing. Pricing managers are usually very creative when it comes to pricing, very likely making that component of your implementation the most complex.
Finally, you may experience failing processes. One example we see frequently is related to auto renewals and amendments. Your CPQ system will create auto renewals and amendment transactions for both opportunities and orders. And, if you have validation rules on that opportunity, for example, not related to CPQ, when CPQ creates those records that validation will fire and prevent the process from completing.
What do each of these issues point to? The need to debug, find the records, and fix those problems. And that’s where you have some additional challenges. Let’s dive in.
Debugging CPQ related challenges can be tough. Most CPQ administrators have probably only been through one CPQ implementation–yours. This means they haven’t seen multiple ways of resolving and supporting a user story. Simply put, their knowledge is insufficient. Compounding that challenge is the fact that great CPQ implementations make use of multiple artifacts to build a working solution–combining data and metadata together is commonplace.
As you can see there is a lot to consider, and given the potentially large number of moving pieces it can be hard to find the root cause of a problem, even for experienced CPQ consultants. This is further complicated as bugs are also not always caused by incorrect formulas. Muys emphasized that the sequence of operations, the walls and genes, are very important. So if you have those rules firing in the incorrect segments that might lead to problem miscalculations and so on. All this points to the reality that it can be very hard to debug, or find the root cause of the problem, especially when you go back to the first challenge: very often your CPQ administrator doesn’t know what they don’t know.
Are you looking for CPQ expertise to ensure a successful implementation and post go-live? Simplus is a Certified Platinum Salesforce Partner and we pride ourselves on being Salesforce experts, specifically focusing on CPQ, Billing, Sales Cloud, Service Cloud, and Pardot. Reach out to us today to help your team avoid common issues complicating the go-live process.