This is part 3 of a series on choosing a Customer Reference Management Solution.
It’s a well-accepted fact that defining what you want improves the odds you’ll get what you want in just about anything in life. It’s no different with customer reference management systems (RMS). I generally think of requirements in two flavors: 1) What’s needed to support the existing environment?, and 2) What changes do you hope to achieve that a new solution must support?
Documenting the current environment is pretty straightforward. Caution: It is tempting, if your program has been up and running for a while, to want to replicate much of the environment as it exists—even the rather, uhm, peculiar practices that have evolved over time. Our recommendation: Keep an open mind. If you work with a vendor that has capitalized on the best of each client’s thinking and effectively packaged it into its solution, you could realize a lot of unexpected benefit by adopting new processes, practices and workflows.
Now depending on which route you’re considering: a custom solution built in-house or by a third party, an on-premise “shrink wrapped” package, or a hosted (Software as a Service) RMS, it’s critical to understand what’s possible in terms of customization. If you intend to build an RMS then customization is only limited by your financial and time budgets. Make sure you write the specification very carefully because scope creep is almost guaranteed to cause you delays and significant cost overruns. With on-premise and hosted options you should fully understand what changes require actual code changes versus configuration changes.
We’re obviously most familiar with our own SaaS solution. Just about every aspect of our application was designed to be configurable: some by client administrators, some by our staff to help prevent problematic configuration changes. Should you go the SaaS route, be sure to understand a vendor’s configuration limitations, what’s billable if you need something that isn’t currently in the system, and how enhancement requests are addressed.
Here are some universal considerations we’d advise you to include in your requirements:
Documenting the current environment is pretty straightforward. Caution: It is tempting, if your program has been up and running for a while, to want to replicate much of the environment as it exists—even the rather, uhm, peculiar practices that have evolved over time. Our recommendation: Keep an open mind. If you work with a vendor that has capitalized on the best of each client’s thinking and effectively packaged it into its solution, you could realize a lot of unexpected benefit by adopting new processes, practices and workflows.
Now depending on which route you’re considering: a custom solution built in-house or by a third party, an on-premise “shrink wrapped” package, or a hosted (Software as a Service) RMS, it’s critical to understand what’s possible in terms of customization. If you intend to build an RMS then customization is only limited by your financial and time budgets. Make sure you write the specification very carefully because scope creep is almost guaranteed to cause you delays and significant cost overruns. With on-premise and hosted options you should fully understand what changes require actual code changes versus configuration changes.
We’re obviously most familiar with our own SaaS solution. Just about every aspect of our application was designed to be configurable: some by client administrators, some by our staff to help prevent problematic configuration changes. Should you go the SaaS route, be sure to understand a vendor’s configuration limitations, what’s billable if you need something that isn’t currently in the system, and how enhancement requests are addressed.
Here are some universal considerations we’d advise you to include in your requirements:
- Usability: First and foremost in our book is usability. A good interface should be relatively intuitive. Foreign or “techie” terminology shouldn’t exist. Help should be in context or easily accessible online. This is a hard one to articulate, but is the interface friendly? Seems a little “touchy feely”, but user adoption is as much art as science and this is a factor that shouldn’t be minimized.
- Reference Requests: Will the RMS support your needs with respect to requests for references? Are you supporting just sales, or PR, AR, IR and other functional groups in the organization? Will requests be handled by different people based on region, product, channel, etc.?
- System Integration: Will the RMS need to leverage data from other applications such as a CRM or content management system, or a portal? If so, what options are available? With respect to CRM applications, check to see if the RMS is certified for your CRM application (e.g., Salesforce.com).
- Security: Is single sign on important to you? How might the RMS support this need?
- Product Hierarchy: If you have a complex product hierarchy (e.g., solution, product family, products, versions, etc.) be sure to have a clear explanation of the capabilities and limitations of an RMS in supporting these needs.
- Search: After you understand how users—Sales in particular—search for information, confirm that the RMS provides a compatible search model. Searching a customer reference database isn’t quite like using Google for many reasons, but search should meet the needs of your primary audience.
- Reporting: Will the RMS provide the type of reporting you need? Our experience has been that flexibility is the key attribute when it comes to reporting. The information needs to be easy to get out of the RMS for use by others who will inevitably want data from your RMS. So the export capabilities should be evaluated.
- Rewards: Most of our clients attempt to place a value on various reference activities (calls, blog entries, site visits, etc.) either for their own internal tracking, or for redemption by customers at some point in the future. Know how points are awarded, redeemed and reported on in the RMS’s you evaluate.
- Language Support: If you’re a global reference program, or plan to be, make sure you understand what the vendor has done to accommodate different geographies’ needs. At a minimum it should be possible to store customer content in a variety of languages.
- Reference Pipeline: Like the sales team, the reference program must take leads (nominations in most cases) through qualification and onto commitment (program participation). There’s usually a quota for the program as well. What features does the RMS have to support this process and related reporting?
Now, take your list of requirements and assess each item. Is it a “must have” and if so, why? Is it a nice to have? This will help you set your priorities and zero in on the highest value features during your evaluation.
Next up: Developing scenarios for an easier apple to apples evaluation of your vendor short list.
Checkout the complete Choosing a System podcast series.
No Comments so far ↓
There are no comments yet...Kick things off by filling out the form below.