How to document requirements for a CRM system – part 3

by Richard Boardman on November 23, 2014

I promised in last week’s post that this week I’d set out my views on what should be included in a CRM requirements specification. However, I’m going to put that on hold for a week. I realised there were some points that merit some articulation first. So, to help set the scene, here are a few things we hold to be true that shape our approach:

CRM software does nothing on its own – you don’t buy or sign up for a CRM application and it somehow miraculously transforms your business. CRM is a tool kit. Decisions have to be made as to what you are looking to improve and the system set up to achieve that objective. A lot of organisations get wrapped up in deciding what functionality they need, but give little thought as to how they’re going to beneficially use it.

People will not just tell you their requirements – this is where a lot of people get into trouble. They see requirements specification as simply about interviewing staff and taking notes. They expect them to be able to fully articulate what they need from a CRM system. In reality this rarely works. For a number of reasons:

Firstly, their knowledge of CRM technology may not be up to the job. They may never have used CRM software before, or their views may be rooted in an application they used many years previously. Their input can often be backward looking and may take little account of what’s possible with the latest technologies. Secondly, because users are often only able to describe a narrow set of needs directly related to their role, they generally miss the bigger picture. For example, I can’t remember that last time a user was able to describe key administration and security requirements. The point isn’t that staff input isn’t valuable – it’s essential – but it’s generally insufficient on its own to create a useful set of CRM requirements.

This isn’t something you an leave to the vendor – so the line of thinking sometimes goes: all I need to do is select a technology and then the CRM vendor or implementation partner will help me work out how to get value from it. While there’s a certain logic to this approach, there are also a few potential gotchas, given that selecting a technology first may leave you with a product that doesn’t meet your needs when the full requirements become apparent, and that being committed along a certain path undermines your negotiating position – a situation that some suppliers are only too happy to exploit.

However the biggest issue is that, as a rule of thumb (and I acknowledge there are exceptions), vendors/implementation partner just aren’t very good at working out how to apply CRM technology beneficially. This is slightly counter-intuitive, and you may simply have to take my word for it, but while they (generally) know the technology inside out, the – rather important – bit that trips them up, is working out how to apply it in a way that benefits the client.

So to wrap up, the nub of the preceding section is:

  • Spelling out how you are going to beneficially use the technology is at least as important as working out the functional requirements
  • Requirements definition is much more involved than simply asking the question ‘what do you need?’
  • This is not a stage you can easily skip and expect your selected supplier that doesn’t really understand your business to do in your place

Anyway that concludes things for this week, next time out I’ll outline my thoughts on the content of a specification.

[Facebook] [Google] [LinkedIn] [Twitter] [Pinterest]


How to document requirements for a CRM system – part 2

by Richard Boardman on November 16, 2014

In last week’s post I covered some of the common problems with specifying CRM requirements. In this post I want cover purpose. In other words what are we trying to achieve with a CRM specification. In this respect, I believe there are five key objectives:

1. Identify suitable technologies – by setting out the functional needs we should be able to identify which CRM software products meet our needs and which don’t.

2. Allow prospective vendors to quote accurately – from the document we want vendors to be able to provide realistic costs for implementing the system. The aim is to avoid purchase decisions being made based on estimates that later prove unreliable.

3. Facilitate internal agreement – the document should forge a common internal understanding of the shape and function of the system, so it’s clear to all which areas of the organisation will be impacted by the system and how.

4. Secure appropriate funding and resources – the specification should allow organisations to identify and secure the necessary budget and resources to deliver the system. This might appear to duplicate point two above, but there’s generally a much broader range of costs associated with implementing a system than just those provided by the selected vendor, for example infrastructure costs and the allocation of staff time to the project.

5. Smooth out the implementation process – a clear definition of the requirements up front, shortens the implementation phase, and reduces the likelihood of discovering new requirements which lead to project delays or cost overruns.

Perhaps the key takeaway from the above is that the CRM requirements document serves a much broader purpose than technology selection alone.

However, most of the requirements specifications I come across are largely just lists of functional requirements – often a few pages of bullet-points stating the system must/should/or could do X,Y, or Z. While this may assist with technology selection, it has little value in terms of achieving the other objectives listed above.

So if listing out functional requirements is insufficient, what should a requirements document contain? I will cover that in the next post

[Facebook] [Google] [LinkedIn] [Twitter] [Pinterest]


How to document requirements for a CRM system – part 1

November 10, 2014

As an independent CRM consultant I get to read a lot of CRM requirements documents, and it seems to be an area that most would-be buyers of CRM technology struggle with – probably because there’s little guidance out there about how to approach the exercise successfully. This would be less of an issue if this [...]

Read the full article →

Last quarter’s CRM market news in 60 seconds…

July 19, 2014

In case you missed them, here’s my 60 second bullet point round-up of the main CRM software stories last quarter: April take a cue from Amazon’s ‘Mayday’ customer support feature on the Kindle Fire to add a new SOS capability to its Service Cloud which enables customers to be connected to a support representative [...]

Read the full article →

Getting closer to the coal-face to get more out of CRM technology…

June 7, 2014

I’ve been having one of those ‘I’d long known it was important, but I’d forgotten just how important’ moments in recent weeks. One of our clients has recently gone live and, in the absence of a colleague who was away on honeymoon, I found myself providing go-live support which involved parking myself in the midst [...]

Read the full article →

Are people really using your CRM system? Six ways to find out…

May 26, 2014

If you’re not sure how well your CRM system is being used, here are five ways to find out: Look at usage stats If people aren’t using the system, it’s not going to be adding any value, so a good starting point is to understand usage patterns. Most CRM applications will allow you to query [...]

Read the full article →

99 ways to get more from your CRM software – new ebook

May 17, 2014

Last year I wrote  a series of posts called ’99 ways to get more from your CRM software’. They were designed to help existing users of CRM to find new ways to get value from their systems. In order to make the content a little more consumable I promised to consolidate the posts into a [...]

Read the full article →

A quick introduction to social listening, its benefits, and integration with CRM

May 11, 2014

With Microsoft recently announcing that social listening will be a key component of its spring 2014 release, following last year’s acquisition of Netbreeze, and’s Radian6 already a well-established part of their marketing cloud, social listening capabilities are set to become an increasingly important part of the CRM portfolio. But what is social listening and [...]

Read the full article →

Sixteen things you should be doing to maintain the value of your CRM system over the long term

April 27, 2014

So you’ve invested in new CRM software and successfully overcome the challenge of user adoption. What now? Here are sixteen things you want in place if you are to maintain and grow the value of your investment: Administration – someone needs to manage the day to day running of the system, adding users, changing security [...]

Read the full article →

The under-appreciated benefits of the humble CRM mail-merge function

April 13, 2014

One feature of CRM technology that I don’t think users make enough of is the ability to create, store, and manage mail-merge templates within the system.  These templates allow commonly used documents and emails to be quickly generated automatically, inserting relevant data held in the system, such as name and address. This may not sound [...]

Read the full article →