VRM

Microformats as information brokers – revisited

I was chatting with a colleague about the reference to microformats to support VRM, and it struck me I am not being clear enough, and haven’t thought this through sufficiently to make the case.  Thanks JPG 🙂

So I thought I would give it another shot.  First the VRM concept, outlined on the Project VRM site.

In this picture of the model, ‘Me’ represents you, the consumer.  VRM is an idealistic view that places the consumer in charge of merchants of any type, trying to sell things to you.  In this vision, presumably, tools exist to protect you from unwanted advances from vendors, as well as, tools to intercept vendors and properly represent their services and products to you, as they would fit your requirements.  And all this is done automatically. 

This suggests to me that it can only be accomplished with tools of some type that will provide that function to you, the consumer (how I have come to hate that word – thanks Tara!).

Using the diagram above as a rough reference, in order to provide that service, the functions required are presumably:

  1. Data Source …n : requirements that you the consumer define.  These will vary from basic attributes such as name, address, contact info, job, contact requirements, personality descriptors, elements that describe you in a way that would be meaningful to companies that sell things. Note all of this is securely controlled by you, and you would define how those personal attributes would be displayed to anyone.  At this point its merely a collection of personal data in a totally secure format and a location under your personal control.
  2. Comparison based on match quality:  this is an algorithm(s) that is capable of taking inputs from your preferences and data, and matching with inputs from vendors, sellers of things.  This is hard, but essential.  As a consumer I want to trust the result of this interaction, so the outputs had better be what I expect, or I am gone!
  3. Decision and vendor selection: the final piece of the puzzle is my own decision.  Based on the tools selection, I will make the final decision on the new cell phone, bank account, pair of shoes, new laptop, etc.

Running through this model points out the degree of variability is enormous, and so constructing one tool to handle all this is impossible, or at a minimum a long way off.  The preferences that apply to me selecting a laptop are not the same as for me purchasing a bank account, or a pair of shoes.

So to manage the scope of this, I will zero in on Banking, because that’s my domain.  Banking has a series of things that are standard requests, such as, name, address, contact information, contact preferences, credit history, job history, residence history, investment goals, transaction usage, financial goals, & financial aspirations.  

Hypothesis:

Take those standard requests and build into a tool that will hold all that information. Retain that tool with those request in a background state as you browse online. 

The next part I am less clear on – either:

  1. The tool would capture appropriate inputs from sites as you browse
  2. the tool would go out and spider sites and capture appropriate inputs ( I like this one better)

The need is real -my lack of clarity is only because I am not sure how the technology would accomplish these requirements.

Assumptions:

I am assuming in all this, that the corollary to the tools I am thinking of that vendors would have to adapt to this new world and provide API’s that sit out on the internet awaiting inputs from my “tool”.  When the vendor receives a request from my tool, it would send back an appropriate response based on my request.  It would only answer based on what I ask and make no attempt to circumvent the process to gain advantage over other vendors.  I, the consumer am in charge in this model, and the vendor is subservient.  If the vendor tries to press beyond what I have requested they are dismissed.

I would be in charge, and I would determine the method of response to the vendor based on the collection of responses that my tool has gathered.

Final point – Microformats

I had considered microformats might be a method of managing these interactions.  Could the consumer requirement I have outlined be brokered by a Microformat?  That’s the open question I have.

 

Technorati tags: , ,

One thought on “Microformats as information brokers – revisited”

  1. Colin,

    I agree. Microformats should definitely help with discovery, especially hand-in-hand with tagging. That basically comes from their use of semantic html. That means either of your options 1 or 2 could work, as a browser plugin, a Technorati-style spider & search, or perhaps a personal crawler/agent residing on your own machine.

    However, I think the bigger win from microformats may be learning from their focus on generating community consensus. I agree with your assertion that no one tool can solve all the problems of VRM. However, that’s almost the same as saying no one online service can meet everyone’s needs. It is true. But in practice, the Internet, or more particularly, the shared protocols and formats of the Internet, allow any number of online services to emerge to fill market needs. This happens simultaneously at the network provider level (Earthlink), the server application level (Google), and the client application level (Firefox).

    I think VRM can solve its challenges in a similar way. By creating a set of standard protocols and formats, we can enable a number of mechanisms for customer-centric vendor management.

    In your own area, if there were a standardized format for people to submit loan requests—and that met your needs as a bank—wouldn’t banks use VRM discovery/search/registry mechanisms to find and respond to those requests? After all, the requests are out there, practically free leads, just waiting to be serviced.

    I think one key to VRM is the realization that no single format is sufficient. And I’m glad you highlight that need. If we coordinate at the protocal and meta-format level, any number of request and response formats could be exchanged, allowing customers and vendors to find solutions to their problems. That’s the same way that HTML, http, MIME, SMTP, POP, and TCP/IP enable a wide range of unique, custom services.

    The lesson for me from microformats is in realizing the need to find community consensus in particular subdomains. hCard works because people agree about what it means. That means one person’s hCard is interoperable with any hCard service. Similarly, I foresee community-based development of VRM standards that resolve domain-specific requirements as vendors and service providers join in to create solutions for that domain. Private formats are practically useless here, but formats shared across a community can be incredibly powerful. That’s one of the main values of microformats, and VRM can learn a lot from that experience and approach.

Comments are closed.