When done right, Requests for Proposals (RFPs) will lead to more relevant and revealing responses from vendors. Alas, most RFPs become overly vague and feature-driven, rather than outcome focused. We can do better.
Over past seventeen years, thousands of our subscribers have relied on Real Story Group research, advice, and templates to help build their RFPs for customer experience and marketing technology selection. But of course a good template alone won’t guarantee success.
Understanding your business case and technical requirements is half the battle. In this case I’ll write about the other half: how to actually write an RFP that will attract proposals that will specifically answer your needs.
In technology product selection, as in life, the key to differentiating among possible alternatives is clarity. Vague, wordy RFPs (or "tenders") only beget vague, wordy responses that fail to adequately clarify your choices.
You can really help your enterprise by removing conveniently ambiguous buzzwords. Here's four terms you should seek out and eliminate from any RFP.
All too often, this word makes you and the vendor co-conspirators in postponing discussion of the hard work coming your way.
Making systems "talk to each other" can be surprisingly easy or devilishly hard — but usually the latter. Unfortunately, it can be very difficult to know in advance just how hard, so companies tend to postpone a meaningful discussion of specifics during the technology selection phase. That's bad.
Instead of vaguely asking whether two systems can integrate, come up with some actual test cases. Articulate specific needs for read- or write-access to repositories, as well as event-triggers across systems. Describe all-important customer experiences as they complete tasks that span back-end platforms. Then you'll begin to start laying a roadmap for integration -- without ever having to use the word.
Extra credit: lose the word seamless too. Seams are part of the fabric of all software. They allow specific systems to be good at distinct things. Focus on where, when, how, and why you'll want to stitch those things together.
Intuitive to whom? Vendors are justifiably proud of their tools and always deem them easy to use. Yet many if not most customers report significant usability problems even with simpler enterprise platforms.
A related no-no word is "easy." What does easy mean?
Instead focus on usability. Usability is fitness to purpose. Therefore, you need to discover your colleagues' true purposes in employing any tool. Note that different personas are going to require different experiences based on distinct purposes, so perhaps the most "intuitive" solution is the one whose screens are most readily modifiable.
This is a useless marketing term typically employed by vendors and their analyst shills. Don't ever type it yourself.
What most people mean here is "richly capable." That sounds like a good thing, but richness brings complexity, so If you mean "multifunctional," or "extensible platform," you may unintentionally mitigate against the ease of use we were just seeking above.
Get clear about the functionality you're looking for, and try not to buy any more than you need, since "robustness" always comes with a cost...
"User" is another vague word that allows you to avoid clarifying key personas. Trust me: you will want to enter any technology procurement with a clear list of actors and their roles in any system. That enables you to better ensure that features match their needs (see #2 above).
So go ahead and eliminate your users. And then raise up the people who really matter: Customers, Colleagues, Customer Service Reps, Managers, Prospects, Partners, Distributors, Suppliers, Developers, Designers, Authors, Editors, Data Analysts, Community Managers, Marketers, Executives -- the list is endless.
But for the system you're trying to build, I'll bet there's a handful of personas that matter a lot. Call them by name.
In sum, these four poorly defined marketing jargon words deprive you of the opportunity to tell vendors what you really want, and gives them the opportunity to wave their hands while seeming to respond to your requirements.
Let's End on a Positive Note
Here's a word to employ more frequently at the beginning of any question:
Vendors differentiate less on what they do than how they do it. Care about REST-based APIs? Join the club; nearly everybody does, and almost every vendor will check that box when you ask. So instead inquire something like, "How does your system expose and track REST-based APIs?" You'll get a much more useful answer.
If you need help with technology selection, please don't hesitate to call on my colleagues at RSG.