The words had been thoughtfully picked out for me by the sender in yellow, but it would have been pretty striking without the highlighter. It was notice for an invitation to tender, and it contained the interesting condition that for anyone choosing to enter a cost of up to 2,000 Euros would apply.

Now perhaps I’ve lived a sheltered existence, but I’ve never seen an invitation to tender issued before where prospective vendors have to pay to take part. This was a condition of an invitation to tender for CRM development services. We don’t provide CRM development services, and so have no specific interest in this tender other than this ‘pay to play’ practice strikes me as wrong in several respects:

It’s unfair – It’s tough enough anyway for vendors. Responses to invitations to tender can involve weeks of work soaking up the time of people throughout the business. Should the vendor be lucky enough to be short-listed they have another round of work putting together presentations, demonstrations, and reference visits. The costs of this process can be huge, and given that by definition most prospective suppliers will be unsuccessful, it strikes me as morally suspect to ask vendors to stump up an additional ‘entry fee’.

Read more »

He was the last of the Mohicans. As I watched him he followed the prescribed process. The system hadn’t been well set up, so it was a prolonged and laboured procedure, but he followed it to the letter, key stroke after key stroke. This would have been great if everyone, or maybe even anyone, was doing the same. But they weren’t. His hard work was in vain. A waste. The system was long since obsolete.

Read more »

There’s an old joke that goes something like this:

A man, driving through the countryside, stops to ask a farm worker for directions to a local town.

The farm worker scratches his head thoughtfully, and after a while, says ‘you know sir, if I was going there I wouldn’t start from here at all.’

This surfaced in my mind when I was asked for advice from a company implementing CRM, but, despite focusing on a simple contact management phase to start, were struggling to gain traction, particularly with some of the senior executive users.

I guess my advice was of the ‘I wouldn’t start from here at all’ sort, and may not have been terribly helpful, but my response was as follows:

Ideally when you deploy CRM, there are a clear set of ‘recognised’ problems that you are looking to solve, and compelling outcomes that you have in mind. The resolution of these issues would ideally have senior level support, and while this doesn’t guarantee usage, it certainly helps.

It sounds as if you are encountering resistance at an executive level though. This is a very difficult situation to overcome. If the executive team don’t support it, then it will be a major uphill struggle.

My suggestions for addressing the situation: Read more »

For those of you currently planning a CRM project, I thought it might be helpful to indentify some of the areas where things tend to go ‘off-piste’, but before I do perhaps it’s a good idea to suggest why we might care in the first place.

If the CRM project team come under time pressure, either through underestimating the time-line or through unforeseeable disruption, the, not unnatural response, is to try and speed things up. Unfortunately, often with limited things that can be sped up, this leads to cutting corners in some form or another. Commonly this manifests itself in dumbing down the requirements, reduced testing, and rushed training, which in turn invariably ends with user adoption issues which may ultimately prove insurmountable.

Therefore understanding which bits of the implementation process are prone to delay is a key way of effectively managing time-line expectations. So the following are my top six areas where people tend to get caught out:

Contract negotiation – you may have selected your CRM vendor quickly enough, but contract negotiation can be a major source of delay. Once matters reach the hands of the respective legal teams things rarely move fast. Read more »

One of the first projects we undertook after I set up Mareeba was to review a client’s call centre. The call centre supported computer equipment across the UK, and was something of a victim of success, struggling to cope with a series of large orders that the client had recently won.

One of the key issues the client had, was that they struggled to appropriately prioritise and action issues that had a high impact on their customer’s operations. As a result they were struggling to meet their service level commitments, creating ill will within the customer base, and incurring significant penalty payments.

As a solution we helped them develop new operational processes and implemented a new CRM system to support them. We developed and supervised a customised training programme, and then, after initial hand-holding, left them feeling rather good about what we’d done. Read more »

I’ve heard the concept of the golden sales sausage machine articulated many times in my career. In essence it goes like this: our sales people currently average say four appointments a week and they close one in four. Therefore if we crank up the lead generation to eight appointments a week instead of four, our sales will double.

On the surface the logic looks undeniable, and so the company cranks up the lead generation. The new appointment target is achieved, and everyone sits back and awaits the rewards. Which never come because the sausage machine theory has two key flaws:

Read more »

The phrase ‘CRM is complex, not because people want it to be’ which appeared in a tweet from Mitch Lieberman last week caught my eye, and, though I suspect I am using the quote outside of its original context, I wanted to write a piece about CRM complexity at least as I experience it – as an independent CRM consultant trying to maximise the pay-back from CRM technology.

Complexity is important because if you believe implementing a system to be a trivial task and it proves to be otherwise, the chances are you won’t be resourced for a successful outcome; rather like fuelling the aircraft for Paris, when the destination is Sydney.

In my experience there is often a yawning gap between perceived and actual complexity which means that many CRM initiatives are inadequately planned and resourced. I will expand on these complexities in a moment, but it’s also worth saying that CRM can be virtually complexity-free.

Read more »

In the last few posts I touched on why effective CRM requirements specification was important, and how to approach it. This week I want to wrap up this series by suggesting how this can be brought together in the final CRM requirements document.

Given that the structure of your document should be driven by its end purpose, it’s worth being clear about what it will be used for, which I believe comes down to the following:

• To facilitate agreement internally as to what you are trying to achieve and how you are planning to achieve it, ensuring a common understanding and that the initiative is adequately resourced.
• To define what functionality you will need to achieve your objectives to avoid choosing CRM software inappropriate to your needs.
• To allow vendors to provide accurate, rather than indicative pricing.
• To control and accelerate the implementation phase.

As such, I suggest a simple structure as follows:

Firstly, an analysis of the current situation, the problems you are looking to solve, and a statement of the desired outcomes. This should be as specific as possible.

Read more »

As I covered in my last post on CRM requirements gathering, the first goal is to define what sort of problems you are looking to fix, or what sort of beneficial outcomes you are aiming for. The next step, which I will cover in this post, is to define how you will use the CRM system to achieve those objectives.

Most CRM requirements documents that I come across on my travels tend to be a list of required functionality. There is curiously little mention of process – i.e. how the technology will be used.

There are a number of reasons why process is important in CRM requirements gathering. CRM technology is just a tool set, and unless you can define how that tool-set will be used to reach you objective you aren’t going to get there. It’s very much like travelling, you need a destination, but if you are going to get there you need to figure out the route as well.

Read more »

Last week I described why I felt a detailed set of business and functional requirements was essential to a high pay-back CRM project. Over the course of the next few posts I intend to set out some thoughts on how you can go about creating them.

The ‘big’ point in terms of this post is that you need to be clear about what problems you are trying to solve or what compelling outcomes you are looking to achieve. This may sound fairly obvious, but I see a lot of CRM requirements documents in my travels, and very few of them have clearly stated business goals.

There are three reasons why I think being explicit about your outcomes is important. Firstly, it acknowledges that you understand that technology is a tool. It won’t produce value on its own. It needs to be used in a coordinated way to produce results, and there are many and varied ways in which CRM technology may benefit your business.

Read more »