Right Side Up

One of the sessions at the VRM workshop in San Francisco last week focused on Requests for Proposals or RFPs.

The idea is pretty straightforward. A buyer creates an RFP for something she wants to buy, sends it out to the market, gathers up sellers’ responses and makes a choice.

Sellers, knowing they are competing against each other for a ‘hot’ lead, may be incentivised to offer an extra special deal. Buyers also benefit from the fact that it is a hassle-free process – the offers coming streaming in straight to your digital ‘front door’ when you ask for them. This is especially so if the RFP process creates an anonymity shield which stops sellers from scraping the buyer’s contact details and spamming her.

One way of doing this is, for example, is to ask sellers to upload their responses to a temporary URL which only the buyer knows about. Once the buyer has made her choice, or after a certain time span, the URL can be closed down.

It sounds a like a neat idea and for a time I thought it would be one of the vanguards of buyer-centric commerce. The more I look at it however, the more I think it is still a good idea – but something that will only really work well once lots of other supporting bits of infrastructure and service are in place. (For more details on this see our White Paper on Added Value Buying Services) In other words, aside from a few ‘pure’ applications it is a ‘later’ rather than ‘sooner’ development.

Here’s why. The immediate technical challenges of creating anonymous links between buyers and sellers are relatively solvable. At the moment, open source software expert Don Marti is leading the charge on this (http://zgp.org/~dmarti/business/upside-down-bg/).

Trouble is, even if we crack the technical messaging bits, there’s still a lot more we have to do to make RFPs really work. For example, we have to address the potential obstacles that exist at both ends of the process. Specifically:

- helping would-be buyers build a specification that’s clear and detailed enough for vendors to respond to
- a means of translating buyers’ expressions of desire into language that sellers can understand and respond to
- seller response processes that ‘understand’ RFP feeds well enough, and efficiently enough, to generate meaningful, useful responses.

These are not easy problems. They are very hard problems relating to language (the two sides understanding each other well enough to communicate), and value (the two sides getting enough value from the new process to think it worthwhile).

On language, the RFP problem is easy if the buyer can name an exact product title (e.g. down to bar code/electronic product code detail) – a ‘language’ that fits directly into the seller’s systems. But this probably accounts for 0.01% of real buyer requests, most of which include an element of search, discovery and uncertainty.

The other 99.99% of buyer requests will be much vaguer, along a spectrum e.g. I want to buy:

- a digital camera
- a digital camera in this price bracket
- a digital camera with these sorts of features in this price bracket (but I’m not really sure what these features are, or how important they are to me)
- a digital camera of this brand with these features in this price bracket (though I haven’t thought about which of these features are ‘must haves’, ‘nice to haves’, and so on
- a digital camera of this brand and model with these features in this price bracket.
- only this brand with a choice from these particular model variants, with these clearly specficied features.

Under an RFP system, sellers not only have to understand and respond relevantly to this spectrum in a way that generates easy-to-understand and easy-to-compare information that is useful to the buyer, they first of all have to understand what the buyer is ‘getting at’. For example:

- is the buyer describing features using exactly the same language as those described by seller in his product catalogue? [e.g. What if the buyer says he wants a 'fast' computer, or 'an easy to use' camera?] As soon as the seller needs a human being to read and understand the buyer’s description the RFP process may become far more expensive, not cheaper, than existing systems. On the other hand, if we rely simply on machine recognition of key words we will generate more spam than value, even if unwittingly.
- what if the buyer’s specifications don’t fit the market? (i.e. she can’t get all her desired features within her stated price bracket?) How does the seller respond to this? By simply spamming her with all available options? How does the seller help the buyer understand what these trade offs mean, and their pros and cons? As soon as the process goes beyond ‘a single shot’ of buyer RFP/seller offer (as soon as it requires ‘a conversation’) RFP style messaging processes don’t work very well.

This raises many issues of cost and value for both sides: ‘am I convinced that using an RFP is really the most cost-effective way for me to go to market?’

These are not just finicky details. Without a lot of surrounding services and processes to help buyers and sellers at both ends, pure RFPs which focus only on better Internet-based messaging between buyers and sellers are only likely to create a workable win-win with a vanishingly small proportion of transactions.

On top of this, as Bart Stevens (www.ichoosr.com) points out, there’s another barrier of user trust to overcome. Many consumers are so jaded be clever ‘bait and switch’ marketing ploys that seem honest and good value in the beginning only to have a sting in their tail, that they are wary of taking up genuinely new buyer-centric opportunities even when they do emerge.

It’s not only seller-centric marketers who are interested in behaviour change!

Anyway, my conclusion is that:
- the real ‘value add’ here probably does not lie in the messaging/contact aspects of the RFP process but in the specification building process – helping buyers articulate demand in such a way that it fully and accurately fits what they want, in a way that streamlines rather than complicates seller processes.
- while at first sight RFPs look like an easy ‘low hanging fruit’ for VRM, I suspect they will end up being one of the hardest – and last – nuts to crack; the ‘artificial intelligence’ of VRM if you like, where, only after thirty years of failing to solve this ‘simple’ problem do we actually realise how complex it really is. (We tend to underestimate just how complex buying processes are because, currently, most of the complexity is handled inside buyers’ heads. The complexity only becomes apparent when we try to automate it.)

But that’s not to say cracking the communication protocols is a bad idea.

Alan Mitchell

Tweet This Post

AlanMitchell Buyer centric services, Project VRM