It’s kind of hard to debunk something before it exists, but that’s what Graham Hill attempts with Four Fallacies of Vendor Relationship Management. Says Graham,
VRM is Doc’s response to the problems of customers getting the rough end of the stick in their dealings with companies. Rather than companies owning huge databases of customer transaction data which they can mine for their own advantage, customers should take control of their own transaction data and selectively release it to companies when they want something from them. Sounds simple enough doesn’t it.
Hard to know where to begin here. But I’ll try.
- VRM is not just my response. Many are involved in thinking about VRM and developing code and products to make it happen. It’s also still early. There is no code out there to critique yet.
- VRM is not just about “the problems of customers getting the rough end of the stick in their dealings with companies”. That’s just one corner of a much large set of problems VRM will work to reduce. Another is poor and not very granular vendor intelligence about what customers actually want. Another is a lack of a uniform and consistent way for customers to manage relationships with multiple vendors. Another is the blindered way that vendors look at “the customer” as a template rather than as an individual, denying vendors much information that might be useful. Another is money left on the table because there is no good way for customers with money to spend to notify whole markets of their wants, in ways that protect the customer’s privacy at the same time. Shall I go on? I can, but I’m not sure it’s worth it.
- Where did I, or anybody, say “Customers should take control of their own transaction data and selectively release it to companies when they want something from them”? Yes, VRM will give customers ways to control their own data, to serve as the point of integration for that data, and to share that data in selective and cooperative ways with vendors. “Take control” makes VRM sound like it’s a way for customers to storm the walls of Fort Business. That’s not the idea. Instead the idea is locating data where it makes the most sense, and giving those controlling customer data better ways of applying it. Data about who we are, what we want, where we live, how we do business … Much of this should live on both sides of the relationship system. Data “ownership” is a sticky and complicated issue. For VRM’s purposes, however, “owning” does not mean wrestling data away from vendors.
Bottom line: VRM is about providing customers with tools that make them both independent actors in the marketplace and better equipped to engage with vendors. Those tools are in development. We need to get some of them out there before we can even begin to have arguments about whether or not they’ll work. Fact is, they will or they won’t. But they deserve a chance before we go salting the soils in which they need to grow.
Graham goes on to list “four fallacies”:
- The Fallacy of Ceding Control…
Fallacy One: Companies are just not going to cede control over customers’ data. - The Fallacy of Wanting Control…
Fallacy Two: Customers way want more control over the marketing which is sent to them, but not their actual transaction data. - The Fallacy of Managed Markets…
Fallacy Three: The customer-managed market upon which VRM is built is not viable. - The Fallacy of the Economic Model…
Fallacy Four: There is not a viable economic model underneath VRM.
First, we’re not asking companies to give up data they control. We’re creating ways to share data that will be tood both sides of the relationship. This will take time. It will also probably follow the same realization and adoption curve as open source code acceptance has followed in enterprises.
Second, customers should want control over their sides of relationships with others. Those relationships should include vendors. VRM is not just about controlling (or restricting) marketing stuff that vendors send out, nor is it just about transaction data. Both are relatively small potatoes. What matters are actual customer wants and needs, along with seemingly trivial yet important stuff, such as having a way of gang-notifying many organizations (inluding vendors) that one’s address has changed, instead of notifying one at a time.
Third, we need to get stratight what “free market” we’re talking about here. Graham writes, “VRM seems to rest on the assumption that it offers a superior way of deciding what products, services and expeiences to offer to customers than the current free market system.” That’s not correct. VRM rests on a number of assumptions, none of which is that. One of them, however, is that it’s good for vendors to know what customers actually want rather than just guessing about it. Huge amounts of money are wasted by vendors on guesswork. Reducing that would be a nice payoff, wouldn’t it? I think Graham believes we’re a bunch of socialists or something. Far from it. Many of us are free-market advocates of the first order. Not that it should matter. Good ideas should stand in their own proven pudding. We don’t have that yet. Just wait.
Fourth, there is no new economic model underlying VRM. Graham writes, “The free market system has driven unprecedented prosperity in those allowed to participate in it too. I don’t see many people queueing up to enter into planned market economies these days? Why throw all that away for a transaction cost heavy model whose economics hasn’t even worked out, let alone tested and proven?” Two problems here. One is that Graham assumes that VRM opposes the free market system, or that it advocates a planned market economy. It does neither. In fact, we look forward to taking advantage of the free market system by getting better information into it. The other is that Graham seems to assume that the free market and the mass market are the same thing. They are not. The free market encompasses the mass market but is not reducible to it. VRM will improve both the mass market and the market for more individuated products and services.
At the end Graham adds,
Whilst I agree in principle that customers need to be given much more control over how they are managed by the companies they transact with, there are already partial solutions in existence such as customer managed relationships, multi-sided markets and even infomediaries, that enable this. VRM is an extreme solution that no-one is really looking for. Not Customers, not companies, not markets, no-one.
Well, as it said here years ago, CMR wasn’t getting traction (at least as a name). Frederick Newell’s Why CRM Doesn’t Work was one of the first places CMR was put forth (and very well too). But it’s a non-starter as long as it’s coming from the sell side and trying to lock in the customer. Adriana Cronin-Lukas unpacks that problem very well.
Multi-sided markets are very well aligned with VRM. Thanks to Graham for reminding me to contact Andre Hagiu here at Harvard to talk about that.
I’m also a fan of John Hagel and infomediaries as a concept, and I think both are well-aligned with VRM as a concept.
Will VRM succeed where those other ideas are languishing, or support them in some ways? I dunno. Hope so. Meanwhile, I want to offer an olive branch.
Graham is a veteran of the CRM business. It is essential that CRM folks know that VRM is not opposed to CRM. VRM gives CRM systems more to relate to. It gives customers means for bearing some of the relationship weight — ways that work in consistent ways across many vendors, for the conveniences of both sides. So it’s VRM + CRM, not VRM vs. CRM. Unless we make it the former, it won’t work. And it is essential right now to make clear that VRM is a CRM-friendly movement.
Finally, this whole exchange illustrates why I’ve been reluctant to publicize VRM in the absence of working code, working products and working services. It’s impossible not to talk about it, of course, because VRM is a movement with a growing number of people who need to be able to think and talk about it. So here we are. I hope Graham and others will look more carefully, and with more open minds, at what we are actually doing, and cut us a bit of slack while we talk about it in the meantime.