Data Integration

In this blog we’ll discuss some of the considerations, challenges and pitfalls that firms have to think about when planning data integration projects

The first and most important consideration is to be really clear what it is that you’re trying to achieve with the integration.   What this means is that you have to understand which users are going to benefit from the project, how they are going to use the data and where is the most appropriate place to store the information.

Most systems from different parts of the business also look at the world in different ways, so there is a likelihood that you will need to “transform” the data in someway.  You will also have to think carefully about how users might be able to “drill down” for more information.  A good example of this, is that you might have a summary of billing information shown against each client in your CRM system, but should the user want a more detailed set of billing data, then the practice management system (PMS) is the best place to go for this.  How will the user get there?

There are different data sets that you might want to integrate.  Here are a few examples:

  •  ‘Contact data’ – arguably the primary reason to integrate the PMS with the CRM system is to ensure that the firm’s most important data is visible and has the ability to be included on the firms key business development and marketing initiatives.  Most firms will integrate these systems to show a summary of billing information against clients, but also to enable new clients to be created in the CRM system as well.  Experience shows that the quality of data captured in the billing systems is not always what marketers might want it to be, therefore it is good practice to “ring-fence” this data initially until it has gone through some quality checks and can be released for general use.  
  • ‘Client subset’ – one of the reasons that firms are somewhat reluctant to integrate is that they do not want the entire PMS in their CRM system.  Stanton Allen build integrations that will only integrate a subset of data based on a set of pre-defined rules.  For example, a rule might state that only clients with a matter opened in the last 2 years should be integrated.  This would mean on day 1 that all clients that meet that criteria would be integrated.  On day 2 a client that has no matters in the last 2 years has a new matter opened, this would then become valuable to the firm and therefore fall automatically into scope for integration.
  • ‘One to many’ – another issue for firms is to try to reconcile the different requirements for data management in the PMS and CRM systems.  In the PMS a client may request to be billed regionally so you end up with ‘ABC Petfoods Ltd (North)’ and ‘ABC Petfoods Ltd (South)’ – this suits the need of the client and the PMS. However, this does not work for CRM which will require a single entity called ‘ABC Petfoods Ltd’.  Therefore, Stanton Allen have developed a methodology to maintain a ‘one to may’ relationship between the systems which will relate a single entity in CRM back to multiple entities in PMS.  This will include methodologies to seamlessly aggregate data based on this relationship
  •  ‘One view’ – enables the user to see all of the information regarding the client in one place.  This will include PMS specific information such as client partner, billings and services provided.  From a CRM perspective this will include information such as relationships, activities (emails, phone calls, meetings, etc.) that have taken place.  Having all of this information in one place enables this firm take advantage of enhanced reporting functionality and give better information to users in one place.  Increasingly firms are opting to use Sharepoint sites for displaying this data so that the data is not necessarily loaded from PMS to CRM, but is in fact integrated using a product such as Handshake and then displayed as an integrated data set on the firm’s intranet site.
  • ‘Headline information’ – the purpose of the integration is not to replace the PMS reporting function but to provide an overview of the key measurables. Typically this information will fall into the following profiles:
  • Contact Profile
    • Client Name (Company Name/Person Name)
    • Client Address 
  • Client Profile
    • Client Numbers
    • Client Group
    • Client Status
    • Client Open Date 
  • Financial Profile
    • Firmwide Billing – Total (YTD, Last Year, 2 Years Ago & 3 Years Ago)
    • Firmwide Billing – By Service Line (YTD, Last Year, 2 Years Ago & 3 Years Ago)
    • Firmwide Billing – By Department (YTD, Last Year, 2 Years Ago & 3 Years Ago)
    • Firmwide Billings – By Group (YTD, Last Year, 2 Years Ago & 3 Years Ago) 
  • Relationship Profile
    • Client Partner
    • Matter Partner 
  •  ‘Bespoke scheduling’ – this allows the firm to define what information should be integrated between the systems and when.  Typically, this is done daily overnight but can be modified depending on the specific needs of the firm. 
  • ‘Proactive issue resolution’ – as part of the integration if any issues are encountered either with the process or with the data included in the integration email reports and alerts are sent to predefined resources to ensure these issues are resolved as soon as possible.

Please refer to our blog about Capture, Repository and  Maintain which discusses some of the wider business context about the different elements of successful CRM.