I have been developing two ideas for customer data management: entities vs. roles and differentiation. In the last post I suggested that customer is not a data type, but rather a role that can be played by some core entity in some context, with some set of characteristics assigned to that role within that context.
This gives me a sword with which to slice the Gordian knot – instead of trying to create a single view of the customer that washes away critical distinction of roles, we can manage our entities and map those entities to their various roles and manage the specific attributes that are relevant only to each role.
This allows you to finesse some of the potential consolidation problems. For example, when the individual paying for the product is different than the one using the product, there is not difficulty in maintaining two different individual records that can play different customer roles for either finance or support purposes. It is possible to then differentiate between the different types of customers when that is necessary (such as when you want to publicly disclose the number of corporate customers but not individual names).
It is also possible to get a multi-faceted view of the interaction roles each entity plays across the different business processes. That opens up a greater vista for adding value in terms of key business activities such as customer service, revenue generation, and churn management. It also exposes relationships that extend beyond a single “domain” concept (such as “customer), such as showing which of your individuals with the role of “employee” also have the role of “customer.”
This suggests a different way to initiate your customer master program – instead of the technical aspects of consolidation, consider the business metadata for context (entities, roles, characteristics, attribution, differentiation) and use that to guide model development and integration.