Top Mistakes That Are Made When Implementing CPQ

April 5, 2019

Share this post...

In its simplest form, CPQ (Configure, Price, Quote) is a tool which bridges a gap in functionality between a Customer Management solution (typically referred to as CRM) and an Order Fulfilment/Provisioning engine (typically an ERP solution). This area of capability needs to be logical, automated where practical and should efficiently navigate the Sales Team through guided processes to determine a final costed contract. But it is not without its challenges, which is why Walpole Partnership specialise in this area of capability. So, what are the top mistakes we see when implementing CPQ? In no particular order, here we go…

Mistake 1 – Lack of attention to transformative thinking and requirements

Much like many solution implementations, the requirements are a mission-critical input to the design and build of the solution. These need to be carefully considered and prepared in advance of the build phase. What we regularly encounter, is a business which recognises the need to digitally transform but merely reflects the as-is in their requirements.

Building a new solution that acts the same as an incumbent legacy system but perhaps with an improved UI (User Interface), offers very limited value. CPQ should be transformative which means processes can be progressively streamlined, insight into customer behaviour can be significantly advanced and data maintenance (for products, discounts, workflows,approvals, documentation as examples) can now be handled dynamically in near real-time. Imagine being able to tune the discounting available (sacrificing margin for market share) for your Sales Team during a month, quarter or financial year-end, allowing them to autonomously secure more deals without the need for governance or approval.

In order to maximise the ROI (Return On Investment) for CPQ, it remains important that an adopter transforms their business to operate in alignment with best-practice recommendations of an experienced CPQ solution provider. We refer to this as grasping the nettle as transformation is not an easy process and in some areas of the business and a step backwards may be necessary, in order to climb an escalator in another functional area.

Mistake 2 – Over-engineering the solution and failing to standardise

CPQ is complex and flexible by its very nature and simple by its very definition. CPQ customers can be very demanding for functional richness but it’s important that they don’tlose sight of the need for a performant and responsive platform, keeping the quoting process as streamlined as possible (simple principle to remember is that Sales Teams are typically motivated by commission, the sooner they receive this, the more they are incentivised to sell).

Whilst we would always recommend to walk before you can run with regards to CPQ and therefore would encourage extensive governance initially to validate the solution logic, we would also encourage customers to simplify wherever possible. We encourage customers not to build for the quirky exceptions, no tool will ever cover every possible scenario. Building for the majority of transactions and standardising the sales/quoting process is often of most value but most challenging, especially in businesses which have grown at pace or through acquisition.

Most CPQ solutions are SAAS (Software As A Service) and therefore cloud-based. Many have certain limitations in performance when process hungry tasks are demanded. As an example, customers need to avoid nesting of queries onto a single CPQ screen, demanding that several data tables of a significant size are dynamically modified based on any one of the queries being activated. Whilst this will complete, it will inevitably slow the UX (User Experience) and lead to frustration amongst the end-users. Adoption and advocacy should not be considered nice-to-have, so the end user experience forms a critical component in this regard which should not fail to be recognised.

Mistake 3 – Losing sight of UI/UX (User Interface/User Experience)

UI/UX gurus are many and will typically regularly state the need for;

Only useful features and functions being available to user communities for CPQ
Avoidance of capability which serves no purpose or adds no value to the customer
Fuzzy logic searching to help people navigate to their required data
Avoiding white-noise and maximising the screen layout for a mobile experience
Capturing insight into customer behaviour to tune the experience

What is important is that the users want the system, can see the CPQ benefits (against the as-is world) and these need to be clearly presented and evidenced during the build, test and rollout stages. For example, instead of laborious, manual processes and the associated human errors in putting a professional quote together, CPQ can enable automatic generation of a valid quote including optional terms and conditions, any associated whitepaper and/or technical specification (often but not always without any specialist team involvement).

A wall walk comparison of as-is versus to-be can often tangibly bring this to life, comparing the legacy world of significant amounts of rework, multiple points of data maintenance, data inconsistency, selling non-compatible bundles and services in error versus the digital, paperless process of a well-engineered, autonomous, guided and flexible CPQ Solution.

Mistake 4 – Failing to recognise the need to iteratively build

As mentioned previously, run before you can walk is a term often associated with CPQ implementations and can be one of the top mistakes made during this phase. Adoption of this policy quite simply allows CPQ to be visible and available earlier than typical system rollouts. A basic CPQ model (including standard integration to CRM) can be undertaken for a sample product line within a complex product hierarchy in 20 developer days (dependent upon the quality and accuracy of the input files).

Entering into a CPQ project with a mindset firmly set to evolution is overwhelmingly the most pragmatic approach. What is collaborated upon and engineered for iteration 1 typically does not achieve the aspirational end-state. This fundamental approach allows a pace of delivery which is essential in order to maximise the ROI from CPQ. If the system took several months or indeed more than a year to implement, similar to many ERP overhauls, then the sales processes, associated governance and indeed often the product catalogue and service wrappers will have moved-on resulting in an ever-changing baseline of requirements and an end result of a solution which does not address the points of pain and which is certainly not future-proof.

Mistake 5 – The CPQ project fails to engage with all impacted areas of the business

As with all implementations, the successful outcome is entirely dictated by the level of adoption being realised by the user community (whether they be sales, commercial, legal, engineering or operational teams). The CPQ project should therefore be visible across a business to all stakeholders. If the stakeholders do not buy into the CPQ project, the business cogs needing to be moved in order to transform the business will become a direct barrier to success and this ends up being another common problem of implementing CPQ. To stop this happening:

Take up all opportunities to engage with the audience who will ultimately operate the system.
Pro-actively take a suitable slot in the quarterly or annual sales review to advise the team on what is coming, any forthcoming subject matter expertise which may be required and explain how they can get involved.
Keep in mind that user opinions matter and affect adoption make sure that they are informed as the project progresses and offer them visibility of the solution as early as possible to help manage expectations (heavily focus on the areas of improvement to secure advocacy).

The Project Manager/PMO (Project Management Office) should also invest the time with onboarding resources. Too often we see resources pulled into projects mid-way into the design without being given the backstory of why CPQ is important and what underlying issues are intending to be addressed. Investing this time and maintaining an induction deck (typically presentable in no more than 30 minutes) is invaluable and will result in strong advocacy of people who work intermittently within the framework of the CPQ project or wider digital transformation.