accordion-arrow breadcrumb-separator btn-link-arrow case-studies-carousel-control-arrow-left case-studies-carousel-control-arrow-right case-studies-carousel-control-bg chess-piece cloud contact-close email-icon map-marker-icon mobile-nav-close phone-icon select-icon-arrow select-icon-tag service-transformation small-arrow smoothscroll-arrow top-right-arrow

Five Common Salesforce CPQ Implementation Mistakes

13th August 2019

Author Michaela Burton

Your first Salesforce CPQ implementation will be both a challenging and rewarding experience. In order to set yourself up for success you will need to complete a number of preparation meetings, timeline discussions and design workshops before you begin the actual implementation. This will include finding the right partner to work with or enabling your internal employees via CPQ training, engaging key stakeholders to determine the timeline and scope of work, creating a migration plan from legacy systems, and a number of other important discovery tasks. Doing your due diligence and dedicating the appropriate amount of time to this phase of the project is key, and when done correctly will instil confidence in both the delivery team and the business stakeholders. However, even when a project begins with the best of intentions, there are some pitfalls even the best planned project can fall into. Below are five common mistakes that occur during the implementation phase of a CPQ project.

 

1. Product Modelling – Software Capability Overshadowing Business RequirementsCompanies often use the implementation of CPQ software to reevaluate their product offering and find new and innovative ways to package and sell. While this is an overwhelmingly positive benefit of a tech implementation, it’s easy to sometimes get carried away by the urge to combine and consolidate products. As with any software implementation, technical solution design should never come before the business requirements are fully understood.

For an extremely simple example, let’s look at Product A: The Apple, and Product B: The Orange. The Apple and The Orange are both fruits, both round, and often are purchased together in the same or similar quantities. Looking at them on paper or in an Excel document, it may be tempting to combine the two into one single product called, say, “The Fruit”, using an attribute to distinguish the two. Why not?! It consolidates the catalogue, which means less data in the system, which means optimised performance. Or, perhaps, they could be part of “The Fruit” bundle, and we can use an attribute to control the price and the inclusions. What a great way to show off the benefits of the system!

But, what happens in a few months when we add Product C: The Banana and Product D: The Blueberry to our product catalogue? The Banana looks nothing like The Apple or The Orange, and The Blueberry is purchased in much higher quantities. Technically, though, they are fruits, and based on the way we have configured our system they now must be grouped into the same product offering as The Apple and The Orange. And now Johnny Appleseed, your most important customer, is unhappy with the generic description he gets on his proposals when he is trying to order The Apple in bulk, which means additional customisations are required to dynamically update the description based on the type of fruit being purchased. Your sales reps are also wondering why they can’t just type “The Orange” into the search bar in order to find and sell it. They’ve been selling it as a standalone product for years, why is CPQ so difficult!?

Admittedly, the above example is a silly one. However, the mistake it outlines is all too common in new CPQ implementations. The driver behind this mistake generally comes not from a place of malice, but rather from a place of excitement around the new possibilities available to business via the CPQ platform. There are, of course, genuine use cases for all of functionality outlined above. Product attributes, bundling, and dynamic descriptions are just some of the many features available that can reduce clicks and improve the quoting process. The key takeaway from this story and others like it is: business requirements must always drive the technical solution. Changing a product design or business process so that it suits a more exciting technical solution is never a good idea. Just because functionality exists and can be utilised, does not always mean that it should.

2. Approvals Overload – The Risk of Becoming Big BrotherAdvanced Approvals functionality is often seen as one of the most compelling reasons to purchase CPQ+ licenses from Salesforce. Unlike standard Salesforce approval processes, advanced approvals enables parallel approval chains to exist within one overarching approval process. It also introduces the concept of smart approvals, which re-inserts a recalled or rejected record back into the approval process at the layer which it was initially rejected at, rather than returning it to the beginning of the process. These two benefits alone have the ability to drastically improve user experience where users are accustomed to lengthy multi-step approval processes.

That being said, no matter how sophisticated or intelligent the approval process is, it will always come as a shock to users who are not used to this level of governance and have not been properly trained on the change. If there are no existing approval layers in place, introducing it alongside brand new software will likely result in frustration and change fatigue in your user base. In my experience, whenever a brand new rollout also includes brand new restrictions (think validation & product rules, locked fields, and approval processes in the Salesforce world), they are almost always immediately scaled back as a reactionary measure to negative user feedback.

Introducing approvals in the second or third phase of your rollout, after users have had a chance to use and fully understand the new software, is the recommended approach for most new CPQ implementations. This helps to negate change fatigue and gives project teams the opportunity to communicate the change, as well as the reasoning behind it, well ahead of time. By the time the approvals process goes live users will be expecting it and will already have been trained on how to use it. This will drastically improve user’s perception of the system and enable you to move the project forward with a focus on introducing new features and enhancements rather than rolling back functionality.

3. Quote Document Delays  The Importance of the Proposal The quote document is one of the most important pieces of any CPQ go-live. In many instances, sales and operations representatives have grown accustomed to having to manually create a proposal for each new deal. This is often a time consuming and burdensome process that does not lend itself to positive customer experiences or a short deal cycle. The ability to press a button and have a perfectly formatted proposal available to send to the client within seconds is a massive time saver and productivity booster.

Despite being a value-add for internal employees and customers alike, quote documents tend to be overlooked throughout the CPQ implementation process. While it is logical to begin quote document development after products have been modelled within Salesforce, there are many elements involved in proposal preparation that can and should be considered early in the implementation process, such as: What will the document look like? How should discounts be displayed, per line item or as a sum total? How will the products be grouped? What terms & conditions are required? Does the level of complexity require the purchase of third-party document generation licenses? Are we going to require electronic signature capabilities? And so on.

After answering these questions, it is prudent to ensure that the time dedicated to document build also considers the time required for changes that stakeholders will request after seeing the document with real data. Template designs are always subject to a few tweaks here and there before it’s customer ready. This portion of the build may consistently be the most under-scoped piece of the implementation process, but all that’s required to prevent delays is a bit of forward planning and a steadfast commitment to not let scope creep in other project areas take away from document development time.

4. Order and Contract Management – Forgetting Forward Planning Taking an iterative approach to CPQ implementations is preferable in the vast majority of projects. It allows the user base to familiarise themselves with the core areas of the platform while end-to-end solution is gradually rolled out. Because orders and contracts mark the end point of the quote to cash process in most Salesforce instances, their development and rollout is often delayed to the later phases of CPQ implementations.

While it is reasonable to delay some of the more nuanced contracting functionality like amendments and renewals to later phases of the project, it’s important to remember that decisions made early in CPQ implementations around product and subscription modelling will impact this portion of the project. Failing to consider how you would like subscription and asset management to work in the long-term may lead to re-work and more complicated solution and design requirements in later phases of the project. Avoiding this common mistake requires stakeholders and project leaders to have a point of view early in the implementation as to how orders and contracts as a whole should behave. Having this clear vision early in the project will guide the implementation team as they determine how to best configure products and quotes in the initial project phases, while keeping the long-term goal in mind.

5. Tactical Takeover –Bandaging the “Bandaid Fix”It’s deployment night, you’re going through your final round of business acceptance testing, and something isn’t working as expected. What could have caused it? Was it that last minute workflow rule, or is the minor change to the trigger you wrote running into managed package code? Unfortunately, you don’t have time to properly investigate, diagnose, resolve and test to the standard you would typically enforce. You’re going to have to deploy the dreaded ‘bandaid fix’ and come back to it later. It may not be ideal, but it is an unfortunate reality of software implementations with tight deadlines.

Bandaid fixes and tactical solutions are okay in the short-term. They serve the important purpose of keeping stakeholders and executives at bay and providing end-users with an acceptable short-term solution to a problem. The key to these solutions is that they are designed to be interim fixes. They should only remain in place while the strategic long-term solution is being designed and built. Unfortunately, because CPQ implementations are often up against tight deadlines and are delivering functionality core to day-to-day business process they are very susceptible to falling into the trap of iterating on top of the bandaid/tactical fixes. Project leaders, stakeholders and super users who have developed an understanding of these interim solutions may start pushing back against ‘wasting’ time developing another solution for something they perceive as already being solved, often with phrases like: “it’s good enough” or “we’ll get to it later”.

The issue with ‘getting to it later’ is that a CPQ implementation builds and iterates on itself. What you build today lays the foundation for functionality that will be introduced in 4-6 months. The longer tactical solutions remain in place the more difficult it becomes to remedy them, and the more difficult it becomes to re-train users on the new solution. The best way to prevent this mistake is by ensuring there is a buffer between project phases to allow the delivery team to update tactical solutions, as well as respond to user feedback and implement minor improvements. This buffer will help both the delivery team and the end users feel heard, and will improve the overall long-term health of the system.