Lose The RFP Mindset When Selecting A CRM Solution

3
128

Share on LinkedIn

The traditional RFP-driven vendor selection process is heavyweight and often has undesirable outcomes:

  • The RFP process it time- and resource-consuming. Forrester estimates that CRM vendor selection projects take six to 12 months to complete. The effort involved to compile detailed requirements often produces something resembling a programming specification rather than a concise statement of business process needs.
  • Outcomes are often undesirable. The more onerous the RFP process, the more likely it is that some of the more viable candidate vendors will opt out  after determining sales considerations costs and reading the tea leaves of the competitive situation. When this occurs, mediocre or unqualified vendors may be the only ones left to choose from.
  • Failure to differentiate among mature products or identify innovators. RFPs only include requirements that buyers can envision now and generally look quite similar to capabilities that vendors can deliver in current releases rather than more visionary features that don't exist in many products today.
  • Vendors gain the upper hand. Vendors often have much more experience with RFPs than the buyer. A cagey vendor will look to circumvent the formal process by influencing executive decision-makers informally or disrupting the process if it is not going its way. Slick sales presentations and RFP responses often gloss over product weaknesses.

You should consider a proof-of-capability evaluations based on business process requirements and less on checking off functions and features. How do you do this?

  • Organize. Define a charter that consists of a concise statement of strategy (i.e., vision and rationale), scope, objectives, resources, and time frame for the project. Define a project team that includes an executive sponsor, a project director or team leader, and a project team composed of business and IT professionals with a vested interest in the outcome. Create a summary of the  business and technical requirements to identify candidate vendors.
  • Narrow. Screening the vendors at this stage is a vital task that should result in a shortlist of two to five vendors — ideally three — for further consideration. Determine whether to give incumbent vendors priority based on integration and license upgrade opportunities.
  • Evaluate. Detailed demonstrations are critical. Demos put the software through the paces of performing business process scenarios directly relevant to your business requirements. Provide scripts to the vendors a few days in advance to give them time to prepare. In addition to the business process capabilities, you should also focus on usability, flexibility and supported technology standards.
  • Decide. A proof-of-concept (POC) trial is useful in some cases — when technically feasible and when you need additional assurance before making a major financial commitment. 

Republished with author's permission from original post.

Kate Leggett
Kate serves Business Process Professionals. She is a leading expert on customer service strategies. Her research focuses on helping organizations establish and validate customer service strategies strategies, prioritize and focus customer service projects, facilitate customer service vendor selection, and plan for project success.

3 COMMENTS

  1. It’s extremely important, if you’re going into a CRM hunt, to make sure you look for a simple solution. You have to have first-hand experiences with your CRM options, both by participating in demos, watching product videos, and taking advantage of trials, in order to truly experience the day-to-day process in the CRM.

    If it isn’t simple enough for your team, you’re in for a world of hurt.

    Brad Hodson
    JobNimbus, http://www.jobnimbus.com

  2. A demo to the project team is necessary, but it is also inherently one-sided. In a large organization, it is not enough for only the project team to have hands-on. It will be more telling to have focus groups (subsets) of varied departments take the application through its paces — and there should be a collaborative “reporting out” process.

    Only then will a project team be informed enough to know whether the selections work for the intended users. And weaknesses, missing critical features, and gotchas will show up, too.

  3. @Vernessa, absolutely agree. Demo is just the first step, but getting beyond just the “decision makers” and getting the opinion of key members of the organization who will be using the software on a daily basis is beyond necessary.

    Wish this would happen more often, though.

ADD YOUR COMMENT

Please use comments to add value to the discussion. Maximum one link to an educational blog post or article. We will NOT PUBLISH brief comments like "good post," comments that mainly promote links, or comments with links to companies, products, or services.

Please enter your comment!
Please enter your name here