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.
Liliendahl on Data Quality 
At least this is better than the requirement that the deceased customer come in and complete a form declaring himself dead 🙂 Still rumoured to be enforced by some government agencies
Henrik,
Your post is a reminder that there can be multiple reasons why a customer is “dead”:
– Physically deceased
– Not traceable anymore
– Expressed his/her will not to be contacted anymore
– Has actually never existed
etc.
In all cases, it is important not to physically delete the related record(s), but to keep and maintain the complete history / life cycle of a customer, i.e. to set entries inactive together with a reason (code), timestamp of the deactivation and responsible user.
At a later point of time, it may be crucial to know and prove. Especially: Regulatory authorities may ask for it, people may sue the organization for not respecting an “anti-spam” law, and – last, but not least – the human error of an agent may have “declared” a person dead that actually is still alive…
Thanks a lot Gary and Axel for commenting. Your comments also again highlight one of my favorite subjects which is how these things works differently around the globe.