How to document requirements for a CRM system – part 5

by Richard Boardman on December 13, 2014

Last time out I described what I’d expect to see in a decent CRM requirements specification. Putting this sort of document together isn’t a trivial exercise, but the payback from the time invested can be huge. Here are some of the key benefits of this sort of approach:

Increased return on investment – the focus on having well defined business objectives means that there’s a much greater likelihood that the system will generate value to the business once it’s implemented. Many CRM projects fail to achieve anything meaningful either because there are no business goals or that they’re not fully articulated or understood.

Less white elephants – this emphasis on operational outcomes also means that investment tends to be focused on areas that make the biggest difference, and there’s less likelihood of expenditure on unnecessary frills or expensive white elephants.

Improved functional fit – the approach of fully documenting how an organisation’s business processes will be supported by the system is very effective at flushing out functional requirements, and tends to give a much greater understanding of what is and isn’t needed. This helps avoid the risk of selecting a CRM technology that doesn’t meet your needs or spending on unnecessary capabilities.

Reduced costs – the emphasis on process, and spelling out requirements in more detail, particularly in the areas of data migration and integration, means that prospective vendors can provide much firmer and more accurate pricing proposals. This avoids the common pitfall of having to make procurement decisions based on very loose estimates, which are only firmed up when the selected vendor undertakes a more detailed, and often expensive, discovery phase – the outcome of which is invariably a hefty uplift in costs.

The cost reductions through using this approach can be significant. We generally expect to purchase a system 30-40% cheaper through tightly defining the details up front.

Increased implementation speed – the time spent spelling out requirements in detail in advance of purchasing CRM software, means that the project can progress a lot quicker once the technology is selected and the implementation partner is on board, because this potentially time-consuming phase is already done.

Improved project control – a clear, shared, vision of what the system looks like, means that there’s much less likelihood of budget overruns or live date slippage through new requirements being discovered during the implementation phase.

That covers the content and the associated benefits, in the next post I’m going to cover how to go about putting this sort of specification together.

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


How to document requirements for a CRM system – part 4

by Richard Boardman on November 30, 2014

In the fourth of this series of posts about CRM requirements gathering, I wanted to cover content. So what needs to be included in a CRM requirements document? The following covers the main areas I’d hope to see:


This section sets out how the requirements were gathered, and, importantly, who was involved in the process. This helps ensure that the approach was thorough and comprehensive and that any gaps in coverage can be identified.


The overview gives a high level description of the new system, and will cover who will be using it, and what they will be using it for.


For many organisations, making all functionality for all users available on day one is impractical. The phasing section set out how the deployment will be broken down and how these will be prioritised.

Business objectives

For me this is one of the most important parts of the requirements specification. It describes why you’re undertaking the project in the first place: What are the problems you’re trying to solve? What beneficial outcomes do you expect the the system will produce? This should be as specific and detailed as possible.

As I’ve touched on in previous posts, a CRM system needs to be set up and used with specific goals in mind. If these can’t be properly articulated, it’s unlikely that the project will be a success.

Defining clear business objectives also has an important role in securing appropriate funding and resources, as well as helping prioritise requirements based on business need.

Supporting processes

The role of this section is to specify how the system will support the business processes necessary to achieve the agreed business objectives.

For example, if a key objective was to grow sales by improving lead conversion rates, from say 10% to 15%, then this section would communicate how the processes from initial lead capture through to order will be managed within the system, and describe how the improvements will be realised.

A sensible approach to this is to describe both the current ‘as is’ situation, highlighting known issues and inefficiencies, and then the ‘to be’ processes. I tend to cover these processes in both a written narrative, as well as a series of flowcharts. The flowcharts for the ‘to be’ describe in detail what’s being updated in the system by the user for each step in the process.

Most organisations neglect this area when defining their requirements, but it plays a key role in helping determine the fit with the ‘out of the box’ capabilities of the various CRM software options, and helps prospective vendors more accurately cost out any associated customisation and development required to bridge any gaps.


This section describes the main types of records managed by the system. For example, this might include information about people, organisations, sales opportunities, leads, and activities, but also may include new entities that need to be added to support an organisation’s processes. I generally start with a diagram of these entities, and how they relate to one another, and then describe each in detail, setting out what fields will be tracked within each.

This might seem like a lot of work up front, but it saves valuable time later during the implementation phase.

Functional requirements

This part of the specification describes all the supporting functional requirements. I tend to break this down into specific functionality required to support each business process, and more general supporting requirements such as administration, security, or access related functionality. In a future post I will endeavour to provide a functional requirements check-list which hopefully should help in this area.

Data migration and integration requirements

Data migration and integration requirements can have a huge bearing on the cost of implementing the system. It’s therefore important to document in as much detail as possible needs in this area. A clear definition of what data is moving between which systems, is essential, and, in terms of integration, whether the requirement is for real time or more periodic integration.


This area should ideally identify what management information you’re looking to get out of the system. Detailing out reporting requirements, not only helps speed up the implementation, but can be a very effective way of validating that the processes have been modelled correctly and that the associated data capture is correct.

Systems replaced

Finally, the systems replaced section confirms which existing systems and data sources will be decommissioned as part of the roll out of the system. This helps remove any ambiguity as to how the post-live world will look.

As you can see there’s a lot more to a CRM requirements document than just a list of required functionality. While there’s more work involved, the benefits of approaching it this way are significant. I will explain why in the next post.

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


How to document requirements for a CRM system – part 3

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 [...]

Read the full article →

How to document requirements for a CRM system – part 2

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 [...]

Read the full article →

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 →