CPQ Bridging Front and Back Offices
I’ve written many times about how conventional, premise-based, ERP seems to be evaporating and CPQ, configuration, pricing, and quoting, are business processes that illustrate the point. First, let’s all agree that ERP isn’t going extinct as it evaporates—it’s too valuable—but it is getting a haircut. Many of the functions leaving ERP are condensing back into the front office and to me that’s what’s exciting because it brings back office data closer to processes that consume it. Naturally, back office systems that are coupled with the front office, even to the point of being native to the same platform, have a distinct advantage.
CPQ embodies the value of the new front-to-back office setup. While mostly front office sales people use CPQ, the data they access has a strong back office flavor. It includes the product catalogue, price lists, and existing customer information that can drive things like cross selling. So CPQ sits at a strategic position, a crossroads, between the front and back offices and that presents its own set of challenges. For example, while sales people want and need access to ERP data very few businesses would want to give them edit and delete privileges to the back office systems.
Also, CPQ workflows involve front office personnel like sales people and their managers, not back office folks. They need to ensure quotes are right and to get approvals for discounts and other irregularities that are commonplace in sales. Top this off with the need for speed—getting an accurate quote to a customer before a competitor does and you have a strong case not only for CPQ but for keeping it closely coupled to both front and back offices so that the CRM system can get data efficiently and safely to conduct its vital processes.
There are lots of ways to do the coupling and no end of interfaces and APIs that vendors use to accomplish this. But one of the best approaches you can consider is just building the CPQ system on the same platform that the rest of the ERP and CRM apps use. We learned in geometry class that if A = B and B = C then A = C, this is the logic of building on a common platform. If everyone builds to the standards of the same platform when the time comes to cooperate there’s great commonality between systems. This won’t completely eliminate integration issues but it significantly reduces them.
The common platform approach shows its true benefits when it becomes necessary to deploy systems on more than the standard desktop or laptop, for instance on mobile device(s). Increasingly CPQ is becoming a mobile app that field reps can use to issue quotes and ask for business on the spot, wherever that spot is. But also, managers and others can make significant productivity gains inside a headquarters building using mobile technology so it’s not just the field reps who benefit from platform-centric strategies. This is also another reason to keep some distance between back office systems and mobile devices that could get lost or stolen. So, finally, it’s hard enough to build for one hardware and operating system platform but today you need to be able to define once and generate many times—another platform advantage.
Incentive compensation is another example that consumes both front and back office data. The CRM system, including sales and marketing, captures deal data while the backend records deals and issues and collects invoices. But there’s also a lot of deal specific information that must be saved that back office systems don’t usually track such as incentives, spiffs, and quotas. Compensation systems might also access employee data from the HR system, which is itself tied closely to the back office. Together, these processes (and there are many more illustrating the same points), thrive when they share a platform precisely because they must access data from across the organization.
A few years ago CPQ and incentive compensation were nice systems to have but many businesses still relied on spreadsheets for their product catalogues and compensation tracking and sneaker net to get approvals. But that era is quickly receding because the appearance of many other technologies is relentlessly accelerating the pace of business. It’s best to keep up.
Salesforce’s Desk.com Gets Smarter
It was gratifying for me to see the Salesforce announcement about the latest iteration of its SMB service desk product, Desk.com because it is so in-line with my thinking as well as my book, Solve for the Customer (I know, it’s a shameless plug). While I happily acknowledge that I advise the company from time to time, there is no causal relationship between the book and product, but sometimes, correlation is just fine. This is one of those times when correlation yields validation in both directions.
Of course there’s a press release and you can find it at Salesforce.com because it is not my intention to regurgitate it here. I prefer to focus on one new function that draws my interest and shows the parallels I mentioned, Desk.com Customer Health Monitor. Billed as a category-first among service providers, the monitor does what I’ve been advocating with minor exceptions. It tracks metrics about customers that a vendor thinks are important and reports on them thus providing alerts that help to prevent churn or attrition.
FYI, Zuora, another company I advise recently bought FrontLeaf to do much the same from a different angle. This idea is gaining traction.
This approach amounts to managing by exception. A small company can’t afford the labor or even subscribe to the systems involved in constant customer outreach and this tactic focuses on what evidence shows are customers that need an intervention, perhaps by a customer success manager. All good.
Now for some nits that need to be worked out—not in the product but methodologically. The big, and for many, hidden issue is knowing what you don’t know i.e. how does a business know what things to measure? An obvious example in the press release is what happens when a customer calls support twice in a month. Is this a sign of trouble or frustration and possibly a churn signal? It could be and the point of an alert is to call for further investigation, which leads to interrogating other metrics to triangulate the situation.
For example, new customers getting up to speed will likely call in more than established customers so it’s best to correlate frequency with other factors like seniority and possibly also products in use—did the customer just install the latest upgrade?
There are many iterations of all this and the simple point is that any company will first want to identify all of the situations that need monitoring and develop accurate metrics for them. I call the situations Moments of Truth, things that both vendor and customer care about and that must be addressed, moments of truth. So we must know our moments of truth before the rest of this makes sense.
We can safely assume we know some of our Moments of Truth but that’s no longer enough. We need to know all of them or we’ll be missing things we can help with and that’s bad because successfully negotiated Moments of Truth lead to bonding which leads to customer advocacy. We really can’t have too much bonding so we need processes that find all of the Moments of Truth and instruments them via tools like the health monitor.
Discovering Moments of Truth is likely a task for a future product release and probably other products like community and analytics. Using our brains to find the low hanging fruit will do just fine for now but suffice it to say there’s more to be done.
