In the CRM purchasing process, a common sequence of events for CRM buyers is to first go through a round of vendor demos and to then decide on and commit to a specific CRM vendor. After the purchase of the CRM system, the next step is to go through the exercise of defining detailed CRM requirements. Finally, a CRM implementation is performed based on those defined requirements.
However, if there are definitive plans in place to move off an old CRM system and onto a new one, it can often make more sense to alter the sequence of some events. A less risky path for many organizations may be to go through a CRM requirements definition exercise in advance of actually committing to a specific CRM vendor.
An up-front, requirements document is different from a traditional, CRM RFI/RFP exercise. RFI and RFP documents and spreadsheets can often become exhaustive collections of “must haves”, “should haves” and “nice to haves”. They may lack depth and be more feature-oriented than process-oriented.
A CRM requirements document should include, among other things: current pain points; a catalog of existing systems; an overview of the current state; a picture of the desired future state; integration priorities; XRM (non core-to-CRM) requirements.
What are the benefits to defining detailed CRM requirements before committing to a specific CRM vendor?
1. Develop a Services Budget Early On
A lot of excitement can be generated around a chosen CRM solution. However, if a services budget is not factored in early on in the CRM buying process, the process can grind to a halt once an implementation services estimate is received. The time and effort that was expended on scheduling and attending vendor demonstrations does not result in a CRM product decision due to unexpectedly high services estimates.
Sometimes, the starts ticking on a CRM subscription before a services budget is determined. When the services estimates are much higher than expected, the new CRM system can go through a much more costly “shelfware” phase.
Both scenarios can be mitigated via a “requirements first” approach.
2. Speed up the CRM Buying and Implementation Process
Companies that send out RFIs and RFQs may be inadvertently slowing down the overall purchasing process. The assumption is that vendor demos, based on the information provided in an RFP, will result in a clear consensus as to which CRM system to select. However, a demo-driven buying process can often result in even more confusion, as most CRM vendors are able to provide ample evidence as to why their solution is better than the competition’s.
Ironically, the overall CRM buying process can be sped up by slowing it down. Being more clear about specific requirements earlier in the process can result in a quicker product decision.
If CXOs are involved in discussions during the requirements gathering and definition process, light will be shed on business benefits of a new CRM system that they may otherwise have been aware of. This alone could drive a faster decision.
3. Get CRM Vendors to Demo More Closely to Requirements
When detailed CRM requirements are developed in advance of vendor demos, vendors will be able to better understand and therefore better address specific requirements during their demonstrations. The demonstrations will be more tailored to a company’s specific needs if detailed requirements are provided to the short vendors – compared to a high level list of requirements within an RFP.
4. Decide What Related Systems or Add-Ons May Be Needed
CRM systems have an increasing number of related third party technologies within their ecosystems.
Microsoft has AppSource Salesforce has AppExchange and Sugar has SugarExchange.
A similar, “requirements-first” approach should also be taken when evaluating certain third party applications across different CRM vendors, especially the more feature-rich ones such as project management and CPQ apps.
5. Gain Additional Time to Refine Requirements
If the detailed requirements phase begins early in the process, there will be more time to make iterative adjustments to those requirements. Often, detailed requirements are passed around the organization for review and comments. Over the course of time, a requirements document may be updated. Previously defined requirements may be re-prioritized.
The earlier in the process that detailed requirements are defined, the more opportunity there is to fine tune requirements in advance of a CRM implementation.
Conclusion
A requirements-driven CRM evaluation process can provide a number of important advantages over a traditional, demo-driven or RFP-driven process.
