I Buy Therefore I amBeyond simply identifying customers – hard enough in itself – the ability to answer the question, “What is a customer?” has serious implications for your businessBy Todd Schraml
Who are your customers? It’s a simple enough question but contains painful nuances for any large business. This question is particularly hard to answer when the goal along the way is to automate the customer identification process. Even if you assume a perfect world — a single name uniquely identifying a business, and every business having a single address — dangers abound. Common frustrations include misspelled or inconsistently abbreviated names and variations in address formats. These variations have only increased as consumers take on the data entry tasks for sellers via online purchasing over the Internet. Vendors such as Vality Inc., Pitney Bowes Inc., and Dun & Bradstreet Inc. (D&B) offer products and services to clean up names and addresses, with some of their tools supporting fuzzy matching logic to help identify variations of a single address. These vendors do good business because no one’s data is 100 percent clean and accurate. However, keep in mind that even in an automated matching process, ultimately your systems must “guess” the correct answer. This fact holds for off-the-shelf packages as well as homegrown applications. Unfortunately, because guesses will occasionally be wrong, the process is inherently risky. Many organizations forget the simple fact that guessing is just that: risking failure. Accepting a soft-ware vendor’s disclaimer that no matching process is completely accurate is easy enough before implementation, but when inaccuracy creeps in for a particularly important customer at a particularly inopportune time, that qualification isn’t so easy to accept. Ideally, your organization can find an approach and tools that even with “guessing” algorithms provide an “acceptable” level of accuracy. In general, in the quest to reach that acceptable level, increasing data matching accuracy will increase cost. Often that increased cost also involves a manual review of matches and nonmatches, which consumes time and resources. Few organizations, even large ones, can afford a large staff to manually review every single transaction for proper customer identification and assignment. And for the lean staff of a Web-based startup, this task will likely remain forever on the “to do someday after making a fortune” list. One (far too rare) option to help minimize this cost is to embed your organization’s customer identification process within the operational systems initiating the customer transactions. Thus, transactions would initiate only for positively identified customers. This approach is still uncommon for two main reasons. First, adding such new requirements to existing systems is perceived as too invasive. Second, the accuracy level required for customer identification during a sales transaction is often far lower than that required for other reporting and decision-making needs. For example, in one extreme case, a mailing to several rural communities for a telecommunications company resulted in the return of an extraordinarily large percentage of items stamped “undeliverable.” The company verified that the addresses used were identical to those on the monthly bills and that the bills were being paid, and decided to investigate further. It turned out that the local postmaster recognized the bills, knew for whom they were intended, and delivered them. But this same postmaster wasn’t doing the extra work of decoding addresses for junk mail. Because of this discrepancy, the overall transaction costs associated with raising customer-identification accuracy levels can increase beyond what the organization is willing to pay. However, a more thorough approach is actually more cost-effective because asking an additional question or two to verify the customer’s identity during the sale is faster and easier than additional “guessing,” review, analysis, and investigation down the line. For the self-service approach of Web-based transactions, maintaining accounts and passwords that customers must enter may slightly increase the development and maintenance costs, but these efforts do bolster the continuity of identification over many transactions. While some customers may be irritated over the need to remember yet another password, others do gain an added sense of security. Any irritation can be offset by offering specials or “freebies” with certain levels of aggregated sales over time. Furthermore, identifying customers can be difficult because having clean names, clean addresses, and trusted matches are only part of the solution. Beyond the “Who are your customers?” question lies an even tougher one: What is a customer?
General BusinessIf you have a small business with one or two locations, you may think you’re in gravy: For each transaction, you have a unique name, address, and customer, right? Not necessarily; you may still have to cope with multiple names for a single customer. Many businesses have one name on the sign outside the door, another one on the e-commerce portal, and yet another on the checks they send out to pay the bills. Some businesses may even be quite particular about the exact circumstances in which they want to use each name (such as “invoices must use one name, other correspondence another name”). Furthermore, it doesn’t take too large of a customer base to end up with two organizations using the same name but that are otherwise totally unassociated entities (Joe’s Garage, St. Mary’s Hospital, and St. Mark’s Church, to name a few). You may have a mall or office building with a common address and many associated names; some of them could be single organizations with multiple names, while others are indeed separate organizations. You may have a single name with multiple addresses, with some of them serving as different locations for one organization and others for separate organizations. As you can see, even at this simple level, using just a name and address will be a struggle. An explicit solution is to establish some sort of a customer ID outside of just a name and address to group things, and likewise to keep things apart. But maintaining that ID and its associations through solely an automated process will be difficult because of these multiple possibilities: A single name and multiple addresses could mean a single customer with multiple locations, or it could mean multiple customers with similar names. Multiple names at one address may mean multiple customers, or it may mean a single customer with multiple names. No software will guess which is which with perfect accuracy.
Complex BusinessRelationships among organizational entities can become very complex, very quickly. (X owns Y and operates locations as both X and Y; Z buys X and also owns A, B, and C.... I’m sure you get the point.) For example, dealing with government organizations as customers can be frustrating because categorizing and grouping state, federal, and local governments and their affiliated bureaus, services, and plans is very problematic. However, several schemes are available to clarify such relationships. One popular option is D&B’s Data Universal Numbering System, or DUNS numbers. (Other companies provide similar services; D&B is simply a good example.) In the D&B scheme, each identified business location is assigned four numbers: One designates the location; a second number designates the immediate parent company (in the example “X owns Y,” Y would have a location number and another number that identifies X as its parent); a third one designates the headquarters site controlling the Y location; and a fourth number identifies the “ultimate” parent organization — in our example, Z’s number would be the ultimate parent for the X and Y locations. For small businesses, these numbers may be identical. For larger businesses, an infinitely long chain of numbers could lead from the original location through various hierarchies to the final, ultimate parent number. This approach provides a simple option for grouping locations by any of four means, and with some additional work on the part of people retrieving data, the option is certainly there to flesh out the chaining from point to point (although you wouldn’t want a novice doing it.)
FranchisingFranchising is an area where “What is a customer?” can be a particularly tough question. If person A owns a McDonald’s, a Burger King, and a Staples, who is your customer? Of course, depending on your business and franchising contracts, you may deal only with owner A, or you may have to deal only with someone within each of the franchiser chains of command. Obviously, the worst-case scenario would be one in which you must deal with the owner sometimes for one set of issues and the franchisers at other times for other issues, and there is always the wild card of a franchise that temporarily is controlled by the franchiser.
HouseholdingHouseholding is a customer identification term that applies to businesses as well as individuals. For example, you sell something to A who lives at X. A is married to B at the same residence. A and B have children C, D, and E. C goes away to college eight months of the year where C roommates with F and G off campus at Y. Depending on your business needs, you may want to consider A, B, C, D, E, F, and G each as separate potential customers and gather unique psychographics and demographics for each one. Likewise, you may want to target marketing efforts toward different groupings, each as a single unit: to A and B; A, B, C, D, and E; C, D, and E; or C, F, and G, for example. At times, you may want to avoid marketing to C at Y, because you’ve already marketed to C at X. Furthermore, you may gather demographics about locations X and Y, but one or the other of those locations is the unit to which you direct your marketing.
Confused Yet?As you can see, identifying “what” a customer is through divisions and groupings clearly is no simple matter. DUNS numbers would appear to be a solution applying to all business (except maybe franchising, but even that could turn out all right). However, even DUNS numbers buy you only a breakdown of the legal divisions of corporate ownership. And as such, they may be only a starting point rather than an answer. Even if you assume clean names, addresses, good matches, well-assigned DUNS numbers, social security numbers for all residential folks, and perfect knowledge of who lives with whom, you still have work to do. In the data warehousing world, it is not unusual to establish multiple data marts to provide different functional areas with differing perspectives. The same is true for identifying who is a customer, and beyond that, what is a customer. Different areas may need different “views.” It is entirely legitimate for your organization’s billing group to aggregate the answer to “What is a customer?” based on who is paying the bill. Likewise, it is entirely legitimate for your sales group to aggregate what a customer is, based on who makes the buying decisions. But these approaches may provide inconsistent views of your customer. In the extreme case — which would probably involve marketing and householding — each group may want many views supported, or even ever-changing ones. The problem is not that this scenario is common, but rather that in many organizations it unfolds in a confused, ad hoc fashion — with managers bringing contradictory reports to meetings and not being able to explain why the numbers don’t match.
Going AtomicCustomer identification across an enterprise can be an amalgamation of many views. Customer identification, particularly in regard to its support of customer relationship management, deserves the expenditure of corporate resources. Far too often, organizations refuse to make this investment, assuming that the status quo must be “good enough” because invoices go out and are paid. A good start to resolving these issues is to determine which perspectives on customers to support. Here is where you should decide whether DUNS numbers will be useful. Many views will have valid business reasons to exist; these go on the list of valid “What is a customer?” views. Next, you need to determine the lowest common denominator that exists within the data for identifying the “who” of your transactions. These pieces of data become the “atoms” that “assemble” into one customer or another. For telecommunications, they could be activated telephone numbers; for other industries, they may be customer names, service addresses, or social security numbers. However, these atoms will not necessarily equate “one for one” to a customer. Rather, they may be fashioned together in multiple ways, becoming different customers based on specific end-user needs. For example, everyone in a family household may collectively constitute a single customer at one point in time, but need to be viewed as individual customers at other times. Sales may view customers based on business ownership; marketing may see customers based on business type and then ownership. An organization or individual could end up being a single customer for one group, and several customers for another group. Thus, the customer identification process comprises three main steps: One, constantly gathering a complete list of all these customer atoms based on existing or new data; two, associating these atoms with code sets that service the individual needs for customer views across the organization; and three, matching transactions against these atoms to properly associate the transactional data for each supported user group. Steps one and three should be fairly easy to automate, but step two will require most of the work. For instance, end users may decide that a unique name and address make a unique customer, in which case your work is done. But sometimes, this process may be just a starting point, requiring you to design a user interface that lets customer-service representatives change those assignments as necessary. For example, if one of the supported views is based on knowledge that exists only in the heads of the sales staff, you have little hope of automating the assignment process. To support step-two processing, a logical structure should exist containing the elements comprising the “atom” as its primary key, with the code sets supporting the various groupings comprising the attributes. For an example, let’s say we’re using a customer name and address as our lowest common denominators. Also, let’s suppose we need the four DUNS numbers discussed earlier, and beyond these we have a customer ID for our invoicing department. (Remember, certain customers may want you to put them in groupings other than where your internal organization assigns them; therefore, the external customer will be driving the internal end-user’s view.) We start by designing our Customer Master (atoms) table with the lowest common denominator as the primary key, and all the desired possible groupings (supported “What is a customer?” views) as its attributes. (See Table 1.) A source now exists to support the creation of multiple views for customer identification. Even this simple example allows for five groupings beyond name and address: DUNS Locations, DUNS Parents, DUNS Headquarters, DUNS Ultimate Parents, and Invoice Customers. Now, if tempers flare because of conflicting numbers, a “rationale” exists to document the differences among views used for individual reports. If one user favored DUNS Locations, and another used Invoice Customers, you can query, and hopefully rationalize, the differences. A table like this one may end up as a keystone of your data warehousing initiative, or it could easily serve as an operational table for a separate customer identification application. You could even make segments of this table available for external customer reporting through an intranet or extranet arrangement. (Customers sometimes have multiple views of themselves.) The number of columns that go into this table, and consequently how many views it supports, is driven entirely by maintenance limitations. While sources for some of this data may be automated, others may require application code that assigns defaults and reports anything new or changed. You can view those reports manually and correct them. Some limited access online will most likely be required for handling changes. (Even a customer with one location may demand two internal departments be treated as separate customers for invoicing.) Remember, this process is just a starting point. More complexity can arise easily and quickly; every new customer view can become a very complex subsystem. For example, each customer grouping could have its own reference tables of additional facts about that grouping level. Likewise, contact names, telephone numbers — even support for multiple “kinds of” contacts and decision makers — can all add to what you will ultimately implement. Be careful to avoid creating an uncontrolled number of new applications to support this one identification logical table. With a resource like this one established and maintained, the proper data will exist as the corporate resource and “system of record” for all views of customer identification. This resource can then support the creation of multiple data marts containing multiple or varying customer aggregations based on the needs of the data mart end users.
Open Your Eyes
Although I haven’t mined the full depths of customer identification here, I’ve presented several perspectives and a few hints for possible solutions. In summary, if you’re addressing customer identification issues in your organization, establish the customer views you will need to support, work on the supporting structure — in people and software — that you’ll need to properly maintain those views, and start attacking your problem from there. Most likely, you will need to begin with an implementation that supports just one initial perspective, and then add additional ones slowly over time.
Todd Schraml (tschraml@reveregroup.com) is a technical specialist with The Revere Group, a consulting firm focused on e-business solutions. He has 11 years of experience in data warehousing across the telecommunications, temporary help services, and insurance industries.
Copyright © 2004 CMP Media Inc. ALL RIGHTS RESERVED |
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|