CRM Reporting – Prior Planning Prevents P Poor Performance

April 23, 2018 Mark Payne

At some point, either during or after implementation of your CRM system, someone in your company is going to ask you for some reports. Inevitably, the one report they ask for will be the one for which you either don’t have the data or the one that requires you to manipulate the data so extensively that each time you run it will take a day out of your busy schedule. There is only one way that I know of to prevent this scenario and that is to know what reports are required before you implement the system.

This may seem like an obvious statement but I have often been parachuted in to rescue projects where the data being captured in the system bears little or no relation to the insight and analytics required at the other end. For a lot of systems, reports and the insight they bring help realise the benefits to the business.

Planning for the reporting end game

So, how can reports be given the due care and attention they deserve before and during the CRM system build? Here are some of my thoughts on the subject:

Make sure you are capturing the correct data

This might seem like the most obvious point of all! Once you know what reports you need to produce it should be a trivial task to ensure that you are capturing the data required to drive them. As always, the devil is in the detail. For example, you may have a report that includes some element of your customers’ ages. In this case you could capture the data as a date of birth, an exact age or even as an age band (e.g. 18-25). Obviously, the option you choose will be influenced by the detail of the reports you need to produce.

It is also important to consider your data structures. It may be elegant to have multiple entities all over the system for ultimate flexibility but sometimes a simple set of fields on a core entity will serve your reporting purposes better.

Make sure that senior management are included in the process.

Senior management are likely to be one of the key consumers of reports produced from the system. Understanding their requirements early in the process on what statistics and data they want to see will help you to shape the system to ensure that their needs are met.

Understand the types of reports you need to produce

I like to categorise reports in 3 different ways:

• Usage Reports.
• Performance Reports.
• Trend Reports.

Usage reports tell you how the system is being used and if there are any issues. They are straightforward and are driven by the system anyway so don’t really need any careful consideration during the design and build phases.

Performance reports are backward looking and tell you how the business is performing based on data captured in the system. They require careful consideration to ensure that the system can supply the key performance indicator metrics that the business requires.

Trend reports are the hardest of all to get right but are likely to be the most valuable to your organisation.

By their very nature they require snapshots of data at given points in time and, ideally, some sort of forward looking element to allow the business to plan and predict what is going to happen next. Inevitably they require some sort of audit trail to be able to produce the trend so you will need to ensure that you are snapshotting data over an appropriate timeframe and that the snapshots are easy to use in the required reporting context.

You will also need to ensure that you know what sort of predictive model you are going to put in place so that the system can be designed to supply the necessary variables.

Future Requirements

I have never implemented a system where absolutely every reporting requirement is known up front. This is where the understanding of the business processes during the design of the system becomes critical. Logically, if the system is capturing all the information required for the processes it is supporting then there is unlikely to be a reporting requirement that cannot be catered for.

The only exception to this is if a business process changes in which case the system will need to change with it. This is where modern CRM platforms come into their own with their flexibility and rapid development capabilities.

Conclusion

In conclusion, reporting requirements should not come as a shock as they should form part of the initial system design and build. To quote Donald Rumsfeld, there will always be “unknown unknowns”, but, if the system is setup correctly and the correct platform has been chosen, then making these into “known knowns” should not be too difficult.