A few key points...

The following are notes from a presentation I gave last week which boil down a lot of my thinking on implementing CRM systems:


The challenges of implementing a successful CRM system are more numerous and complex than might appear to be the case. In this respect there are a number of key points we would raise about implementing CRM technology:

CRM technology on its own can not produce results.

The project should have clearly defined business goals.

The processes required to achieve those goals should be embedded in the technology in a way that is intuitive and ergonomic for the user.

Projects generally benefit from being broken down into bite-size pieces.

Training should be given to all users in the context of the organizations processes and that substantial training resource is put in place to ensure initial user take up.

While critical to success, the challenge of achieving consistent and structured usage over time is generally significantly underestimated.

On the other hand the returns on investment of running a successful system are frequently underestimated, and can become a very significant source of competitive advantage.

Reporting should be delivered from the system and will become a key means of validating that usage is occurring in a structured and consistent manner.

There should be an active administrative resource monitoring that defined processes are being followed and that the quality of data being entered into the system is high.

There needs to be active executive sponsorship particularly in respect to addressing resistance to usage. If the management are not using the technology as a tool to manage the business the system is unlikely to provide any material return on investment.

Training is provided to new staff joining the organization in a timely manner and in context to the business processes they will be undertaking.

There is an effective change management programme designed to ensure the system is enhanced over time and adapts to the changing needs of the business.

It should be noted that this approach will involve a higher overhead than currently incurred and will be more demanding on management time, however we believe that the benefits of the additional investment will, if successfully executed, significantly outweigh the additional costs involved.

As yet unbranded...

A slightly revised Anita Clifford interview is now on the Mycustomer.com web site. This will now be a regular feature of both sites (though appearing here first of course). Mycustomer.com wanted the interview up on the site as soon as possible. Rather too soon for us to come up with any branding for it, at least that everyone agreed on. I thought ‘Talking Shop’ was a pretty sound suggestion, but Neil Davey the editor was considerably less keen. So at the moment it remains unbranded. If anyone has any bright ideas feel very free to drop me a line!

What a CRM consultant would tell you about buying CRM software - part 3

As I’ve noted previously, the key foundations to effective purchasing are to define a detailed set of requirements, and in light of those requirements assemble a group of relevant technologies and capable vendors to select from. Step three is to prepare and distribute a request for proposal (RFP) document in order to better evaluate the available options. While some purchasers are inclined to skip this stage, and start directly auditioning potential suppliers, as I’ve mentioned in a previous post (from which I’ll briefly quote) this can be a risky approach:

‘From my time as a CRM vendor, I'm all too aware how easy it is to script a demonstration in a way that showcased the offering’s strengths and skated over the weaknesses. As a CRM purchaser, faced with assessing a dozen seemingly similar CRM offerings, I’m acutely aware how difficult analyzing the differences can be - even with the benefits of years of experience, and a reasonably tutored eye.’

When you initially receive written submissions from a vendor it gives the opportunity to compare and contrast the offering in a much more structured and analytical manner, and gives you a basis for action should disputes over what was promised arise in the future.

Our goal though with the RFP document is to strike the balance of getting the information we need, while making it as easy as possible for the vendor to respond. If we make the RFP too onerous then we run the risk of potential suppliers electing not to bid. As I mentioned before a good vendor is likely to be a busy vendor, and they will weigh carefully the potential for successfully winning the business and the time/cost involved in preparing the response, so I like to keep the latter element as light as possible.

Our RFP document sets out how and when the vendor should respond, and then prompts the would-be supplier to respond in a number of areas as follows:

Questions relating to the profile of the software and its developer.

Questions relating to the profile of the software vendor/implementer, particularly in relation to support capabilities, implementation approach, and experience with similar projects.

Cost structure including a detailed breakdown of both vendor supplied elements such as software, services, training, and support and maintenance, as well as any non-vendor supplied elements that will incur costs such as hardware and database software.

The final element is a table referencing the detailed requirements document asking potential vendors to confirm whether they meet each item, and provide man-day estimates for any that will require customisation/development to deliver.

While some of the vendors we work with may choose to disagree, we find this approach is light enough not to discourage responses, while providing us with sufficient information to make informed judgments about suitable candidates for the next phase…to be continued.