💃 Salesforce CPQ is Not the Problem! 🕺

Good morning, Salesforce Nerd! According to last week’s poll, Salesforce CPQ is the tech version of Jason Voorhees- a machete-wielding terror intent on dominating your survival instincts!

And the comparison to horror characters is ironic. You see, the origins of Jason, Freddie, and Annabelle are etched in lore - a severely bullied boy at Camp Crystal Lake, a story too 🤮 to publish here, and an ancient and clever demon’s “inanimate” murder machine.

But the CPQ horror stories are just the blood, guts and gore 🫣. If you’re curious about the epically grotesque CPQ origin stories, then read on ⬇️

ORIGIN STORY

Pre-Salesforce CPQ

Just like Jason did not begin life intent on terrorizing the rural New York community, Salesforce CPQ implementations are not intended to weed out the weakest Salesforce professionals.

Nay. The seed for the reign of terror was planted long before the brutality began.

In CPQ implementations, it’s the same. Businesses do not set out to have a horrific CPQ experience. The product and options strategy was developed before CPQ was even considered, but when it is CPQ time, the legacy strategy is what feeds the CPQ implementation.

Here’s what that means 👇

WHAT NEXT?

Options/Product Strategy Pre-CPQ

Here is a specific example of products/options strategy in a manufacturing industry, and how the flows downstream to a CPQ implementation-

A homebuilder company offers the buyer the option to upgrade the front door, brushed nickel door knob to the brass door knob.

For Homebuilder A, the brass door knob is SKU# 123ABC. And the product ID is 11122233 for that door knob, regardless of what Region, Division, Community or Model the buyer has selected for their home.

For Homebuilder B, the brass door knob is also SKU# 123ABC. The Product ID is 100200300 if selected on Model A.

That same door knob is Product ID 110220330 if selected on Model B.

And if the buyer selects model C, then that SKU is not available (maybe it’s not a stylistic fit for that model, or a premium option that is not available for the economic model C, or simply an oversight by the design team, etc).

😵‍💫

Then, for Homebuilder B, in a DIFFERENT Community than the above example, that same SKU# 123ABC is Product ID 101202303 on Model A of that community.

Scale this up to 100 Models of homes, 30 Communities, 6 Divisions, and 2 Regions.

😵‍💫😵‍💫😵‍💫

You can quickly see how many Product IDs the same Brass Door Knob SKU can have for Homebuilder B.

Now compound this with the thousands of SKUs a homebuilder has for all of its available options- door knobs, bathroom fixtures, kitchen drawer handles, countertop materials, vanities, light fixtures, flooring materials, etc…

And then Homebuilder B spins up a new Community, and has to create new Product IDs for each of the same SKUs.

The amount of data loading and synchronization with the CRM and ERP provides a fully-staffed enterprise IT team job-security for decades.

Meanwhile, Homebuilder A has the same product ID for the same SKU across all of their Regions, Divisions, Communities, and Models.

They’ll have a fraction of the Product IDs. And it’s still no small feat. A custom homebuilder that manages their SKUs in this flat data model will still have thousands of product IDs, just not nearly the data model complexity as Homebuilder B.

WHAT IS IT?

Diving in as a Salesforce Professional

So what can you do to wrap your arms around this gory mess?

Since the strategic decision for how to handle options/products was decided before CPQ was considered, then you need to bring some clarity to the chaos, define some guardrails, and get a working solution at your user’s fingertips asap.

And since most Salesforce professionals are not business-decision-makers, then you need to bring industrial-strength questions to the decision-making table. Here are some examples-

What is the minimum viable set of choices we want to provide our customers?

Why is this a good question? Note the key distinction of focusing on the customer, not the salesperson or tech.

Where do we want logic to live - in our sales process, in CPQ, or in the product itself?

Why is this a good question? 2 things. 1) This needs to be asked and it will create both fireworks AND blank stares. 2) The first question about serving customers needs to guide the responses to this question 💯.

How standardized is our offering across sales reps, geographies, and channels?

Why is this a good question? Our homebuilder example only covered geographies. You still need to cover the sales reps and channels.

What shouldn’t your reps be allowed to quote?

Why is this a good question? Inverting is always good!

What do we need to standardize to scale our sales motion?

Why is this a good question? From our earlier example - homebuilder A has standardized their product ID against their SKU. Homebuilder B has not. Homebuilder B will get their new community up for sale faster and cheaper.

FINAL THOUGHTS

Takeaway

In part 1 of our CPQ series, we touched on the spectrum of complexity.

In part 2, we uncovered the evil spirits that lurk behind the complexity. And they’re rarely within your control.

That matters because the wisdom you can bring to the project will give you outsized influence in how the implementation plays out.

The wisdom here is that CPQ doesn’t create the complexity. It reveals it.  

SOUL FOOD

Today’s Principle

and now....Your Salesforce Memes