Blogs

Making Sense of the (CRM Reporting) Madness

By James Imgraben posted 07-10-2021 09:24 AM

  

Since going live with our Oracle CX CRM implementation, we at UniSA have been on an evolving journey to try and consolidate and dissect the enormous volume of data being captured across our enterprise CRM. 

While many SaaS CRM offerings will provide their own reporting modules, with varying levels of functionality (and complexity), to create reports for end-users that are more operational and specific to the data captured within, the challenge we are facing is an increased need for holistic reporting across the product set where we can no longer rely on the individual systems to deliver reports that will meet the needs for senior management.

Primarily there is a need to provide information that will enable senior management to make informed decisions on student recruitment successes, especially when needing to track the engagement of a prospective applicant through marketing, enquiries, application, and enrolment.

One challenge we’ve faced in this is the data retention and limitations within the cloud, where you cannot rely on the system to maintain an indefinite record of a person, either due to data lifecycle policies that see data purged after a certain period of time, or the need to keep object storage within certain thresholds so as to not impact the operational performance of the system.

As well, we have struggled to make use of the SaaS reporting application that initially came with our suite which was intended to provide cross-system reporting, primarily due to similar storage limitations in the application that would meet the needs of an ever hungry CRM!

To combat this, and to co-locate the CRM data to begin to make sense of it, we have built a set of applications that will download and sync a living copy of each system in the suite into our on-premise data warehouse and operational data store. What this has enabled us to do up until now is keep a living record of the transactional data that is being purged from the cloud applications, so that we can report outside of the system retention policy, and will look to provide a more detailed view of year-on-year reporting where we can look back with greater accuracy.

While this approach allows greater control over the records and attributes being synced from each CRM application, it does introduce an ongoing maintenance overhead to ensure that as we onboard new business processes and units in the CRM, we must also keep these tools in line with changes made – to the point where these updates must now be accounted for as an activity in any new project.

Of course, it is one thing to download all the data, but what do you do with the mountain of data to make sense of it? How much do you download from the CRM….and just how much is too much? I hope to detail our approach to untangling this web of data and delivering executive reports in upcoming blog posts, and highlighting any lessons learnt along the way. I am keen to hear from anyone else that has either seen the other side, or on a similar trajectory!

#cx
#crm

​​​

2 comments
36 views

Permalink

Comments

08-03-2021 02:37 AM

We currently adopt different custom-built and few off-the-shelf solutions for the prospective to student life cycle journey.

We are also developing the data warehouse and related analytics to facilitate effective data-driven decision-making.    It is hoped that this can be a topic for experience sharing in the coming IVW2021.

07-13-2021 09:03 AM

James, you have succinctly captured the Achilles heel of many SaaS based systems.  The need for longitudinal data analysis is difficult due to the imposed caps of the systems from a time perspective. Your approach to a local data warehouse is similar to the approach that we are taking.  I’m looking forward to your future posts as you share your journey.