Monday, 14 April 2008

VRM: Here comes the customer

I've been thinking a lot about VRM lately. Not so much about what it means, but rather the mechanism of how it can work.

If you're new to VRM, it can be summarised like this: it's the reciprocal of CRM. Rather than being bombarded with advertising, much of which is irrelevant, and the rest irritating, wouldn't it be nice if you could just tell vendors what you want, on your terms? Without even going to the trouble of looking for them? If they're willing and able to respond, they do so. Everyone else goes on their merry way. It's all about sharing the data you want with the people you want.

Some examples from Doc Searls (Cluetrain Manifesto dude), who heads up the VRM project, include:
I want to:

- Buy a power convertor near St.Paul's in the next three hours, at any price
- Buy a stroller for twins near Highway 70 in Kansas today for under $300
- Buy an Apple laptop with a 500gb HDD and weighs under five pounds, as soon as it comes out
- Buy a double decaf cappuccino at the next exit on this highway

(You can see more examples presented by Doc on this photo)

There are a few big problems that need solving. Filtering is one (both on the outbound request and the way back in), targeting is another (how do you choose which vendor to share your data with?), organisation is a third (by what mechanism do customers agree to share their data, and in what form, while retaining control over it?).

I'm wondering whether the following solution might have some mileage.

Possible solution

I'm wondering whether most of the problems could be solved by defining the terms by which we, the customers, could engage with brokers that we chose. Brokers = any directory service which is willing to accept the data on our terms. After all, the likes of Google, Yell, Yahoo! and Thompson already have a relationship with thousands of vendors. We could offer to share our wish list with e.g. Yell, on the grounds that they'll pass it onto vendors who meet our criteria, and gather / return the results.

How brokers manage the relationship with the vendors is their challenge, but they'd have a vested interest in ensuring a high quality response to the customer - otherwise the custom will go elsewhere. As for their motives, I imagine brokers could make money out of this by agreeing with vendors which customer queries are forwarded onto them, perhaps based on keyword. Maybe this could work in the same way as Google Adwords, where vendors pay to have ads next to chosen search terms, only instead they get carefully targetted, customer-generated requests.

The customer could receive a confirmation that their request has been passed onto x vendors. Responses could be penalised if they don't match the request, rather like Amazon encourages customers to rate sellers in their marketplace. Low scores are punished, to prevent spamming.

The number and quality of the responses would be poor to start with, as customers might not be too good at defining their requirements, and vendors try to game the system. But like any new system, the filters would improve over time improving the system for all.

Obvious problems

1. Hosting the original data is a problem, because customer control is one of the keys to success. Maybe TiddlyWiki could help with this? Data could be held locally, new brokers could be managed via plugin, and data can be sent / retrieved via RSS. And it passes the 'open standards' litmus test.

2. Defining the form of the customer's request is problematic. From the above list, we've already seen that requests can be incredibly wide-ranging. At minimum, a free text field is required for the bulk of the query. But I think tags should play a part (as this would make the broker's life easier, matching tags with the terms they've 'sold' to vendors). And time / location / radius probably need to be defined to some degree, to help tighten the request and responses.

I don't know much about establishing standards. My erstwhile colleague Paul Downey, on the other hand, represents BT at the W3C and thus knows a bit about standards. He sez this will be a hard problem to crack, and he's probably right. Big question: to what extent would we, the customers, allow brokers to help create this standard?

My view is this problem needs to be overcome before VRM can move forward, regardless of whether brokers are involved.

But why bother? Well...

Who wins?

Everybody wins. The customer gets carefully considered responses to their request, with minimal effort. The broker gets paid by the vendor for the targeted information. And the vendor can spend more money dealing with useful leads rather than on frivolous, scattergun advertising.

Incidentally, I'm convinced that VRM will be here one day. Customers' ability to organise themselves is only going to increase over time, as social tools become more powerful and elegant (quick nod of the head to Clay Shirky). It's a question of when, not if, this power will eventually fall into customer's hands.

3 comments:

Bart Stevens said...

Phil, pls have a look at some thoughts I have on your (clear) post.
1. Your remark on the "Yells" of this world. Why involve them? I think you should go to communities of like minded people and pitch your VRM solution. I see Yell etc (still) very much as a directory service pushing info down, whereas communities (who could use Yell) select their own vendors to do business with. It's not only a pricing issue, it's also the R (in vRm) which will increase in importance)
2. I agree with you on the tagging. But I have my thoughts on scalability.
3. On standards I think that it will be more of a best practice definition. Not so much on a technical standard. Other people will do this for us, like Dataportability, Higgins etc
4. My view is that if you build something which will give an instead value to customers they will buy into it, with or without standards. ... "Build it and they will come" ... (Field of dreams)

What do you think?

Cheers

Bart

Phil Whitehouse said...

Hi Bart,

Thanks for your comments, I've got some responses here:

1) Unfortunately, so long as an individual approaches a vendor directly, they have very little leverage. Dealing with customers one-on-one is way too time consuming for most vendors, which is why they insist on engagement on their terms e.g. "fill in our form and we'll get back to you". Adding the brokers makes the operation scalable; the customer then requires very little effort, the broker can evolve the existing arrangements with the vendors, and the vendors know they're more likely to get appropriate leads. It takes the heavy lifting away from the customer while still giving them full control over their data.

2) I'm worried about scalability too, especially when considering popular tags e.g. "TV". But I expect our methods of description would improve alongside the filters and the process, to mitigate this problem.

3) I think if we were to explore the option of multiple vendors, I think it would also lead us down a path where the information is standardised to some extent. This is the only way we can be sure that our data is shared with whomever we want...or is it?

4) Not sure what you mean by this, looking forward to finding out at EIC2008!

Joe Andrieu said...

Phil,

Good stuff. I wrote a short comment here.

I look forward to continuing the conversation in Munich.

-j

--
Joe Andrieu
Chair, Standards Committee
Project VRM