If you’re familiar with Salesforce CPQ, you know that it’s a very powerful solution for our customers. But mastering CPQ is a tough battle. For those of you already working with Salesforce CPQ, or those that are just starting out with the product, we thought we’d talk to our experts to share some tips!
For the second installment of our 3-part series, “10 Minutes with a Salesforce CPQ Architect”, we caught up with Laxman Rao Manchukonda, a Senior CPQ Technical Architect at Salesforce.
Laxman has over 9 years of experience delivering success at an enterprise level, with 6+ years in Salesforce Billing and 3+ years in Salesforce CPQ. He’s a Senior Technical Architect at Salesforce, has 14 Certifications, and lives in the UK with his family.
You’ve done tens of projects – in your experience, what are some key things that make a CPQ project successful?
Laxman: If the customer can articulate, very clearly, what they need, and what they do! When the customer is prepared with the right information and proactively works with us to understand the design and build, it’s always a great sign.
Also, a solid architectural design that covers most of the project aspects. This usually happens when the customer is adequately prepared for design workshops, and understands their business and key requirements.
Another key is designing for the majority. We should not be building a system for 5-10% of use cases, but rather the opposite. If you find yourself starting to build for edge cases, you may spend a lot of time on the project and achieve virtually nothing! Always concentrate on 90% of core requirements.
Related to the above – what are some red flags in a CPQ project, that you may notice early on, and want to bring up early?
Laxman: Deviating (a lot) from out-of-the-box (OOB) functionality. As we put on our solution architect hat and start mapping requirements to functionality, we learn pretty quickly when requirements are going to need customization, and this is natural. We should make appropriate decisions on whether to use CPQ functionality or do something advanced (i.e. use the Quote Calculator Plugin instead of 100 Summary Variables).
Limits & drawbacks are also a concern. If a customer reveals information about their business process that from your experience with the product, you know will be a challenge, this should come up early. Transparency is important, but be sure to show up to this conversation with an alternate solution 😉
What are some trends you’ve seen in your projects in the past year, in relation to customers and their needs?
Laxman: One trend I’ve seen for a lot of CPQ customers is the confusion around the definition of a ‘Product’. They tend to think in a SKU mentality, and are not willing to harmonize their catalog. I see hundreds of products in a catalog, and often many of them are the same product, but with slightly different attributes. When presented with this scenario, we should transform the catalog using the native features of Salesforce CPQ. For example, Instead of creating 1 product SKU per region (which will quickly proliferate your catalog and cause poor user experience), just create 1 product, and dynamically calculate the price based on regional data.
What’s the most challenging part of this role?
Laxman: Data migrations! The actual loading of data – inserting quotes, quote lines, etc – is pretty easy. It’s the transformation of data from existing systems to Salesforce CPQ that’s complex. It requires not only effort and a well thought-out design, but also that the customer has given us the right data in the right format!
If I had to make a second choice, I’d say ever-changing requirements. Any project can change requirements, and this is not a big deal. But, making changes at late stages in the project, especially those which will impact the fundamental design, is hard and expensive.
Any message or wise words you’d like to pass on to an aspiring Salesforce Architect?
Laxman: When you’re speaking with customers, keep asking questions! Have a dynamic conversation, learn their business processes as best as possible, and this will lead to a great solution design.
Never hesitate to tell a customer what you can’t do…but remember that there’s a right way to do this. Don’t worry about negative reactions, but rather keep customer success at the front of your conversations, and it will work out.