Now you’ve implemented your new system, why do you need to have a central CRM Change Log.

Building on our CRM documentation theme from last month’s blog, for most implementations, we recommend that customisations are kept to a minimal during the important initial rollout period but there are always likely to be requests for additional ad hoc customisations as your team start to use the system in earnest.

This should be encouraged since it is a great indicator of User Adoption enthusiasm.

They will also start to provide you with new suggestions on how CRM can be improved or developed. One good example of this is the use of workflow automation, for example, the automated email to a client who has just logged a support call giving the details logged and their Case reference number.

All these enhancement suggestions need to be fed through to the Administrators and the original Project team or Steering Group, together with your consultants for their own advice and input. Not all suggestions are feasible or right at a particular moment in time.

Now, often during a project, your Lead consultant will track Change Requests in a log and after implementation this CRM Change Log needs to be continued and maintained by the Project team and Administrators.

One of the big issues we find, especially during migration or taking on a new client, is there being no real documentation on any of the changes that have been made to the original system. In many instances, the Administrators after their own training, are itching to create and add new fields or customise screens, but this needs to be controlled and managed.

Our advice is to create a centralised CRM Change Log document, listing the reasons and the rationale for these changes. This can be a simple MS Word or MS Excel covering the key elements of why the changes need to be made. This document may be stored centrally, often within the global documents section of many CRM systems.

This change log needs in my view should include most of the following:-

• Suggestions source, after all you want to credit those people giving suggestions.

• Nature and rationale for the change.

• Authority

• What was done and by Whom and When

• Notification method to inform the user, for instance, email or ad hoc training which then relates to...

• Amendments made to documentation, e.g. CRM playbook updates

These changes should always be authorised which is why we always suggest where possible a minimum of two Administrators, with one being part of IT to consider the system implications of any changes. For example, the adding of a new field. Does this impact on any other processes or more often on any Reports/Dashboards which may also need to be updated to show the extra field.

After Go-Live the CRM Change Log should be kept centrally and easily accessible and the Project team should really meet once a month, possibly every two or three weeks in the all-important first 90 days. These Change Requests all need to be approved and if required, budget approved if you need your external consultant is needed to implement these changes.

On this topic, in the first six months after Go Live you still need to maintain a close contact with any external consultants as they can advise on best practice and call upon previous experience. The first three months are the most critical in any CRM project and when need to ensure your on-boarding User Adoption process works.

If you are interested in our CRM Log book and Change Request template, then please feel free to email gary@thecrmcloud.co.uk.

Gary Perkins