RFPs can be used as an effective tool to assist purchasing decisions. They help buyers compare offerings along similar criteria in order to highlight differences and facilitate evaluations. RFPs can play an important role in executing on the strategic planning process – business goals are assessed, capabilities and gaps defined, then companies act to close the gaps by building or buying. These are key activities that must be completed before issuing a RFP.
A RFP is not a shortcut for the strategic planning process. If you don’t have these answers, soliciting 50-page documents from service providers won’t solve this problem for you. Like strategy, RFPs shouldn’t be identical, even when companies in the same industry seek to purchase similar services. This may sound quite obvious, but you might be surprised at the lack of strategic thinking that goes into many social media RFPs today.
Business works best when designed around specific parameters of a market situation. For example, I’d advise against taking another company’s social media participation policy and adopting it wholesale. Or seeing a Facebook sweepstakes idea and running the exact same program, even if you’re in a different industry and geography. Or using a photo of your customer service team as your Twitter avatar because your industry competitors are using that approach. You may be thinking, “of course not.” So then why copy-and-paste a RFP without customizing for your own needs?
Buyers of social media services have benefited from the work of Maggie Fox‘s Social Media Group and creation of a Social Media RFP template. Unfortunately, too many lazy buyers have misused this source material; in the words of SMG themselves:
“the Social Media RFP template is too long, has too many questions, and many clients and purchasing departments are simply cutting and pasting the content with little or no thought about their actual needs.“
If you think the term “lazy” seems harsh, then why would smart companies be asking for credentials in podcasting, del.icio.us, and virtual worlds? Last time I checked, Second Life wasn’t high on any marketer’s list of priority platforms. Taking this kitchen sink approach is a disservice to both buyer and seller.
I’ve always been an advocate of creating solutions when uncovering issues – stay tuned. In the meantime, I’m interested in hearing about your experiences with social media RFPs from either side of the table.
Caveat emptor? Caveat venditor.
Hey Peter – thanks for the link, and I agree with you completely. I think part of the problem is that many organizations don’t know what they don’t know, so figure “more is better”. We added an “RFP Bill of Rights” along with the revised template to help combat some of the issues we were seeing – here’s hoping that as expertise increases, RFP quality will go up, too!
Right – “more is better” thinking is pervasive and ends up being counterproductive, leaving buyers even more confused than when they started. The end result I’ve seen – buyers gravitate towards pretty pictures and shiny objects like they’ve always done.
Peter, I’ve developed an approach where the design blueprint of a service becomes the de facto basis of an RFP. Customers develop effectively develop one part of the blueprint (UNFOLD) and service providers bid with the matching part (FOLD).
The design blueprint, which is seeded with customer outcomes but anchored by customer experience, is a superior basis for generating an RFP for a service because of the following reasons:
(1) The value context of the service i.e. customer outcomes and user experience is illuminated
(2) The design elements include customer assets, need for access (i.e. resources customers do not own), user persona, demand patterns. etc.
(3) The blueprint captures fail-points and constraints associated with demand patterns, as well as the key interactions between users, service assets, agents and touch-points
Effectively, customers are being deliberative and diligent about exactly what value they are buying in a service, how and in what context that value materializes, and what would prevent it from being fully enjoyed. This is the biggest challenge for customers when buying services in contrast with value embedded in manufactured output.
With the design-based RFP, customers are literally saying : “See what I mean”.
Service providers then respond with the matching half which starts with the customer experience, and systematically builds the “service product” that will fulfill the originating customer outcomes. When the blueprint is complete, embedded in it is a service offering and a skeletal service level agreement.
What you’ve written in your post is perfectly why this promotes mutual welfare, trust and efficiency between the two sides. And since every design element has a hash tag which means the design can be distributed across teams, and dynamically constructed in an asynchronous manner which is conducive to socialized design.
An RFP illustrated with value, costs and risks; described in terms of activities, events, conditions and pathways for customer value; validated in terms the experience users (not customers) of the service; and presented in form that promotes socialization across groups, locations, and time periods.
I’d love to have a chat, share ideas and notes. I’m very curious about the RFP template you refer to.
Sounds interesting Majid. Marketing and IT may never get along, but Marketing and Procurement could certainly work more closely together. We have a few clients where these functions work very well together and make the buying process better for both sides of the table.
RFPs are evil and should die a slow, painful death.
The entire process is flawed and there are much better ways to assess capabilities without asking agencies to give away thinking that they normally get paid for. What other industry gives away the only thing they have to sell? Besides, someone ALWAYS has the inside track. And if it isn’t you, then why are you wasting your time?
Please read Blair Enn’s “Win Without Pitching Manifesto” and then let’s talk. http://www.winwithoutpitching.com/manifesto
I’ve been using the method for years – and it works. Very, very well.
I think RFPs are a necessary evil.
Dachis Group offers different types of services, some of which are bought and sold in agency-like fashion, others which are more consultancy relationship-based sales.
While I agree with you and [I think] the philosophy of the Manifesto – every business chooses its own strategy (or needs to) and responding to RFPs, given the nature of industry operations today, may be required and a good business decision.
Don’t hate the player(s), hate the game, I suppose.
I’m one of those ‘evil’ procurement people and yes, I agree completely – I HATE templates, too many end-users think its a ‘shortcut’. They spend so much time talking in circles about what to do, that when they finally take action, they want the procurement dept to put out an RFP in 2 days. OR, I’ve had end-users find an RFP and decide “yep, that’s what we want” and post it themselves (then I get to come and help clean up the mess when they need to negotiate a contract for a bunch of things they don’t want/need nor understand completely).
If its any consolation, this happens for all types of services – I’ve had a school district issue an RFP for banking services and all throughout the document it referred to ‘university’ (because they copied a University’s RFP for banking services)…
Yes, RFPs are a ‘necessary evil’ – public sector gets grilled for negotiating ‘taxpayer’s money’ directly without a competitive process – and private sector companies have major customers lobby for ‘reciprocal business’ If I could come up with a better way, I would…I’m still trying to figure something out that won’t have taxpayers complaining, nor major clients threatening to take their ball and go home…
Given that the classic RFP process is a combination of art and science, it seems that we should have seen a semantic web solution by now. Maybe it’s an opportunity for someone to develop an offering here, similar to the vertical exchanges developed years ago for materials sourcing.