Success is not All About Features

The relationship with your CRM vendor doesn't end when the contract is signed. Some would even argue that the relationship starts at the time the contract is signed. And the relationship doesn't end when the implementation is complete, either. In fact, you are looking at many years of working with a CRM vendor as the tool goes through several upgrades, additional customizations, and integrations. Once in place, CRM tools often outlast key stakeholders, organizational structures, even business models. So the choice of the tool should be viewed as the choice of a long-term partner, not as a mere decision on features and functionality. The interesting dilemma in the CRM field is that a lot of the creative, leading-edge functionality originates from small vendors, who are inherently less stable than more established players. The CRM field has seen a large number of mergers and some outright failures. When a vendor disappears entirely, its customers are placed in a difficult situation: they suddenly find themselves with unsupported systems, perhaps at critical times for their needs, while they must consider another large investment to purchase a replacement that will be supported in the long run. If they had chosen an ASP solution, they may even become unable to access their data (let alone use the system) from one day to the next. Outright failures have been relatively rare, but mergers are common. Tools from vendors that undergo mergers are typically supported "as is" (with no enhancements) for many months, sometimes years, and occasionally forever, if there is such a concept in the technology arena. In the case of an acquisition by a competitor, the typical scenario is that the acquiring company provides support for a year or so, then offers to migrate customers to the other tool. Migrating systems is not a trivial affair. As discussed in , "Auditing your CRM System," facing a migration should trigger a reassessment of your CRM strategy rather than an automatic agreement to proceed with it. In the case of a migration inspired by a merger, at least you would not be in a situation where you would be left completely stranded with no notice. What should you do if you need a specific functionality that is only provided by a smaller, less stable vendor? One possibility is to wait a little while. There is a great deal of leap-frogging happening on functionality, so if there's a good idea out there, it will eventually be picked up by a larger, more stable company. Sometimes such a vendor acquires the smaller, innovative vendor, but not always. In a leapfrog environment, what counts most is the ability of the vendor to pursue a long-term strategy of continuous product improvements. An important part of assessing your vendor's stability is to look beyond the current features or the current size of the company and to evaluate the vendor's commitment to product marketing and innovative development (which depends in part, but in part only, on financial stability). Always include vendor requirements in your list, even if you need to bend them later on.

Vendor Requirements

What should the vendor requirements cover?

  • Financial viability. Is the company successful and likely to remain successful? If the vendor is a public company, it's easy to get a hold of its financial results and, assuming they are properly audited, to analyze its prospects. Private companies are more challenging. While some may be willing to share some financial information under a non-disclosure agreement during the sales cycle, it's a lot more difficult to evaluate this information. In the end, you will have to make a leap of faith based on your analysis of their success in the market. Remember that all successful, large, public CRM companies started as small, private outfits (as did hundreds of others that did not make it).
  • Customer references. This is, for me, an essential criterion, unless you are willing to take a chance on a wonderful and unique technology—and you have a good backup plan in case things don't work out as you had hoped. With smaller vendors, check references early in the evaluation phase so you don't waste your time on candidates that do not have appropriate references. An appropriate reference is a customer in a field similar to yours, using the tool in approximately the same way as you will, and with about the same number of users. For example, if you provide financial services, a reference from a software company is not that useful. If you are looking for a marketing automation system, a support-tracking reference is not what you want. If you want to implement with 300 users, a reference with 20 users is insufficient. (The opposite is not that great either: the 300-user reference is likely to have vastly more resources available to implement the solution, and they may need complicated features that would just get in the way of your small organization.) We'll come back to the art of getting meaningful references in , but it suffices to say that you should define the kind of references you would seek as part of the requirements checklist.
  • Geographical presence. Although I can't imagine picking a vendor solely because it is in your backyard, there's much to be said about accessibility, both in the short term and long term. Taking this point to extremes, would you buy a system from a vendor that's headquartered on the other side of the world, with no local sales force where you are? If you had a choice of two vendors, one local and one remote, would you be more likely to go with the local vendor? Be sure to consider not only the availability of the sales force, which is often quite good, but also the availability of support and other post-sales services for the long-term.
  • Business model. Is ASP acceptable? Desirable? Required? Is a dual model (ASP and packaged) important?
  • Technical vision. Can the vendor articulate a technical vision? Does the vision make sense? Does it match your needs? Do you believe the organization is likely to sustain the technical vision? For instance, is there a strong CTO? Do you see a depth of technical leadership within the company beyond a key individual? (This last point is important for a small vendor: if the CTO were to leave, would the company survive?)
  • Business vision. Is the marketing and business development strategy attractive? Does it put you and your needs in the center of the vendor's focus, or on its margins? If you like the business vision, do you think the vendor is likely to be successful with it?
  • Attention to customers. Better vendors use a better sales process, provide more customized responses to RFPs and other requests, and in general lavish more attention on their customers. Don't mistake pre-sales attention for post-sales support quality (we will address post-sales support quality in section 8) but do take into account the quality of the pre-sales process when evaluating the vendor.

For convenience, all the requirements discussed in this and future sections are summarized in checklist format at the end of this chapter (section 9).