How to get started on CPQ

CPQ is the first step to a full quote-to-cash process: it allows you to put together products and services and their associated pricing as a technically and commercially viable solution in front of your end customers.

Any CPQ solution — depending on your rollout approach, readiness, individual needs, and internal platform capabilities — can become complex very quickly. There are many ways (some good, some not) to configure CPQ to perform a certain calculation, apply logic, run rules, and introduce features that even the most seasoned Salesforce administrator may not be familiar with.

While this blog may not be the definitive guide to starting with CPQ, we hope it provides some insight into what to consider and how to navigate the biggest questions. Hopefully, it brings you a step closer to making an informed decision that realises your expectations.

Plan and prioritise

Before you start building your new shiny CPQ tool, you should take a moment to think about what you really should build and why. If you just start building, you might quickly discover that there are almost endless possibilities in creating cool and advanced functionalities, but it will become difficult to maintain the focus, keep the promised timeline and budget, and ensure that everything you build is compatible with all parts in the setup. In other words, it won’t really be supporting your business in the best possible way.

Instead, make your starting point about setting the target for the whole initiative. What is the company vision that you want CPQ to enable? Is it, for example, to transform from a product-centric company to a service– and subscription-type company? Do you want to boost the recurring revenue business and automate the majority of contract renewals? Or is it most important to enable easier quoting of more complex products which have the highest margins? Or perhaps the target is the complete opposite: to focus on the simpler products and streamline their sales processes while not spending much time on the complex deals?

There are many possible main targets for a CPQ implementation, also related to generally eliminating silos and building a linked and integrated system landscape that is simpler to maintain. You can, of course, have more than one target, but the more targets you choose, the harder it will be for the whole team to maintain focus and work toward a unified goal.

Prioritise requested features and user stories

Think carefully about whether your requirements are defined based on the fundamental nature of your business and are essential for you to succeed, or if they are based on how you have been doing things so far. See our tips for selecting the right CPQ platform here.

In a perfect world, every requirement or user story should have a clear business case behind it. Especially if some of your requirements need extensive customisation, you really want to question whether it’s a real showstopper if you won’t get it or something to re-evaluate later when your CPQ transformation has already passed some milestones.

So choose well what is really ‘must-have’ and what is ‘nice-to-have’. By marking all requirements as ‘must-have’, you’re shooting yourself in the foot. If one requirement needs complex customisation, it might hinder you from utilising several other out-of-the-box features, and you end up customising a big part of the whole setup. That, in turn, will mean more difficult maintenance and limited scalability in the future.

Identify low-hanging fruit

CPQ comes with a whole lot of standard functionalities, which can be activated with just a few clicks. It’s good to identify early which of these features fit well with your products and business processes and enable them. It’s never a bad idea to leverage the standard capabilities of the platform, and you will also be confident that the standard features are compatible with each other and allow for simpler rules and automation and thereby better scalability.

In other words: identify, design and build the most valuable core feature sets of the CPQ solution for your organisation and deliver these first. You can always grow from there, and your learnings will serve you immensely the next time around. Have a change management and training strategy, or at least an awareness, in mind throughout the project.

Rethink what you really want to sell

A CPQ implementation is a great chance to re-think your product catalogue and what you really want to sell. Having a proper product configurator opens up completely new possibilities to have a smarter and more compact product catalogue without separate SKUs for each variant.

The target for managing products and configurations also has a big impact on the size of the project. A catalogue with ten products that are configured, priced and contracted in 100 different ways is more expensive to implement than 100,000 products sold in a handful of consistent, defined ways.

When considering CPQ, spend time finely mapping and analysing the way a product moves through the sales process; the various iterations and cycles it goes through from ‘a SKU in our catalogue’ to ‘PO-ready’ will give you an idea of how complex your product rules need to be. Suppose you discover your sales process involves multiple approval iterations, custom pricing models, bespoke massaging of contract or quote terms, or other once-off activities that delay an already difficult sales cycle. In that case, you should question your pricing and configuration logic.

Another giveaway is any time your quotes are moved out of your quoting platform and into spreadsheets or offline collaboration tools and then forced back into the quoting tool for final processing. This is not sustainable, and it’s a clear indicator that your product rules cannot be (or simply are not being) applied consistently or elegantly during the selling motions and that your CPQ configuration may need to simplify these rules (preferred) or be heavily modified to suit them (with attached costs).

If you have hundreds of thousands of SKUs running rampant, are not well classified, are created ad hoc based on individual sale events, or have multiplied far higher than they ought to be, then cleaning up and normalising the product catalogue into something that can be used meaningfully in CPQ logic could be a considerable effort.

Conversely, creating a well-formatted, consistent and established product database is an exercise you could conduct internally beforehand and sets the stage for a smooth, cost-efficient adoption of CPQ regarding product identification, pricing logic and configuration rules. That’s not to say having thousands of products is always challenging, nor that a dozen products cannot present significant complexity. It’s all about how well defined your product hierarchy and classification methodology is, how scalable it is, and the quality of data inside.

Define the right KPIs

When considering your KPIs, start at the highest level — your mission or vision statement — and work through the critical business drivers and associated activities to achieve this to help clarify what should be measured. Then, move into your systems and data sources to identify how technology enables or makes available the data points needed to feed the indicators.

Be careful differentiating project deliverables versus actual KPIs. The former is a targeted output result with a defined lifespan; the latter are ongoing, continual improvement measurements against a benchmark, usually without a defined target.

Well-crafted KPIs are the coordinates of your travel towards your company goals, but they are only effective when they are fed accurate data from well-adapted systems, mapped against the desired destination, and observed by users willing to take course-correcting action.

Include the right stakeholders

Too often, we see overspent budgets, internal user group conflict, delayed or failed projects, and poor adoption where CPQ has been assigned as just another internal IT project.

According to Salesforce, when CPQ is deployed and used correctly, most users report a significant increase in sales efficiency. It is a business transformation initiative that requires extensive experience and invokes strategic considerations alongside a very niche and nuanced technical skillset.

Make sure you identify and engage all business units that may be affected or provide input early on, all the way from marketing to order management, finance to customer care. Remember to invite them to the requirements and user testing sessions and communicate openly during the project as well. Key project members (administrators and developers for sure, but business representatives and sponsors as well) should undergo formal product training and gain
hands-on experience.

You can also consider engaging a qualified Salesforce CPQ system integrator for the upfront advisory portion of the project to develop a strategic implementation and change management roadmap that you can then develop and deliver internally. Knowing a trusted advisor is steering you toward success.