How do you fit a square peg in a round hole?

I just completed a Salesforce CPQ implementation for a large US telephone company. What started out as a simple exercise in pricing turned into a fun but extensive challenge of fitting a square peg into a round hole.

First, a little bit about what all the acronyms mean. The most exciting thing happening in computing these days is the implementation of a pricing engine referred to as CPQ. CPQ stands for, simply enough, CONFIGURE, PRICE, QUOTE. The discipline promises to be quite revolutionary in helping companies make sense of how they configure a quote in a consistent and effective manner each time, and then price it in a way that respects and rewards each of their sales channels. But CPQ is much more than that. The true power of the discipline comes in the analytics that inform your going-forward configuration and pricing model. Simply put, the promise of CPQ is in driving your go-forward sales based upon a rich set of organized and consistent historical quoting practices. Of course, that being said, the longer you have an effective CPQ process in place, the more effectively you drive your go-forward config and pricing structure.

The challenge with applying this thinking to Telecom pricing, is….well, the CPQ vendors haven’t figured out quite how to do this. You see, most quoting for product and service goes something like this: Pick a product, then pick the options that can be purchased with the product, pick quantities for each, and then price your quote based upon the pricebook and quantities. Simple. Of course, most CPQ engines can do some complex math like: if the customer buys between 10 and 60 hours of support, then charge him $100 per hour, and after that drop it to $80 per hour. Again, things that most businesses deal with on an everyday basis, and CPQ engines can price without missing a beat.

But, telecom is different. You are not buying (selling) widgets. Their offering is Ethernet or T1. Prices vary based upon the most ridiculous rubric. This becomes very evident if you’ve ever tried to read your phone bill. There are port charges, access charges, class of service charges (which could vary with port speed some days and access speed on others), and a maddening number of other charges that vary based upon how much it costs the provider to bring service to your doorstep (which in turn depends on agreements that they have with other carriers for last mile service).

In addition to all the various charges and the not-so-normal-CPQ-algorithms used to calculate them, each quote may contain the same service provided to multiple locations. This is the case if the buyer has multiple locations spread throughout the country that need to be quoted at the same time.

The challenge that CPQ faces in this environment is that most of the algorithms provided out-of-the-box don’t apply. You can’t buy 20 ‘Ethernets’ and look up the pricing table. Instead you have to look at the widget (service), call an external service to determine how far the address is from a pop-point, then look at another table to figure out if you have direct service to that end location (or you have to route through another telco)…and then do the same calculation over again for each of the charge types for each location. Phew!

The next challenge, not addressed by any CPQ software, is how to structure the quote so that it can be used for down-stream provisioning. A good CPQ implementation team has to consider not only the pricing elements for the quote, but also how to structure the quote so that you can feed the quote directly into the downstream provisioning engine. In a sense, the quote must act as the warehouse picking ticket (in our widget analogy) as well.

Another key concept to grasp when dealing with a Telecom CPQ implementation is what the Telecom industry calls MACD (Move/Add/Change/Delete). When you want to change your telephone service by adding / deleting a feature or moving across town, the back-end system has to execute a MACD. In the CPQ world, this is building a quote to alter an Asset. That’s easy. Unless you are dealing with a telco. The challenge here is that some of your pricing elements come from a historical price list, and some come from the current price-list. That is, take all the challenges that I spoke about in the quoting process, and add yet another variable: which price list should I use for each pricing component on the quote. Traditional pricing picks all your quote elements from a single price list. In telecom MACD, the pricing of most elements are driven off a contracted price list. Except when they are not. So, a quote generated on separate days for a product that has a contracted price-list can look very different depending on when you generated the quote.

Virtually every major CPQ manufacturer is trying to tackle the complexities of the telecom vertical. Sooner or later, they will ‘get’ telecom. Until then, if you are implementing CPQ for a telco, be ready to rethink everything you know about CPQ product selection and pricing.

About the Author:

Moyez Thanawalla is a cloud software consultant based in Dallas, Texas. He has multiple, high profile CPQ implementations under his belt. For more information: http://t.digital or moyez@t.digital