Category Archives: Uncategorized

The CPQ Challenge for the Telecom Industry (or, how do you fit a square peg in a round hole)

shutterstock_297180278

I just completed a 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 purchase 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 your 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.

The Technical Reason why Salesforce is buying Steelbrick instead of Apttus

Earlier today, Steelbrick (Steelbrick.com) posted a letter on its website by CEO Godard Abel confirming industry rumors that Salesforce had indeed signed a definitive agreement to buy the remaining shares of Steelbrick that it (Salesforce) does not already own.

This comes as a little bit of a shock to those who watch the CPQ space because Salesforce has, in the recent past made substantial investments in industry leader, Apttus (apttus.com). Today, Apttus leads all others in adoption rates for its CPQ product. Apttus CPQ is the de facto standard for enterprise CPQ implementations. So what justifies the nearly $360 million purchase price that Benioff and team just agreed to spend for Steelbrick?

Most implementers of Salesforce based CPQ products think that the answer lies in the technical synergy between Salesforce and Steelbrick. That is to say that technically Steelbrick integrates into the Salesforce platform much easier (and much more naturally) than does Apttus.

It’s all about the Objects.

While both the Steelbrick CPQ and the Apttus CPQ products are built on Native Salesforce, the two have chosen a fundamentally different technical path. The details of the two products tell the larger story. Within Salesforce, there are approximately 400 interconnected tables called Standard Objects. You get these tables when you first get your Salesforce licenses. These include Objects with names such as “Account” and “Contacts.” In addition to that, the Salesforce platform allows a company’s administrator to define new tables (called Custom Objects in Salesforce lingo) that carry the data that can not be cleanly inserted into one of the Standard Objects. Architecturally, Steelbrick has chosen to leverage and expand upon many of the Standard Objects that Salesforce uses while Apttus has chosen to build it’s own Custom Objects.

So, why should I care?

Most implementation partners have an opinion on Standard vs Custom Objects. On the custom side, Apttus will tell you that their Objects are simply more powerful and better suited to handle the heavy lifting that is CPQ, and that Standard Objects can not be stretched to accommodate the CPQ load. Not so fast,says Steelbrick who has chosen to architect around Salesforce’s Standard Objects. Steelbrick has extended these Standard Objects with Custom Fields to achieve their objectives. In fact, Steelbrick will tell you that the advantage of using Standard Objects allows companies to buy additional products on the App exchange or from Salesforce that expect (for instance) Quotes to be in the Quotes object. Valid point. To further emphasize their point, Steelbrick will point out that Salesforce itself advises that you don’t build Custom Objects unless your task simply can not be accommodated with their out-of-box Objects.

While it will become clear that other deal points are at play in today’s announcement, no doubt integrating Steelbrick into the mainstream of Salesforce’s technical offerings will be much easier than had they tried to do the same thing with Apttus.