Whether it’s called Last Name, Surname or Family Name this field remains stubbornly mandatory in virtually every customer database that I come across in my work. This constraint can severely hamper organisations’ attempts to move their marketing and CRM activity into a world of social media and digital content.

There seems to be a need in IT Teams and Data Managers to have something to hold as a core piece of data stored about every person on their database aside from the unique reference number allocated by their systems. It results in forcing website enquirers to share their last name when this is of no benefit to them when they simply want to have a brochure sent to their email account. It also means that Facebook users who become active contributors to an organisation’s Facebook presence cannot be stored on a database because they haven’t shared their name.

But surely some of the most important information about future customers or valuable (but anonymous) advocates is captured from sources where names are very much optional. So, why do many organisations seem so happy to accept this constraint? Even those that make an initial attempt to enable ‘virtual’ customers and prospects to be stored get a hard push back from their IT department or systems vendor saying that “Last Name is Mandatory and that’s that”. Zoho, one of the market leaders for instance, force Last Name to be mandatory in the person record on their basic CRM system. Without a person record you can’t store a contact method so a ‘dummy’ person record has to be created with a Last Name populated from the Facebook name, for instance.

In fact, the challenge is even wider than whether a Last Name is needed or not. It extends into questioning the mandatory nature of a ‘Physical’ person record. Increasingly, we find out interesting attitudes and behaviours about individuals whom we only know as a contact method such as a Twitter handle, email address or Facebook name. For instance, we may want to record content contributions, website visits, likes etc. before we know who the physical person is. We are then forced to create a person record for them to which we can link the contact method we have collected for them. Not exactly efficient or good practice!

So, is there a solution to this challenge? I believe that increasingly the big package and cloud customer database vendors will move to accommodate ‘virtual’ customers who may or may not have a ‘physical’ customer record attached to them. While this change is happening we are seeing leading organisations begin to go it alone where they have the capability to do so. This is either because they are building a solution from scratch or because they are implementing some form of overlay customer data repository such as a Master Data Management (MDM) solution for Customers.

The work I have done recently with a major motor manufacturer’s UK sales business has contributed to the brave step of them dividing physical people from virtual people (or Personas as they have chosen to call them). In fact, it is the Persona record that is mandatory for all customers and prospects, both Consumer and Business. This record is automatically created when a physical customer is added and is used as the central point to which most other data is linked such as contact methods, website visits, sales enquiries etc. A Persona record can also be created if a virtual customer record is received in the form of a Facebook entry from the Facebook API or a web enquiry where the person chose not to provide a name. It enables the organisation to begin communicating with them and to begin building a history of their activity right from the first point of their relationship with the organisation, even before it is known who they are. Of course, this new approach did raise some interesting challenges and pose some decision points that had not been addressed before. For instance, there was no basic reason to not store sales enquiries against a virtual persona if the enquirer did not wish to share their name. But what about actual purchases? For some products such as accessories it would arguably be acceptable to store purchases against a virtual persona with no need to know who the customer is. For other purchases such as new vehicles it would be impossible to complete all the formalities and register the vehicle without knowing the physical person, but who knows in the future, with increasing on-line vehicle purchase. For financial products it is very clear that the purchase needs to be made by a physical person. None of this invalidates the approach and simple constraint can prevent a purchase being linked to a Persona unless that Persona also has a linked Physical Person record. It is fully expected that most of these virtual personas will eventually reveal who they are voluntarily as they move through the purchase/relationship process. Others may be identified via cookie linking or other mechanisms such as deducing who they are by geo-location or other behavioural data. These latter approaches will call into question the whole question of permissions and GDPR but that is not for this Blog. The question is if, and when, the reality of virtual people will be better accommodated by the big systems vendors and service providers.