WO1998049640A1

WO1998049640A1 - Client profile management within a marketing system

Info

Publication number: WO1998049640A1
Application number: PCT/US1998/006448
Authority: WO
Inventors: Roger Dean Wilkinson; Rob Scott; Lisa Goehring La Rue; Dan Zeltner; Larry Smyth
Original assignee: Mci Worldcom, Inc.
Priority date: 1997-04-29
Filing date: 1998-04-01
Publication date: 1998-11-05
Also published as: AU6793498A; CA2287158A1; JP2002511166A; EP0979477A1

Abstract

A computer system includes a database and management software for managing client profiles that are used in marketing contacts. The management software is able to receive and process input data from multiple provider sources for addition to the database. The processing that is perfomed may include that application of data hygiene rules and the reformatting of data into a standardized format. The processing may also include the application of matching rules to determine whether a client profile already exists for the client that is associated with the input data. Overlay rules may be applied to resolve how a client profile shoud be uptdated when a client profile already exists for the client associated with the input data. In this fashion, the management software is able to readily update the database with data received from multiple data sources.

Description

CLIENT PROFILE MANAGEMENT WITHIN A MARKETING SYSTEM

TECHNICAL FIELD

The present invention relates generally to telecommunication systems and, more particularly, to client profile management in a marketing system.

BACKGROUND OF THE INVENTION

Telemarketing, direct mail and direct sales have become more widespread in recent years. A diversity of businesses are employing marketing to sell their goods and services. One of the goals of such marketing is to establish new customers so as to expand the customer base of a business. These businesses desire to target potential customers who are most likely to be effectively solicited by marketing campaigns and contacts.

Conventional systems identify potential customers for contact by telephone numbers or addresses. In general, batches of telephone numbers or addresses are placed on contact lists and mass calling mailing or visiting campaigns are performed. Unfortunately, such mass campaigns are not very effective in that they generally have high failure rates. In addition, such campaigns utilize a large volume of resources.

SUMMARY OF THE INVENTION

The present invention provides a more effective approach to marketing campaigns and contacts. The present invention focuses on a client profile management system that is part of a larger marketing system. The client profile management system maintains a database of client profiles. The client profiles may include individuals or businesses. The profiles are maintained, not on a per telephone or address basis, but rather on a per individual basis. As such, separate client profiles may be maintained for two individuals that live at the same address and share a common phone number. In addition, the client profiles may be updated to reflect changes in a client, such as telephone number changes, name changes, and address changes. The client profiles may be received as input for the client profile database in a number of different formats. The client profile management system provides mechanisms for parsing and formatting such input into a standardized format that is acceptable to the database.

In accordance with a first aspect of the present invention, a method is practiced in a computer system that has a database for holding client profiles. Each client profile holds information regarding clients for marketing contacts. In this method, input data that holds data about a client is received from a data provider for possible addition to the database. Matching rules are applied to deteπnine whether the input data is for a selected client that already has a client profile in the database. The matching rules compare any name information and any address information in the input data with any name information and any address information in the client profile for the selected client. If it is determined by the matching rules that the input data is not for a selected client that already has a client profile in the database, a new client profile is created for the selected client in the database to hold data from the input data. On the other hand, if it is determined by the matching rules that the input data is for a selected client that already has a client profile in the databases, overlay rules are applied to determine how to update the client profile in view of the input data. The client profile is then updated.

In accordance with another aspect of the present invention, a first client profile for a first client at a given telephone number is stored in a database. The database stores client profiles for the marketing contact such that each client profile stores information regarding a client. A second client profile for a second client at the given telephone number is also stored in the database. The database has an index for accessing the client profiles on a per client basis. Thus, separate client profiles are provided for a single phone number in the database. In accordance with a further aspect of the present invention, a first address is stored in the database for a selected client in the client profile. The database stores client profiles for marketing contact. A second informational or former address for the selected client is stored in the client profile as well. In response to a request from a requester, one of the addresses stored in the client profile is provided to the requester. Hence, the database stores multiple addresses for a single client.

In accordance with an additional aspect of the present invention, a first set of input data is received in a first format from a first data provider at a computer system. The computer system holds a database that has client profiles for holding information regarding clients for marketing contact. The first set of data is reformatted into a standardized format and at least some of the data in the first set of input data is added to a first client profile in the database. A second set of input data and a second format is received from a second data profile at the computer system. The second set of input data is reformatted into the standardized format and at least some of the data in the second set of input data is added to a second client profile in the database. The computer system includes the ability to receive and integrate data from multiple data providers in different data formats.

BRIEF DESCRIPTION OF THE DRAWINGS

A preferred embodiment of the present invention will be described below relative to the following drawings.

Figure 1 is a block diagram illustrating the strategic marketing (SaMS) infrastructure that is suitable for practicing the preferred embodiment of the present invention.

Figure 2 is a block diagram of a computer system that is suitable for practicing the preferred embodiment of the present invention. Figure 3 illustrates the logical organization of the CARMA database.

Figure 4 illustrates data flow within CARMA.

Figure 5 is a flowchart illustrating the steps that are performed to process data by CARMA.

Figure 6 is a flowchart illustrating the steps that are performed to apply the matching rules.

Figure 7 is a diagram that illustrates the different categories of rules that are found within the match rule table. Figure 8 is a diagram that illustrates the different types of overlay rules that are found in the preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The preferred embodiment of the present invention provides a client acquisition and retention management architecture (CARMA). CARMA is part of a strategic marketing system (SaMS) infrastructure that provides client management, information management and contact services for a marketing system. CARMA collects, tracks, and manages client information for marketing and sales functions. CARMA is flexible enough to be used by virtually any type of business and can track a wide range of information regarding clients. Information regarding the clients may be obtained from virtually any source in any format. CARMA provides processing for standardizing data formats and performing hygiene functions on input data.

As will be described in more detail below, CARMA includes a database of client profiles and program code for managing the client profiles. CARMA receives input data from multiple sources and processes the input data to create new client profile records in the database. In addition, CARMA determines whether input data is received for a client that already has an associated client record within the database. CARMA provides matching techniques for locating such matches and provides overlay rules for resolving how the existing client profile should be updated.

The client profiles are created on a per individual basis rather than on a per telephone basis or a per address basis. Multiple clients may share a common telephone number or address. Profiling information and characteristics is, thus, applied to individuals rather than to an entire household. CARMA also may maintain multiple relationships per client, including multiple addresses, multiple account numbers, multiple membership numbers, multiple input source (list) entries and multiple phone numbers per client. CARMA facilitates changes in client profiles by performing continuous ongoing tracking of clients. Address changes, telephone number changes, name changes, service connections and service disconnections may be tracked via CARMA.

Figure 1 is a block diagram illustrating the SaMS infrastructure 10. The SaMS infrastructure 10 includes CARMA 12 and data providers 14. The data providers 14 provide input data to CARMA 12 that is processed for integration into the client database maintained by CARMA. The input data may originate from external data sources 16 that originate outside the SaMS infrastructure 10 and internal data sources 18 that reside within the infrastructure. The SaMS infrastructure 10 also includes a decision support system (DSS), which is a large-scale data warehouse that includes programs for collecting, storing, managing, distributing, and analyzing data. Data from the data providers 14 is also passed to DSS 20 for integration into the data warehouse. CARMA 12 interacts with DSS 20 in that updates to client profiles are passed by CARMA 12 to DSS 20 in a generalized format. DSS 20 collects data from the data providers 14 where client identification is not a concern. Such data may include, for example, the number of people who move between a given pair of states, the number of people who purchase both a car and home stereo in the same year, or the number of women who own a business and are members of a political party. The data collected by DSS 20 varies according to business needs of users of the SaMS infrastructure 10. DSS 20 provides access to this data by business strategy units (BSU) 22. A BSU is a company's organization that is responsible for formulating business, marketing, and sales strategy. Each BSU performs strategic queries of data in the data warehouse of DSS 20 using analytical tools provided by DSS. The results of these queries are used by the BSUs 22 to formulate marketing campaigns.

The SaMS infrastructure 10 also includes a contact infrastructure (CONI) 24. CONI 24 is a software system that uses data extracted from the data warehouse along with specific strategies from the business strategy units 22 to generate leads that marketing personnel may use. These leads are deposited within a centralized lead repository (CLR) 26. The business strategy units 22 specify criteria to CONI that CONI is to use in extracting lead data from DSS 20. The lead data identifies client leads (i.e., potential customers who are to be targeted in a marketing campaign). Client leads are identified by a client identifier that is stored in DSS 20. CONI 24 generates leads by matching these client identifiers with a name, address and/or telephone number that are obtained from CARMA 12. CONI is described in more detail in copending application entitled, "SYSTEM AND METHOD FOR AUTOMATED LEAD GENERATION AND CLIENT CONTACT MANAGEMENT FOR A SALES AND MARKETING PLATFORM," which was filed on even data herewith, which is assigned to a common assignee with the present application and which is explicitly incorporated by reference herein.

The leads that are generated by CONI 24 and stored in the CLR 26 are distributed to one or more telemarketing/direct mail centers (TM/DM Centers) 28. These centers may include call centers from which telemarketing agents perform client contact sales and services over the telephone. These centers may also include direct mail campaign facilities. The agents at the TM/DM center 28 use the leads provided via CLR 26 and store the results of contacts made using the leads in the CLR. These results may be fed back to both CARMA 12 and DSS 20. When an agent at one of the TM/DM Centers 28 succeeds in signing up a new customer or making a sale, the order may be entered in the customer order entry system 30. The customer order entry system records the order and provisions the order. The customer order entry system 30 also updates DSS 20 to indicate the results of the order. If the order is for long distance service, the order is passed to a national local exchange carrier (LEC) interface system (NLIS) and quick PIC system 32. These systems 32 pass the order to the client's LEC 34 so that the LEC can convert the client's PIC at the local class 5 switch. The SaMS infrastructure 10 is described in more detail in copending application entitled "SYSTEM AND METHOD FOR AUTOMATED LEAD GENERATION AND CLIENT CONTACT MANAGEMENT FOR A SALES AND MARKETING PLATFORM," which was filed on even date herewith, which is assigned to a common assignee with the present application and which is explicitly incorporated by reference herein.

CARMA 12 may be run on a number of different types of computer systems. Figure 2 is a block diagram illustrating a computer system 40 that is suitable for ranning CARMA 12. A mid-range computer that employs the DEC Alpha processor from Digital Equipment Corporation of Maynard, Massachusetts, is suitable for ranning CARMA 12. Computer system 40 includes a central processing unit (CPU) 42 that is responsible for overseeing operation of the computer system. The CPU may include a number of peripheral devices, such as a video display 44 and an input device 46. The computer system 40 may also include a network adapter 48 for interfacing the computer system with a local area network. A modem 50 may be provided in the computer system 40 to facilitate communications with remote computing resources over conventional telephone lines. The computer system 40 may include a number of different types of storage 52, including primary storage and secondary storage. The storage 52 holds a client database 56 and a copy of the program code 54 for CARMA. Those skilled in the art will appreciate that the computer system 40 may be alternatively a multiprocessor system or a distributed system. The present invention is not limited to being practiced on a single processor system. The client database 56 has a logical architecture like that depicted in Figure 3. The client database 56 contains a number of different tables, where each table contains different information regarding a client. Each client is assigned a unique client identifier (client id). This client identifier links information that is kept in the different tables about the client. The linked records for a client in aggregate, constitute the client profile for the client. The three primary tables in the client database 56 are the client table 60, the address table 82, and the domestic phone table 90. Each record in the client table 60 contains information about a client, such as client ID, social security number, name, and professional title. The address table 82 holds information about the client's address, whereas the domestic phone table 90 holds information regarding a client's phone number and phone service.

It should be appreciated that there may be a one to many relationship between the client table 60 and the address table 82, as well as between the client table 60 and the domestic phone table 90. A client may have multiple addresses and multiple phone numbers associated with it. Each of the addresses has a separate record in the client address table 80 and each of the domestic phone numbers has a separate record in the domestic phase table 90. The client table 60 and the address table 82 are linked by an intermediate table: the client address table 80. Each address of a client has a record in the client address table 80 that is linked to the client table 60 by "clnt id". Each address has a status indicator ("adr stat") within the client address table 80. The address status indicator may have a value of "active," "obsolete" or "informational." This status indicator is useful in tracking a client as a client moves among addresses. An address identifier ("adr id") is held in the client address table to link the record and the client address table to the address record in the address table 82.

The client phone table 76 serves as an intermediate table between the client table 60 and the domestic phone table 90. For each phone number or client, the client phone table 76 contains a phone number in three fields: "npa," "nxx," and "line."

Suppression tables are also provided for the intermediate tables (e.g., the client address table 80 and the client phone table 76). In particular, the client address supp table 84 holds suppression information regarding a client address. Similarly, the client phone supp table 88 holds suppression information regarding a client phone number. The phone supp table 92 holds suppression information regarding records stored within the domestic phone table 90. Analogously, the address supp table 88 holds suppression information for records stored in the address table 82. Household enhancement information is stored within the address enhancement table 86. Enhancement information for clients may be stored in the client enhancement table 74.

A client account table 66 tracks internal account numbers for the client. There may be a one to many relationship between the client table 60 and the client account table 66. In other words, information about multiple accounts may be stored for a given client.

A client member table 70 tracks a client's memberships in affiliate clubs, affinity clubs, and various other clubs. Examples include airline frequent flyer clubs, professional organizations, auto clubs, credit cards, travel clubs, health clubs, and the like. There may be relationships between records in the client member table 70 and records in the client table 60.

The client prov detail table 72 holds detailed audit information regarding the data provider, such as a client's phone, address, and name as provided by each source. The client enhancement table 74 holds enhancement information regarding clients. The client language table 78 holds information regarding the natural language that the client speaks and/or understands. Multiple client language records may be provided for a single client. The client list table 62 serves as an intermediate table for linking a client as identified by a client identifier with a list record in the list table 61 which defines all sources (lists) by which a client has been received.

As was mentioned above, CARMA 12 is able to process input data for multiple data sources and to update the data in the client database 56 accordingly. This process of handling new input data will be described below relative to Figures 4 and 5. New input data is processed in load transactions. Initially, the raw input data is received at CARMA 12 from the data providers 14 (step 120 in Figure 5). As was mentioned above, the data providers may be both external and internal and may provide a variety of different types of information. A scheduler 100 is responsible for invoking the respective stages of processing performed by CARMA 12. The scheduler initiates and monitors the data load process upon receipt of the data. The scheduler initially causes formatting and data hygiene to be performed on the raw input data (step 122 in Figure 5). This formatting and data hygiene is performed by a stage load process 102 (Figure 4). The stage load process 102 performs standardization of names and addresses of clients. The stage load process ensures that client identification (in the form of a name, social security number, or other common identifier) is valid and that certain information, such as mailing address, is valid and in a proper format.

In the preferred embodiment of the present invention, CARMA 12 uses the PostalSoft' s TrueName product 104 and the ACE product 105. Mapping mechanism 103 determines which of the products 104 and 105 should be uxsed on input data. PostalSoft 104 standardizes, parses, corrects, translates, appends, and validates name/address information in the data input from the data providers 14. In general, PostalSoft parses all billing names and address information into standard name and address database attributes. ACE 305 also performs standard billing address append functionalities, such as the identification and attachment of full nine digit zip codes, carry routes, geographic match codes and check digits for bar-coding. Street suffix values unit designators are also standardized by TrueName. TrueName 104 maintains a reference list of first names and associates a gender code with each first name (i.e., male, female).

The preferred embodiment of the present invention also includes a number of custom coded edits or translations 106 that embellish the PostalSoft product 104. For example, the name information is always placed at the beginning of the output. Invalid characters are not permitted in names and extra blanks are eliminated in names and addresses. Literals such as "in care of or "attention of are deleted. Repeated names within first name fields and last name fields are deleted. Invalid names are eliminated. This may include the elimination of profanity and repetitive characters. The name components of input are removed if the hygiene score is below a predefined threshold value. Stage load process 102 outputs the validated standardized data to an interim data store 108. This enables a user to view and approve the data using the computer system 40 before the data is passed on to a final load process 110. The final load process 110 performs some additional processing of the data before data is added to the client database 56. The final load process 110 entails applying client matching algorithms 112. These client matching algorithms 112 are applied to determine if the client identification information that is provided and the data matches an existing client in the client database (step 124 in Figure 5). Figure 6 is a flow chart illustrating in more detail how the client matching rules are applied. First, critical matching criteria is examined for records in the client database 56 and information contained in the input data. Values that indicate the matching condition for each of a number of different criteria are assigned (see step 134 in Figure 6). The critical matching criteria include a social security number matching (SSN) criteria 19. The value for the social security number matching criteria may be "Y", indicating that there is a match and that both the input data and the record in the client database 56 include a populated social security field. The value may also be "N" indicating that there is no match but that the input data and the database record include a social security number value. The value may lastly be "B", indicating that one or both of the input data or the database record do not contain a social security number value.

Last names are compared to determine a value for a last name match (LNM) matching criteria. A value of "Y" for the LNM criteria indicates an exact match excluding spaces and special characters, identified misspellings, and hyphenated last names for married women. A value of "N" indicates no match and that a last name is provided both in the input data and the database record. First names are compared in obtaining a value for a first name match (FNM) criteria. A value of "Y" indicates an exact match including equivalent nicknames, abbreviations, and identified misspellings. An exact match may also be found where the first letter of the first name, including equivalent nicknames and abbreviations, match but only if the input data or the database record has a first name as an initial. Lastly, an exact match can be found if it matches to a nickname table entry. A value of "N" indicates that there is no match and that a first name is specified in both the input data and the database record.

Middle names are compared to yield a value for a middle name match (MNM) criteria. The MNM criteria may have a value of "Y", which indicates an exact match, equivalent nicknames and equivalent abbreviations. A value of "N" indicates that there is no match and that a middle name is specified in both the input data and the database record. A value of "B" indicates that one or both of the input data in the database record are not populated with a middle name.

Gender is compared in the gender (GDR) matching criteria. A value of "N" indicates that no match is found between a male, female, or company genders in both the input data and the database record. A value of "A" indicates that the input data or the database record is populated with an ambiguous gender value. A value of "M" indicates that both the input data and the database record are populated with male gender codes. A value of "F" indicates that both the input data and the database record are populated with female gender codes. A value of "C" indicates that both sources are populated with company gender codes.

Titles of clients are compared to yield a value for the title (TTL) matching criteria. A value of " Y" indicates an exact match on a courtesy title or match of equivalent ambiguous values. For example, the abbreviation "Mrs." matches "Ms." A value of "N" indicates that there is no match and that both the input data and the database record are populated with courtesy titles. A value of "B" indicates that the input data or the database record or both are not populated with a courtesy title.

Zip codes are compared to yield the value for a zip code matching criteria (ZIP). A value of "9" indicates an exact match of a full nine-digit zip code. A value of "7" indicates a match on the first seven digits of a zip code. A value of "5" indicates a match on the first five digits of a zip code A value of "N" indicates no match and that both the input data and the database record are populated with zip codes. Street names and street suffixes are compared in the street names and street suffixes (STR) matching criteria. A value of "Y" indicates an exact match of street names and street suffixes. A value of "N" indicates no match and that both the input data and the database record are populated or that one of these two is not populated. A value of "B" indicates that both the input data and the database record are not populated with a street name or a street suffix.

An address number or P.O. Box number is compared to yield the value for the number (NBR) matching criteria. A value of " Y" indicates an exact match. A value of "N" indicates no match and that both the input data and the database record are populated by the same type of information.

Apartment numbers are compared to yield the value for the apartment (APT) matching criteria. A value of " Y" indicates an exact match. A value of "N" indicates that there is not a match and that both the input data and the database record contain an apartment number specification. A value of "B" indicates that the input data or the database record is not populated with an apartment number.

Phone numbers are compared to yield a value for the phone number (PHN) matching criteria. A value of "Y" indicates an exact match of phone numbers. A value of "N" indicates that there is not a match and that both the input data and the database record contain phone numbers. A value of "B" indicates that either the input data or the database record do not contain a phone number.

Account numbers are compared to yield the value for the account number (ACC) matching criteria. A value of "Y" indicates an exact match where both the input data and the database record are populated with an account number. A value of "N" indicates that the input data and the database record contain account numbers and that there is no match between the account numbers. A value of "B" indicates that one or both of the input data and the database record are not populated with an account number.

Membership numbers are compared to yield a value for the membership number (MEM) criteria. A value of "Y" indicates an exact match on a specific membership number. A value of "N" indicates that there is no match and that both the input data and the database record are populated with the same type of membership number. A value of "B" indicates that one or both of the input data and the database record are not populated with the membership number.

Client id's may be compared to yield a value for the client id matching criteria. A value of "Y" indicates an exact match where both the input data and the database record are populated with client ids. A value of "N" indicates that there is no match and that both the input data and the database record are populated with client ids. A value of "B" indicates that one or both of the input data and the database record are not populated with a client ID. It should be noted that each of these matching criteria may also assume a value of "-" indicating that the determination of whether there is a match or not is not dependent upon that criteria.

The values are utilized by applying match rales using a match rale tables to determine if there is a match (step 136 in Figure 6). An example of match rale is as follows:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 scenario result-rule

- Y Y Y M B Y Y Y Y - 00113 MATCH

- Y Y Y M B Y Y Y N - 00114 MATCH

- Y Y Y M B Y Y Y B - 00115 MATCH

- Y Y Y M B Y Y N Y - 00116 MATCH

- Y Y Y M B Y Y N B - 00118 MATCH

1 = SSN 2 = LNM 3 = FNM 4 = MNM 5 = GDR 6 = TTL 7 = ZIP 8 = STR 9 = NBR 10 = APT

11= PHN 12 = ACC 13= MEM 14 = CLN

Each row within the match rule table contains a scenario and a result (note the columns labeled "scenario" and "result-rule"). Each row may be considered a separate rule. Each other column specifies a particular value for one of the 14 match criteria described above (see the Legend above). If the criteria have the value specified in the columns, then the rale is fulfilled and the result of the rule is applied. For example, scenario 113 specifies that if there is a last name match (column 2 is "Y"), there is a first name match (column 3 is "Y"), there is a middle name match (column 4 is "Y"), both the input data and the database record are populated with male gender codes (column 5 is "M"), one or both the sources are not populated with a courtesy title (column 6 is "B"), there is a zip code match (column 7 is "Y"), there is a street name and street name suffix match (column 8 is "Y"), there is a number match (column 9 is "Y") and there is an apartment match (column 10 is "Y"), it is determined that the input data and the database record match. As a result, a determination is made in step 126 of Figure 5 of whether there is a match or not by applying the match rale tables.

It should be appreciated that there are a number of different combinations or scenarios within the match rale table that could be categorized into the categories set forth in Figure 7. In particular, the match rule table contains the following combinations: name and address combinations 140, name and phone combinations 142, name and social security number combinations 144, name and account combinations 146, name and membership number combinations 148, name and client ID combinations 150, address and phone combinations 152, address and account combinations 154, address and membership number combinations 156, phone and account combinations 158, phone and membership number combinations 160, and account and membership number combinations 162. If it is determined in step 126 that there is not a match between the input data and any database records that hold client profiles, a new record may be created and a new client identifier is assigned to the client (step 128 in Figure 5). The new record is filled in with the data that is provided in the input data that has been processed by the stage load process 102. In contrast, if a match is found, an overlay process is applied to determine how to resolve the conflict between the client information contained in the input data and the client database record (step 130 in Figure 5). In general, as will be described in more detail below, the overlay process applies overlay rales and resolution rules to determine how to resolve the conflicts and the data is updated accordingly within the client database 56 (step 132 in Figure 5). This overlay process is depicted as overlays 114 in Figure 4 and results in data that is passed to the client database 56.

Figure 8 depicts different varieties of overlay rules 164 that are provided by CARMA 12. There are client overlay rales 166. The general approach of the client overlay rules is after receiving an indication that there is a match, the name fields in the client database 56 are only updated if the input data has more complete information. The client overlay rales contain specific rules directed to fields in the client table 60. The active address overlay rales 168 specify how active address information within the client database 56 should be overlaid relative to input data that matches. The informational address overlay rales 170 specify how informational address information should be overlaid. The phone number overlay rales 172 specify how phone number information should be overlaid. The enhancement overlay rales 174 specify how enhancements should be overlaid. The list specific database table overlay rules specify what database tables are allowed to be updated for any specific load feed. Lastly, the client_provider_detail overlay rales indicate how client provider information in the database 56 should be overlaid.

Once a client database 56 has been updated, the changes may be replicated by a client database replication process 116 and may be passed on to a data harvesting facility for an operational data store managed by the DSS 20. Changes are captured by a changed data capture process 118 that forwards the changes to the data harvesting process 96 of the data warehouse of DSS 20. Therefore, CARMA 12 provides an integrated system for client profile management that provides a number of unique features. CARMA tracks individual clients as individuals for other than as telephone numbers or addresses so that multiple clients that share telephone numbers or addresses may be tracked. CARMA 12 maintains multiple relationships, including multiple addresses per client and multiple phone numbers per client. This facilitates complete tracking of clients having multiple phone numbers or addresses. CARMA 12 provides continuous ongoing tracking of clients and readily facilitates changes to client profiles. CARMA 12 includes processing resources for accepting and using input data of almost any type in any format. Still further, CARMA performs effective client matching to avoid duplicate client profiles.

While the present invention has been described with reference to a preferred embodiment thereof, those skilled in the art will appreciate that various changes in form and detail may be made without departing from the intended scope of the present invention as defined in the appended claims.

Claims

1. In a computer system having a database holding client profiles that each hold information regarding clients for marketing contact, a method comprising the computer-implemented steps of: receiving input data holding data about a client from a data provider for possible addition to the database; applying matching rales that determine whether the input data is for a selected client that already has a client profile in the database, wherein the matching rales compare any name information and any address information in the input data with any name information and any address information in the client profile for the selected client; if it is determined by the matching rules that the input data is not for a selected client that already has a client profile in the database, creating a new client profile for the selected client in the database to hold data from the input data; if it is determined by the matching rales that the input data is for a selected client that already has a client profile in the database, applying overlay rales to determine how to update the client profile in the database for the selected client in view of the input data; and updating the client profile in the database based on how it was determined to update the client profile in the database by applying the overlay rules.

2. The method of claim 1 wherein the matching rules compare any social security number information in the input data and with any social security information in the client profile for the selected client.

3. The method of claim 1 wherein the matching rales compare any phone numbers in the input data with any phone numbers in the client profile for the selected client.

4. The method of claim 1 wherein the matching rales compare any account numbers in the input data with any account numbers in the client profile for the selected client.

5. The method of claim 1 wherein the matching rales compare any membership numbers in the input data with any membership numbers in the client profile for the selected client.

6. The method of claim 1, further comprising the step of formatting the input data into a standard format prior to applying the matching rales.

7. The method of claim 6, further comprising the step of applying data hygiene rales to remove unwanted data in the input data prior to applying the matching rales.

8. The method of claim 1, further comprising the step of applying data hygiene rales to remove unwanted data in the input data prior to applying the matching rales.

9. A computer-readable medium holding computer-executable instructions for performing a method comprising the computer-implemented steps of: receiving input data holding data about a client from a data provider for possible addition to the database; applying matching rules that determine whether the input data is for a selected client that already has a client profile in the database, wherein the matching rales compare any name information and any address information in the input data with any name information and any address information in the client profile for the selected client; if it is determined by the matching rules that the input data is not for a selected client that already has a client profile in the database, creating a new client profile for the selected client in the database to hold data from the input data; if it is dete╧Çnined by the matching rales that the input data is for a selected client that already has a client profile in the database, applying overlay rales to determine how to update the client profile in the database for the selected client in view of the input data; and updating the client profile in the database based on how it was determined to update the client profile in the database by applying the overlay rules.

10. In a computer system, a method comprising the computer- implemented steps of: providing a database for storing client profiles for marketing contact wherein each client profile stored information regarding a client; storing a first client profile for a first client at a given telephone number in the database; storing a second client profile for a second client at the given telephone number in the database; and indexing the database for accessing the client profiles on a per client basis.

11. The method of claim 10, further comprising the steps of receiving a request to access the first client profile and granting access to the first client profile in response to the request.

12. In a computer system, a method comprising the computer- implemented steps of: providing a database for storing client profiles for marketing contact wherein each client profile stores information regarding a client; storing a first address in the database for a selected client in a client profile for the selected client; storing a second address in the database for the selected client in the client profile for the selected client; and in response to a request from a requester, providing one of the first address and the second address for the selected client to the requester.

13. The method of claim 12 wherein the method further comprises the step of storing a first phone number in the database for a given client in a given client profile for the given client and storing a second phone number in the database for the given client in the given client profile.

14. In a computer system having a database holding client profiles that hold information regarding clients for marketing contact, a method comprising the computer-implemented steps of: receiving a first set of input data in a first format from a first data provider; reformatting the first set of input data into a standardized format; adding at least some of the data in the first set of input data to a first client profile in the database; receiving a second set of input data in a second format from a second data provider; reformatting the second set of input data into the standardized format; and adding at least some of the data in the second set of input data to a second client profile in the database.

15. The method of claim 14 wherein the first format and the second format differ.

16. The method of claim 14 wherein the first set of input data contains data of different data type than data found in the second set of input data.

17. The method of claim 15 wherein the first data provider is external to the computer system.