Merge constituent records for staff and students

Does anyone else have issues with staff and students creating multiple constituent records - one for their staff or student emails and then another for their personal email address?

We have found this to be a small issue on the front line as staff/students dont always recollect the email that they booked with so might struggle to locate their own bookings.

But more of a nuisance is that our merge utility pulls them up as duplicates because their name matches on both accounts... we then find that we cant really merge them because they are in theory two separate accounts so they all sit in the "select constituent ID to be kept:" list in the merge tool? It becomes hard then to see when other potential duplicates are added to that list by the utility.  I know there is a way that we can mark the accounts so that they dont get pulled into that list but that doesnt really solve our problem because we still want the system to identify in future if a real duplicate has been created on one of the two accounts.

Does anyone have any clever criteria for the dupe function that can filter out these from being pulled in the merge utility?

Thanks, Lianna

Parents
  • ,

    The kinds of multiple records per constituents you are describing are in my experience fairly common.  I’ve been working on a case study of this issue with 5-10% of records being these kinds of multiple records for the same customers even in a fairly clean database.  I’ve also noted that It often turns out for operational reasons like you are describing that merging such accounts can cause adverse customer experiences.  And if you don’t merge your aggregate custom reporting will have fairly large error bars.  

    Regarding what to do about this I believe that some organizations use custom reports rather than the merge screen to find duplicates that have filters that look at different time frames to reduce the number of records that need to be considered.  (This is sometimes referred to as “blocking” in the record linkage literature.) 

    Is in my mind one of the gurus of constituent merge purge in our community  she might be able to share some of her sophisticated approaches to these questions.   I belive that there are also some past TLCC presentations on this topic. 

Reply
  • ,

    The kinds of multiple records per constituents you are describing are in my experience fairly common.  I’ve been working on a case study of this issue with 5-10% of records being these kinds of multiple records for the same customers even in a fairly clean database.  I’ve also noted that It often turns out for operational reasons like you are describing that merging such accounts can cause adverse customer experiences.  And if you don’t merge your aggregate custom reporting will have fairly large error bars.  

    Regarding what to do about this I believe that some organizations use custom reports rather than the merge screen to find duplicates that have filters that look at different time frames to reduce the number of records that need to be considered.  (This is sometimes referred to as “blocking” in the record linkage literature.) 

    Is in my mind one of the gurus of constituent merge purge in our community  she might be able to share some of her sophisticated approaches to these questions.   I belive that there are also some past TLCC presentations on this topic. 

Children
No Data