As a Salesforce CPQ architect, I often get this question from other consultants and clients: what are some CPQ best practices related to design that one should take to be a successful Salesforce platform designer?
To that, I would say that there are two ways to approach a problem: you can provide a solution that works, or you can provide a solution that solves the problem. You might be asking, “Well, what’s the difference?” The difference between the two lies in longevity. A solution that just simply works will, in most cases, be limited to only solving the current situation. It may work well for your present business problems, but it is often short-lived. Alternatively, a solution that will actually solve the problem works best for both current and future business needs. It’s a long-term solution that considers where the business might go and takes future risks and challenges into consideration.
It should already be clear—whether you are an architect or a consultant—that you should always try to solve the problem. The following attributes are the most critical components to think about when designing a solution.
You should always look to provide a scalable solution. Scalability is the core parameter to implement to guarantee business longevity.
Let’s say you are designing a solution for a client that has business in the United States and only sells in USD. They have some custom pricing, and you decide to create some currency fields that store those prices on the product. This solution will work but what if the company expands in a year and decides to go international and sell in local currencies? Your solution will fail because it is not scalable. Scalability, in this case, will allow the customer to scale seamlessly and adapt to their growing business needs by enabling multi-currency with ease.
As a consultant, you should consider it a job well done when there is less maintenance for the admin team once you roll off the project. Recently, I worked on a project that was implemented by another consulting partner, and it was so difficult to maintain the solution that the client decided to engage Simplus CPQ experts to help them re-implement the solution.
I specifically remember one example related to pricing. The client had multi-currency enabled, and a couple of their products had a very customized pricing task. They used spreadsheets before CPQ to price their products, and the other implementation partner just took the spreadsheet, converted the formulas into a pricing rule, and called it a day.
The solution worked, but when it came time to update their pricing, the client realized that the solution was complicated to maintain. We quickly jumped into it and were able to convert the pricing rules into a more standard structure by using discount schedules that were multi-currency enabled. The client was thrilled at the prospect of an easy-to-maintain solution.
We have discussed areas that heavily focused on the back end of the system, but let’s not forget the most important aspect of any tool: user experience. Without it, you will have low user adoption resulting in low ROI.
Let’s walk through a simple example. In Salesforce CPQ, there is a setting that allows for the automatic calculation of prices once a user enters a discount or if any other information changes on line items. Auto calculation is a great tool, but it might slow you down if you have a large average quote size; every time a user makes a change, they will need to wait before the system performs calculations. It might get annoying fairly quickly. This is just one example, but it’s important to think about these kinds of scenarios when working on user experience.
Salesforce CPQ alone is such a powerful tool, but the fact that it also resides on the underlying Salesforce platform allows users to take advantage of pre-made configurations instead of having to build code. Users can leverage workflow rules, process builders, record types, etc.—all within the same platform.
You should always try to keep the solution simple when possible by utilizing configurations over building custom code. Before solving a problem using Apex or Visualforce, all avenues of Salesforce configuration should be considered to ensure that coding is the only viable option.
Let’s walk through an example: You are an excellent developer, and you like writing code, so you decide to do a calculation using Apex code. But why complicate your job if it can be done using a simple formula? The essence of simplicity is identifying complicated processes in such a way that is easy to understand so that another administrator can make changes if needed.
When all of these considerations come together, you’ll find that you—as a CPQ consultant or architect—will be more forward-thinking and proactive in designing CPQ solutions for your clients.
excellent post… thank you for sharing
I like your tips on best practices for cpq for your projects. I am not and expert developer that’s why I am thankful that I found your article. This will help me on my CPQ research.