Customer Relationship Manage-ment (CRM). This combination of sales force automation (SFA), database marketing and data warehousing has perhaps focused us too much on existing customers, causing us to forget that there is a whole world of untapped potential relationships to be pursued.
SFA and CRM vendors tend to only include retention, up-sell and loyalty of existing customers and, as such, are narrowly defining the major focus of the customer relationship management data architecture. The common implementation focuses on establishing the multitude of feeds from the touchpoint transaction (both traditional and Internet) and billing systems to capture a transaction history and profile in a database (either operational data store or data warehouse). The goal is eventual exploitation by closed-loop campaign engines and exploitation marts. This CRM data architecture is too narrow and, if adopted by certain types of companies, will cause bottlenecks and missed opportunities.
The CRM data focus should be broadened to include acquisition strategy (not just retention and loyalty), survey, fulfillment and other non-sale interactions that a customer-only perspective would omit. Consider the concept of prospect relationship management (PRM) with the premise that anyone is a prospect. All customers are (up-sell or cross-sell) prospects, non-customers are prospects and all prospects are to be related to as intimately as possible by gathering history and enabling our touchpoint systems to appreciate that history. Obviously, more data has been accumulated on current customers, so the potential intimacy of the customer relationship is heightened. To ignore non-customers in the architecture, however, is shortsighted.
The PRM premise is a simple one that can only be appreciated with advances in technology, specifically data warehouse-based designs, parallel DBMS engines/utilities and the Internet. Only now can a business compile data from the customer negotiation, order and billing systems and merge them rapidly with external data (e.g., purchased demographic or lifestyle data) and Internet clickstream (not necessarily sale-only) data. Most importantly, the ability for terabyte-level prospect pools to be created and updated with extensive history is enabled with trickle-feed warehouses and non- disruptive physical data movement technology.
PRM is implemented in a very different fashion than CRM in that it assumes that all data is not created equal. In fact, only some customer data is relevant as received as an asset to leverage relationship management. PRM assumes that base customer data is superceded in importance by customer aggregates, external purchased demographic and lifestyle data, and derived customer value (segmentation, lifetime value, propensity to buy, etc). Therefore, a divorce of prospect data and customer data, seemingly heresy in traditional CRM, is a cornerstone of a PRM architecture.
For example, the billing system of any company contains volumes of account and customer information developed at a granularity to produce a bill and perhaps to report revenue and interface to the financials. The only base data out of this environment that is meaningful for PRM would be billing name, billing address and products sold. More meaningful are the derived factors of payment history, average billed revenue and products possessed (not just billed this bill instance). The real value of this data can be appreciated when some base customer data is combined with aggregates and purchased data at a grain which is prospect specific, not account or customer specific. There-fore, a new data store at a prospect level must be established separately from the transaction-capturing systems, the purchased data capture systems and the aggregation systems.
As another example, the ordering system of any company contains many attributes about the sale which simply have no value after the transaction has been posted. Order number, shipping tracking data, tax, postage, etc., are of no value once the transaction is complete. Each company can decide if data, such as shipping address, method of payment, credit card number, etc., is worth keeping en masse.
What's the Difference?
The obvious difference between PRM and CRM is the scope of externally purchased demographic and lifestyle data that is considered relevant for the enterprise. In CRM, the external data that matches an existing customer is appended to the customer data in order to achieve greater insight. In PRM, all purchased prospect data is stored regardless of whether the prospect has an existing customer relationship or not.
Architecting a PRM Solution
What is required to adopt a PRM strategy rather than a CRM strategy?
Admit that your major customer systems each have a stove-pipe perspective that not only needs resolving, but enhancing. Billing, traditional order entry, Web site order entry, customer care and call center systems all have inherent focal points. Producing/formatting bills, streamlining contact time and validating operational data are all local needs met with local applications and data structures. CRM and PRM both recognize the need to resolve disparate key structures (billing-account-ID, customer-ID, Web site logon/password, billing/ship-ping/service address, service type, etc.), but only PRM proposes development of an abstract key unrelated to any of these. This ensures that even a non-customer can be stored and eventually merged when they execute customer transactions and become a customer while remaining a prospect (for other non-sold products).
Divorce customer from prospect. Allow your customer data stores to contain all data fed from transaction systems. Then consciously decide which subset of customer data is to be copied to another environment where the merge with externally purchased data and aggregates may be exploited. Optimally, create an abstracted view of customer events which holds simple (transaction/event type, date, business unit and disposition) records so that all touchpoints can be understood in a standard fashion.
This separation of concept is also due to the need to:
Store history differently. The prospect data store (with external data, aggregates and some customer data) will have retention needs that are very different from the customer data store. The prospect data store should:
- Allow continuous, multilevel and long-term campaigns to be targeted and tracked,
- Allow recent customer interactions to be analyzed into patterns, and
- Allow consistent updates of certain transactions, each with a different feed schedule and merge/purge priority.
The customer data store historical need is driven from broader customer analyses that have had, at times, little to do with relationship management. Profitability, revenue analysis, product penetration and sales/commission tracking require the collection of the customer data and the transactions that created the data but have little to do with the ongoing improvement of the customer relationship. These historical needs are related to fiscal concerns, a legal need to retain data and internal financial parameters that are absolutely unrelated to ensuring customer satisfaction.
Consequently, it is easy to see that a prospect data store may contain 100 million prospects, each with 400 attributes to enable marketing and customer relationship management and, concurrently, the customer data store could contain 25 million customers with 250 different and 150 similar attributes to the prospect data store.
Admit this and selectively copy some base customer attributes into the prospect world. Treat both with equal, but different, respect as exploitable warehouses established at the appropriate grain for the needs of the business. Without this, contention for the "copied/shared" attributes is probable.
Allow purchased data to be unused for a while. Does this mean that an organization should buy, scrub and uniquely identify prospects and store that information even though there has never been any contact with this prospect (they are not a customer)? Yes, assuming you buy demographic and lifestyle data and that data is appended to existing customers, why not store all purchased data under a unique key and enable acquisition strategy development as well?
Given the explosion of potential channels in the Internet age, chances are that your business, especially a business with a low market share and/or a commodity product, could benefit from pre-allocating information about people "who will come." This "build-it-and-they-will-come" strategy is based on a premise that disk space is cheap but customer acquisition is expensive. If we can hold the information used to acquire a customer and eventually link it when they become a customer, we are way ahead of the company that waits and then requests and holds information about the prospect. Of course, the cold call transaction contains more meaningful context if we purposefully retain both the transaction and the information from which the transaction was triggered.
Establish abstractions in your prospect data store that are irrelevant to customer. The prospect store need not contain any detail not required for relationship management. The prospect data store must, however, enable disparate sources to combine regardless of the density of the acquired data. In other words, you cannot count on anything as base data from the external or internal sources. You may or may not have phone number, Web site address, name/address (in various parsing) from your multitudes of sources to the prospect store. Therefore, an abstract unique key and flexible abstracted confidence levels must be established as the core of the prospect data store.
As an example, if one feed contains five lines times 30 characters per line without city, state and ZIP parsed, and one source does not contain phone numbers but has other excellent value, use it all and append a "confidence level" to each of the sources in the "matching" routines that are necessary to merge these disparate sources. Of course, if the confidence of a source is so suspect as to get a low confidence level, one may question the purchase of the data at all.
Allow flexible, source-based dating of the data to be inherent in the database design of the prospect data store. The data in the prospect store will have different historical needs than the customer data store. It has to handle multiple sources with different receipt and validation patterns and will be retained in varying time periods.
For example, perhaps the relationship management prospect store gets seven feeds. It gets feeds from the clickstream hits daily, orders twice daily, billing snapshots monthly per bill cycle, demographics quarterly, lifestyle information monthly on the first of the month, segmentation is run twice a year, and lifetime value is derived after the bill snapshot revenues have been averaged, etc. Each source has its own timings, versions and dependencies.
Admit this. Don't try to jam everyone into a monthly update schedule or something nonintuitive. Build a dated-layer (prospect-ID + start date key) concept into all of the information fed to the prospect data store. Any query to the store must not only answer what data is requested, but also must specify "in what time period" is the data requested. This combination of current state and historical profiling is a powerful relationship management necessity.
By broadening the CRM concept to appreciate abstract prospect concepts, acquisition strategies, liberal use of external data and a separate but equal view of prospects and customers, your company will foster flexibility not previously foreseen. This PRM premise can be most appreciated in industries or organizations that are swamped with data from disparate sources such as merger participants, enterprises with multiple spin-offs and multi-product line conglomerates. It is most attractive to organizations with high-customer volume and low-loyalty commodity product companies such as telecommunications service providers, life/auto insurance carriers and banks.
PRM might not be for you, but think out of the box and give it a try. You may be surprised.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access