CRM Software RFP Failures, Fixes and Alternatives
Most CRM software Request for Proposals fail to identify measurable weaknesses, limitations and differences among competing CRM solutions.
There are three methods to improve upon ineffective RFPs. You can fix them for moderate results, append them for better results or replace them for the best results.
Design Thinking has become the preferred alternative to the RFP as it focuses on what's most important, surfaces differences among competing CRM systems and is completed in a fraction of the time.
Customer Relationship Management (CRM) software selections often start with a Request for Proposal (RFP) document.
The purpose of a an RPF is to screen vendors pursuant to software selection criteria and down select a vendor short list of the highest fit CRM software applications.
But do RFPs really work for CRM software selection projects? And if not, is there a better alternative?
Problems with CRM RFPs
The RFP begins with the best intentions but almost always falls short in delivering an objective, measurable and meaningful comparison among competing choices. Here are some common problems with RFPs.
Instead of creating a dialogue they enforce a monologue. Unlike traditional back-office applications which are more standardized, CRM systems benefit from creativity and collaboration. However, RFPs are one-way requirements documents that demand responses to fixed questions. They fail to solicit ideas and experience from the vendors who have the most to offer.
Most CRM RFPs fail to define the business problem to be solved. Instead, they assume if they ask for enough CRM software capability the business problems will take care of themselves. Seeking an abundance of software technology for a business problem that hasn't been thoroughly defined or believing that technology alone will remedy business problems is naïve thinking and leads to very disappointing results.
Most CRM RFPs are little more than exhaustive requirements lists of undifferentiated requirements. They over emphasize the verification of routine software features, functions and capabilities in what then becomes an arms race among vendors. The reality is that CRM software is a very mature industry and the market leading applications have created needed functionality over decades. In fact, CRM software research shows that most CRM adopters use less than 30 percent of CRM software capabilities. Acquiring more functionality than goes unused reduces CRM software ease of use and increases IT maintenance cost.
Many CRM RFP responses are often biased to the point of inaccuracy. CRM software vendors often answer the questions in ways that apply creative interpretation to artificially over promote the application. This is why the majority of CRM RFP responses show that the applications do pretty much everything. Recognize that most CRM software vendors are less inclined to apply fair or deep consideration to a voluminous list of questions and more motivated to find a plausible confirmation, defendable response or semi-justifiable reason to advise than any or all requirements are satisfied with the application. In fairness, most RFPs ask broad and generic questions that grant latitude and are subject to personal interpretation. Many times, vendors are forced to make assumptions or guesses because the questions are broad or insufficient.
CRM vendors do not stand behind their RFP answers. I've been in this business for more than 30 years and let me be clear that almost all vendors will not append their CRM purchase contract with any part of their RFP response. CRM purchase agreements include one or more of those complete agreement phrases, you know, something like "This Agreement is the complete and final agreement and supersedes any course of dealing, discussions, or representations between customer and vendor." So, if the vendor won't stand behind their RFP responses how can the customer put weight or confidence in them? Short answer: you can't.
If the RFP does not surface the weaknesses and limitations for each CRM software solution – and they almost never do – it is not a worthwhile effort. Even worse, it creates a false sense of due diligence and promotes invalid CRM software selection decision making.
3 CRM RFP Alternatives
Rather than creating a laundry list of undifferentiated CRM software requirements, a Design Thinking workshop surfaces a short list of the most significant objectives.
It's a shift from trying to validate hundreds of software requirements – most of which are common or of moderate value – to a laser focus on the dozen or so capabilities that drive the biggest business impact and will absolutely make or break the implementation and postproduction success.
Design thinking is an iterative, people-focused design and problem-solving method that applies deep empathy for users and collaboration among multi-disciplinary teams. This approach solidifies the highest impact and most important success criteria; measured in user, customer and business outcomes; and according to the people who will most use or benefit from the CRM software.
What makes this approach different and better is that it shifts CRM objectives from being measured in software features and functions ― which frankly most users and managers don't care much about ― to being measured in user and customer business outcomes ― which users and managers care deeply about.
That's a profound shift that does two things. From a business performance perspective, it aligns the CRM software to support the company's top business priorities, and from a technology perspective, it directly increases user adoption, software utilization and technology payback. This approach also allows validation of all the key requirements in a follow-on CRM software demonstration. The CRM demo is the place to confirm requirements important to your goals and selection. However, due to setup and time constraints, CRM software demonstrations can generally only validate about one to two dozen meaningful capabilities.
Design Thinking has become the preferred alternative to CRM RFPs because the process focuses on what's most important, surfaces measurable differences among competing applications and requires a fraction of the time. Compared to an RFP process that may consume weeks or months, a design thinking workshop is performed in one or two days. But be clear, for most companies, it's not just faster, it's better.
Request for Information (RFI)
Consider an RFI instead of or in addition to an RFP. Another problem with RFPs is that the requirements are set by people who may not be well versed with how CRM software can solve business problems. RFIs are less rigid and more collaborative. They solicit ideas and permit the vendors to demonstrate things the customer didn't know to ask for.
Improve the Request for Proposal
Most CRM software buyers perform RFP processes because they are aware of no better alternative and it's what's always been done. It's easy to stick with what you know even if results are mediocre at best. If creating an RFP is a requirement at your company, then consider adopting Request for Proposal Best Practices.