Your Customer is a Person too

The Customer Data Puzzle Part 2

7 min readApr 5, 2023

The next question is “WTF is a customer”, this is possibly my favourite question in an organization. Because everyone is absolutely certain they know what a customer is, but there is no consistent definition of what that means. So in Part 2 we’ll look at answering that question, and the reality that there is no one definition of customer and that a unique customer doesn’t have to mean a unique person. This was after Part 1 looked at the multitude of customer systems.

“Customer” is contextual

The classic British Sitcom “Yes, Minister” had a concept of “irregular verbs”, where the definition changed depending on the context

That’s one of those irregular verbs, isn’t it? I give confidential security briefings. You leak. He has been charged under section 2a of the Official Secrets Act.

Customer is an irregular noun, its definition changes depending on the part of the business you are in:

Finance: A customer is someone who has paid an invoice
Distribution: A customer is the location we drop the package at
Sales: A customer is someone I can sell something to
Marketing: A customer is any warm body we could maybe sell to

It also depends what industry you are in:

Power Utilities: A customer is a connection point to a house
Mobile Phones: A customer is a subscription contract or an IMEI connection
Retailer: A customer is a person who buys stuff
Airline: We don’t have customers, we have passengers
Cruise Line: We don’t have customers, we have guests

These distinctions are important and all of them are right which is why one of the first things to understand when looking at the challenge of customer is a simple challenge:

What is the difference between a natural person and a customer?

The Natural Person

You are a natural person, I am a natural person, even a member of the British Royal Family is a natural person. A natural person is a living breathing human, this differentiates it from the various other type of legal “persons”. A Natural Person can also represent multiple legal “persons”, so the person who is legally allowed to sign-off the accounts has a legal role to play, as well as being the natural person doing that role.

Ultimately therefore every interaction you have with an actual consumer is an interaction with a natural person. Laws such as GDPR are written based on the natural person, meaning you do need to know the individual behind the record.

The Customer and the Natural Person

The smart way to think about the natural person is that this represents the individual outside of your organization, that person doesn’t just interact with you, they interact with lots of other organizations, and other people, as well as your own. As an organization therefore you have zero ability to dictate the definition of the Natural Person. This means that you cannot guarantee with absolute certainty that each customer represents a single natural person.

Shared Accounts v Customer Accounts

The other challenge is if you work in a way, such as Netflix, where you have no “group” plan and instead allow a single customer account to be shared with multiple people then you are also breaking the association from a customer to a natural person. This is the equivalent of a device or premises based account in the utilities and telco industries.

This is a bad thing. There is a reason that Apple, Amazon etc all have approaches that include “Family” plans where you can share with nominated people. This can not only help in terms of preventing people from sharing in the first place, but means you can associate each account to a natural person.

Apple have Customer Accounts, Netflix have building base accounts, the objective for Netflix to deal with leakage is to identify device usage (not a person) for devices that are not associated with the address for the account. Apple on the other hand don’t care if your kids have left home or your mother is part of the plan, but they know each and every person as an individual account.

Get Steve Jones’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Now there are reasons in 2023 to allow accounts where an individual person’s email address is used to access a shared account by multiple people. I’ll list them below:

1. To use someone else’s account

Err there we go. So, don’t do that. Let’s make that a rule

Rule 1: A customer account should be traceable to a single natural person

Note, we are not saying that there is one customer account per person, just that for a customer account we are going to set up an approach which means each account that is created links back to one, and only one, individual. If you are breaking this rule you’ve decided that your customers aren’t actually people, they’re “accounts” or “subscriptions” or something else that is purely internal to your business model as it exists today.

“Group Plans” are an non-person account type

If you are supporting that type of plan sharing, then you’ve created a non-natural person account that contains multiple natural people. So don’t think of this as being a feature of the “primary” user, think instead of it being its own account which has a primary user and which represents the corporate view of how you engage with the people behind the contract.

Diagram showing that a Customer, who is a Natural Person, creates a Group Account and becomes the Primary users, two other Customers, each one representing a different Natural Person, are members of the same group account — A Group Account is your approach, its not a feature of the customer

Multiple accounts is fine, for now

The next thing to embrace is that it is absolute going to happen that one customer matches to multiple accounts, even potentially using the same unique identifier.

This can happen for a lot of reasons:

You might have acquired a company which had its own log-in approach, for instance you’ve been using Google, Facebook and Apple to authorize individuals, but an acquired company did it all themselves with email & password
Someone might have used their corporate email for a personal registration using a password, and using corporate SSO for their corporate account. (For historical reasons I have exactly this case with Azure).
You offer new subscribers a discount and penalize renewals, therefore people tend to use new email addresses and say they are new subscribers.
Your company has multiple go-to-market brands which for regulatory, corporate strategy, or historical reasons are treated separately.
They’re using these multiple accounts as a way to commit some type of fraud

In all of these cases, and many more, one natural person can end up being multiple “customers” from your corporate perspective. This separates the “customer” from the “customer account”, the account is the mechanism via which they identify themselves, the customer is the data you know about them via that interaction.

The answer is not to always force that all to be collapsed, there might be valid reasons for them to be separate, the answer instead is to track the link from natural person to customer and then understand what works best for your customer engagement strategy.

Object relationship diagram showing a Natural Person can be multiple customers, each customer might have multiple customer accounts, and each account could be for multiple business purposes — A customer isn’t an account, but an account is how you know the purpose of them as a customer

Transactions are an account thing

So the last thing I’ll deal with in Part 2 is the association of transactions and interactions back to that natural person. If we have the Customer Account being the way you identify the customer then it is that which represents the piece to hang the transactions from. This way you reduce the need for future re-mapping that could happen when you do start consolidating customers. Because a customer can have multiple accounts, then I can leave historical transactions against their historical account if I consolidate but still be able to show the user a unified view.

This is important. What we are saying here is that the design of our systems, as we move to Part 3 and look at matching and MDM, should be to assume a customer has multiple accounts. Rather than today where process and transactional systems often have issues when an MDM does a merge, or a split, instead we use the power of the x-ref to display the right information to the customer.

The customer, and ultimately that natural person, doesn’t need to know how you’ve engineered your internal systems and what database ID you’ve used for each of their transactions to identify it was their transactions, they, including everyone who interacts with them, just needs to see the unified view at the customer or employee experience level.

UX is where it comes together

This means that you need to think about the UX from an Employee and a Customer perspective, not from the database schema that happens to reside within a single system. So if you’ve just rolled out a new SAP system for instance, you still want to show the historical transactions. If they’ve had two separate accounts and now they’re just using one, you still want to know about transactions from both.