View Presentation

NOTE: This is a work-in-progress which I will support with models and candidate implementations.

OK. Maybe I'm stating the obvious but please humor my indulgence. I just want to state this for the record so I can move on.

First, there is no such thing as a Customer. If it is a "thing", then it's a highly transient state - or better, yet, an event. I'll discuss this more later on. For years I've seen every Customer Information System (CIS), Customer Management, Customer Relationship Management (CRM), Customer this-and-that NOT deliver. Every project, of which I've known about, that was about 'understanding' the Customer didn't deliver. Every system that was set up to ensure "Customer Satisfaction," well, I don't want to go on demeaning these efforts - it's just that these efforts stand upon the shoulders of something or someone that's looking in the wrong direction.

Quite simply, it's not about the Customer. Even in one organization the Customer can mean very different things. It's always a bit of sadistic fun to ask folks from different business units within an organization to define what the customer is. Invariably the heat rises. To Marketing the Customer may be the End-user consumer calling in about a problems with the product. To Sales it may be the Channel Managers or decision-makers that elect or influence whether or not to purchase, raise, or lower product levels. To Purchasing it may be the Vendors that he or she wants to keep happy by paying them on time. To Manufacturing it may be the subcontractors, assemblers, and unions and their elected officials. To Human Resources it may be employees, contracting firms, unions and their elected officials. In any organization there is always different types of parties that a stakeholder may have concerns and desires to understand and manage. That is, a customer is not necessarily someone who "buys" your stuff.

So, the term "Customer" is a poor unfortunate overused word. I call these "air" words. That is, a word that means everything but does not really mean anything. There are several in different domains, like "Member". Everybody knows what they are at an abstract level but at the work level, that is, the "get it done and make money" level, there's just a mass of finger-pointing confusion.

The problem is, that the word "Customer" is not a noun but an Adverb. It connotes action and a dynamic state of being. I don't know how many times I've seen clients wrestle with issues like, "when does a customer stop being a customer?" Then, they build the answer to that question right into their systems in such a way that discourages them from ever changing their policy. And even worse, I have seen expensive consultants draped in MBAs lead the charge.

The important distinction that leads to a simple answer is in embracing the notion that it does not matter THAT you know someone or some entity; what is important is HOW you know someone or some entity. That is, most Customer-focused efforts concentrate on the Party (the person or organization) and not on the relationship with the Party. The relationship is at the core of every business system. Information about the Party, like name, SSN, FEIN, etc., is merely support and reference. It tells you nothing that is meaningful. What is critical is how you know them and the central instrument, that manages, monitors, and measures, is a concept known as an Account.

The concept of Customer is derived. That is, if a Party meets certain criteria then that Party resolves to being thought of as a Customer. If within an organization the criteria are different, then how can a business, at the Mission level, even begin to have the word "Customer" in any of its statements? That's why I enjoy reading corporate mission statements. It has very good intentions but the organization cannot possibly achieve their objectives across the organization. And, if they're using their Customer Information Systems to help achieve their objectives then I hope the shareholders are reading this.

The Account as a fundamental unifying concept often goes unnoticed. This is an example of "naked is the best disguise." I don't know how many applications, business domain models, conceptual models, and databases where I've seen the "member" or "customer" table. In addition, I see all of these flags and tags and dates and extraneous, sundry, bolted-on data elements. All of this in the name of "understanding the customer."

The Account is that object that gives a context for the relationship. Actually, the Account IS the relationship. Its fundamental function is to aggregate all of the events that transpire between the producer role and consumer role within the relationship. That is, the Account relates to every transaction with the consumer. For example, I purchase gas using my account. That account knows every time I've made a purchase. It can tell me the last time I made a purchase and how much I paid. That account can even tell me how much I've spent between October 24, 2000 and January 6, 2001. Depending on my criteria as a business, that Account can tell me whether I'm a good Customer, if the business defines a "good Customer" as one who buys more than $200.00 per month and makes the payment on time. Of course, altering the criteria can easily change that policy.

One does not need a Customer database, table, or concept to answer the questions in the above example. Here's another example of why there's no such need for a Customer in the system: I mentioned earlier that often there are bolted-on sundry data elements and that a common question is, "when does a customer stop being a customer?" I mentioned that whole applications and the applications with which they interface and integrate suffer the tyranny of temporal policies. One such policy may be, "a customer is not a customer when they've not made a purchase is six months." So, the Customer table gets a new data element called "InactiveFlag" and gets batch processed or interactively updated. If it's set to 'on' then the Customer has not made a purchase in six months and is no longer considered a Customer. Now, first, I want to say that the whole idea of declaring someone NOT a Customer any longer is ludicrous unless of course, the individual associated with Account is dead. However, fundamentally, I dislike the term "Customer."

Having had the luxury of contributing in many project-participant roles I appreciate the various stakeholder perspectives. It is also interesting to note that discrete and transient business terms (and often business jargon) find its way into the actual implementations. For example, having a physical database table called, "Customer", or even worse, a database called, "Customer". It is frustrating to note that regardless of how good we get at building software and systems using various methods and methodologies from SSAS, IE, RUP, to eXtreme, and use the most user-centered, adaptive, and agile approaches and use the fastest, most mutable development tools, the same terrible results await us unless we lose these legacy concepts and words from our systems' lexicon.

Where does a customer exist?
It is difficult to explain converging ideas in a serial manner so at this time I wish to address the issues around Customer as a physical concept as in a physical table instance. I have already pointed out that every individual stakeholder knows what the customer is from that individual stakeholder's perspective. One of the ancient problems that still haunts many old and, sadly, new systems, is that we may find several applications that uniquely support the functional views of "customer", e.g. Customer, Vendor, Contractor, Employee, etc. Another ancient problem is not knowing when a Vendor is a Customer, when is Customer a Contact, etc. That is, not knowing when the very same entity provides value in many different ways, situations, and contexts. I have seen this in many projects. An example of this is when an Employee cannot have access to the employer's products and services. Actually, there were occasions where the employer was missing out on significant opportunities and revenue streams because that employer was unable to know the various roles that a party may play.

What is really going on?
The Account, for lack of a better concept, serves as the instrument for aggregating event/transaction types. There are several inversions of casting a solution for a "Customer-less" architecture. To cast it simply, let's say that an individual entity, that we'll call a "Party" plays a particular role in a relationship with another Party . For example a Party may play the role of "RetailPurchaser" (aka Customer ) in a particular transaction which we'll call a "Purchase". If the Party is not known to us, we collect various information about the Party so that we can remember that Party. In addition, we'll create an instrument that we will use to aggregate transactions applicable to the RetailPurchaser role. These event/transaction types may be order, purchase, return, complain, etc. When that Party wishes to make similar transactions those transactions aggregate to the appropriate Account.

So far, nothing that is mentioned here should be new. The big difference may simply be that I'm casting the Account as being a RetailPurchaser type of Account. However, I could also cast that Account as being somewhat more generic and say that the Account supports a Party wishing to transact in the role of a RetailPurchaser. The abilities of the RetailPurchaser role dictate the types of transactions that Party may affect.