7 - Maintaining and Evolving CRM
It's been mentioned that the primarily problem with CRM, the reason that it fails to deliver value, is because it is not utilized properly, and sometimes not at all. No system can create value merely by being obtained - it must be used, maintained, and evolved. The present chapter means to describe some of the ongoing tasks that are necessary to success.
Role of the Steering Committee
The notion of a steering committee was considered in the second chapter, but the author wishes to revisit it, as it is "of paramount importance" to the long-term success of a CRM program. Some of its ongoing focuses should be:
- CRM Evangelism - Continuing to promote the application of CRM within the organization, necessary because enthusiasm for a new technology wanes quickly.
- Executive Support - Next of kin to promotion is continued executive endorsement of the program, to give the employee4s the sense that it remains relevant.
- Change control and roadmap planning - ongoing efforts to address necessary changes and continue to evolve the program to ensure it remains effective and relevant as the business and the market change.
The CRM steering committee tends to met frequently during development, often weekly, to ensure that the project is progressing. Too often, the committee breaks up after the product launch. The author recommends scheduling meetings at least once per month to review results and assess needs. The agenda of these meetings may involve planning for the next release, but should largely shift to supporting the users of the CRM system.
Also, the participation in the committee will change, as many individuals who are critical to the launch of a new system have likely, and rightly, moved onto other projects, and others have taken over its maintenance:
- A program manager (possibly different from the project sponsor)
- Departmental "champions" remain relevant and represent the groups who use the system
- Trainers and other personnel who will offer initial training to new users and "booster" training to existing users
- IT personnel who monitor/maintain the application (likely different to those who built it)
Maintaining CRM
The notion of maintenance generally gets little thought - so long as the equipment is up and running, it is assumed that the system is up and running, and the program is progressing as intended. Basic equipment maintenance and troubleshooting are needed, but there are other maintenance issues that are often neglected:
The employees who use the system should not be forgotten: they will need practical support (training and assistance) as well as morale support (their work is recognized and valued); they will recognize inefficiencies in the system and identify opportunities for improvement.
Monitoring of both the systems and the people is necessary to confirm that operations are going as planned and recognize any issues that may arise. Where a system does not achieve its attended results, employees often quietly find a way to work around it. Recurring help-desk questions, common application errors, and even "water-cooler banter" can help to identify issues - and a tracking system should be in place to ensure they are considered and resolved.
When working with a vendor, it is common for them to provide support for a fairly short period of time. When this period ends, support for the CRM program often ends. It's important to consider what activities the vendor does that will still be needed after the service period terminates. Even when vendors provide ongoing support, they tend to place little interest in "old" clients in favor of newer ones, and can become neglectful.
The author considers user feedback to be essential - the user community should have a convenient and flexible method for submitting their feedback (the author specifically suggests e-mail). If CRM is controversial, such that employees may fear repercussions if they make any negative remark, an anonymous method of providing feedback is recommended. It's likewise important to have a centralized location where all feedback pertaining to the CRM system and program can be gathered, to ensure that it is tracked and considered. Having feedback received and responded to by random persons us inefficient, ineffective, and suggests a lack of coordinated support.
Providing support to program participants is essential. The author suggests having routine "help sessions" to provide a place and time to gather for support, as well as an office or help desk that can respond to on-the-spot needs. If it is not feasible t have round-the-clock support, set regular "office hours" for users.
Documentation will constantly need to be updated. System and application changes certainly need to be communicated, but the program and processes will also undergo changes. There will likely be ongoing bug fixes, modifications, and small-scale improvements that need to be documented.
The author's notion of documentation isn't merely technical manuals, but also training materials, announcements of new features, reminders about valuable functions, user success stories, etc.
Enhancing CRM
"Enhancing" implies making changes to the program or system, but excludes changes that are not intended to correct errors or cause things to go as planned in the first place (which are maintenance issues). Minor improvements that are made on-the-fly may technically be enhancements , but are often of so small a scope and impact they do not merit much planning.
The author advises a formal change-control process be put into place so that enhancements are handled in a coordinated manner - to avoid conflicts where one enhancement interferes with another, as well as to ensure budget is being spent on the most efficient and effective tasks.
The need for enhancement occurs when a user provides feedback regarding present operations or when someone (user or otherwise) identifies an opportunity. In general, the suggestion for an enhancement describes the change that is desired and the anticipated results of making that change.
Proposed enhancements should be submitted to the steering committee for consideration, who will consider the merit of a suggestion (intrinsic and relative to others), consider resources available as a whole, and authorize an effort to be undertaken.
An enhancement must be included in the roadmap and has the same components as any other project (planning, design, build, test, monitor, support, maintain), plus the requirement to consider the impact of the change on existing systems and operations: will it play nicely with the data storage and other applications, what impact it will have on users of the system. (EN: The author really belabors this, but it's repetitive and adds no new information.)
Of importance: any new version or upgrade to existing applications and systems may need to be treated like an enhancement project rather than installed as a maintenance task without considering the impact it may have. Especially when a system has been enhanced or customized, installing a new version or a simple patch can break things. (EN: it's also more extensive than the author suggests. Not only will an upgrade to the CRM software pose a risk, but upgrading other items, such as the server operating system, the database software, the e-mail server, or any system on which the CRM application depends, poses a risk.)
For on-premises applications, it is at least under the control of your IT department, who should have procedures in place for assessing, testing, installing, and troubleshooting updates to the systems they manage.
Where the CRM system, or components of it on which others may be dependent, is externally hosted and managed, a similar problem exists: the vendor is likely to make changes and upgrades to their systems that will change the functionality, and this often occurs with very little notice. Your CRM system could falter or fail altogether as a result. This should underscore the need to be in regular contact with such vendors, even after the initial project is completed.
There's a special warning for being a "beta" site for any vendor. The advantages are that you are often well ahead of other customers who use the same software, you often have more interaction with the vendor while they are coding their system (better insight, more accommodation), and the vendor may offer a price break - but the drawback is that beta software is buggy by nature and is constantly changing as the vendor is still working out the functionality. All of this can be very disruptive to your operations, and because CRM systems may have direct impact on customer experience, a bug can damage your customer relationships. Consider, very carefully, whether those benefits are worth the risk.
Monitoring the Vendor Ecosystem
Even after selecting and installing a given application, it remains important to continue to monitor vendors and products in the market to have a sense whether the application you have chosen remains the best choice for your needs, and whether the company that provides it remains viable in their industry.
The author suggests industry conferences as a way to keep track of how solutions are evolving. Solutions providers will be at conferences to flaunt their wares, and presentations will provide an indication of the innovative ideas in the CRM space. Conferences generally have separate "tracks" for management and IT, and both are important to consider.
The author mentions independent software vendors (ISVs) who often deploy solutions that combine stock products with custom software. Communications within this community readily identify which existing products are the best, what modifications they have to make to serve their customers, and what custom code they are doing that points to things that may become built-in features in future.
CRM user groups offer the same insight as ISVs, but from the management rather than technical side. While people are reluctant to share trade secrets with user groups, they have no reluctance to indicate problems and ask for help in solving them, which itself indicates what they are attempting to do and, at the same time, identifies flaws in the products they are presently using.
The author also (briefly) refers to blogs and discussion groups online, which his another method of getting first-hand accounts of CRM systems in use elsewhere.
Conclusion
The end-of-chapter conclusion reiterates some of the key points from the book. Primarily, that the benefits you achieve from using CRM will depend on the amount of thought and effort you put into it; that it is an ongoing program rather than a once-and-done installation; and it takes constant effort to maintain enthusiasm