In the post Last Time Right the bad consequences of not handling that one of your customers aren’t among us anymore was touched.
This sad event is a major trigger in party master data lifecycle management like The Relocation Event I described last week.
In the data quality realm handling so called deceased data has been much about suppression services in direct marketing. But as we develop more advanced master data services handling the many aspects of the deceased event turns up as an important capability.
Like with relocation you may learn about the sad event in several ways:
- A message from relatives
- Subscription to external reference data services, which will be different from country to country
- Investigation upon returned mail via postal services
Apart from in Business-to-Consumer (B2C) activities the deceased event also has relevance in Business-to-Business (B2B) where we may call it the dissolved event.
One benefit of having a central master data management functionality is that every party role and related business processes can be notified about the status which may trigger a workflow.
An area where I have worked with handling this situation was in public transit where subscription services for public transport is cancelled when learning about a decease thus lifting some burden on relatives and also avoiding processes for paying back money in this situation.
Right now I’m working with data stewardship functionality in the instant Data Quality MDM Edition where the relocation event, the deceased event and other important events in party master data lifecycle management must be supported by functionality embracing external reference data and internal master data.