At the VRM West Coast workshop, Don Marti led a session on Personal RFP’s, which then led to the issue being debated further on the mail list and built out in this post by Alan Mitchell. Here’s my contribution, looking as much from the CRM/ recipient perspective as the VRM one – ultimately I think that until we look at both simultaneously then we won’t get much up and running at any kind of scale deployment.
Firstly, I think we need to get our terminology in order; as Craig Burton pointed out…we do not yet have a clear VRM lexicon accepted and understood by all project participants.
Here are a couple of references from Wikipedia, that relate to/ illustrate the background to the terms Request for Information (RFI) and Request for Proposals (RFP). I think we need to look at both in tandem because typically they interact with each other.
Request for Information – A request for information (RFI) is a standard business process whose purpose is to collect written information about the capabilities of various suppliers. Normally it follows a format that can be used for comparative purposes. An RFI is primarily used to gather information to help make a decision on what steps to take next. RFIs are therefore seldom the final stage and are instead often used in combination with the following: request for proposal (RFP), request for tender (RFT), and request for quotation (RFQ). In addition to gathering basic information, an RFI is often used as a solicitation sent to a broad base of potential suppliers for the purpose of conditioning supplier’s minds, developing strategy, building a database, and preparing for an RFP, RFT, or RFQ.
Request for Proposal – A request for proposal (referred to as RFP) is an invitation for suppliers, often through a bidding process, to submit a proposal on a specific commodity or service. A bidding process is one of the best methods for leveraging a company’s negotiating ability and purchasing power with suppliers. The RFP process brings structure to the procurement decision and allows the risks and benefits to be identified clearly upfront. The RFP purchase process is lengthier than others, so it is used only where its many advantages outweigh any disadvantages and delays caused. The added benefit of input from a broad spectrum of functional experts ensures that the solution chosen will suit the company’s requirements. Effective RFPs typically reflect the strategy and short/long-term business objectives, providing detailed insight upon which suppliers will be able to offer a matching perspective.
I think the background to these terms is key to how we must think of them in VRM world if we are to understand how best to deploy them. What does that mean in practice?
In addition to these characteristics, it is also worth noting that over time intermediaries have emerged (e.g. TEC) who, amongst other support services, make whole series of standard RFI and RFP templates available at no or low cost in order to stick themselves into the value chain.
My view of the above is that a) the originators of the terms RFI and RFP now have finely honed processes for dealing with them, they do enable win-wins for buyer and seller, and intermediaries have emerged to deal with some of the hard stuff – like finding common terminology, and b) they are typically not automated processes and thus not not at all like what will actually be required to do the things we have commonly described as Personal RFPs in VRM discussions, (e.g. i’m here, and I need a stroller for twins).
SO: Before we progress, we may wish to change our terminology around the RFI/ RFP issue – to more accurately reflect what the individual needs; otherwise we risk being confused with the prior deployments of the terms which actually have very little in common with what the individual might deploy right now.
Here’s my view of what those needs are:
If we look hard enough we’ll find that there are already architectures out there, that do 2, 3 and 4 – and bits of 1 are around that can be picked up and added in, either directly or (more likely) via fourth party services. For example, the architecture below has been doing its stuff on the web since way back in 2000; a proposition called 2busy2surf that was way ahead of its time. Unfortunately that business has now gone, but the architecture and buyer-seller matching engine has been white-labelled into 20 or so propositions since then. It is still churning out stacks of permissioned requests for information and requests for proposals, and returning matched information packages or offers. These come direct from the selling organisation, or more typically through the affiliate markets (third party services).
So, to get what we used to call personal RFP’s up and running, what we need to do, in my view, is:
That’s going to take a bit of time and effort. It’s on the agenda for the User Driven and Volunteered Personal Information working group at Kantara; this group has now been approved and will be up and running shortly. I’ll post the details on how to join that as soon as I have them.