A more successful approach to CRM requirements definition – part three

November 8, 2009September 6, 2015 Richard Boardman

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.

The second reason that process is important, is that it’s often only when you look at the detail of how your goals will be reached that you will flush out all the data capture, integration and functional requirements that will determine the complexity (and cost) of the project and the most appropriate technology for your needs.

Let’s say you decided that the objective for your project was to increase the life-time value of your customers by increasing the frequency and relevance of the communications you send them. If you look at this purely from a functionality stand-point you may simply conclude that you need marketing campaign management capabilities.

If however you start to look at this from a process stand point, i.e. what are the things you are going to need to do to improve your communication, then all sorts of complexity can start to appear. So you might consider:

How do you want to segment the database to ensure our communications are targeted and relevent? How and when will you capture that information? How do you check the quality of data? How do you ensure that people do want to receive the information you want to send them? How will you handle those that want to opt out? How will you handle ‘gone-aways’ and ‘bounce-backs‘? How do you control changes to the customer data? How will you handle leads and enquiries arising from our communications? How will you maintain data quality over time? How will track the impact your campaigns are having? What reporting will you wish to produce?

As you answer these questions, and work through the processes you need to put into place, then the complexity of the solution often increases. For example you might determine that a key means of targeting your communications will be the products that the customer has previously bought from you. In order to obtain this information it may require a previously unforeseen integration into your financial system.

Looking at things from a process view point is therefore both a key way to check the system will support achievement of your objectives, as well as a means of flushing out the requirements that will determine which CRM software best suits your needs and how much the project is going to cost.

As a bare minimum I would advise you to document and detail all the processes that your system will support. If at all possible I would try and take it a stage further and set out precisely how the technology will support them. I tend to map out the processes and add a detailed commentary on exactly what’s happening in the CRM system. So for each step in the process I indicate who is updating what fields on which entities in the system. This does require a working knowledge of CRM technology, but it allows you to create a more detailed blue-print for the system which in turn gives you much better control of time-lines and budgets.

Next week I will wrap up this series, including my thoughts on a suitable structure for the final requirements document.

Footnote – we recently published a free ebook which goes into a lot more detail about how to approach the CRM requirements gathering process and how to document the outputs. The ebook can be downloaded from here.