SYSTEM AND METHOD FOR AUTOMATED LEAD GENERATION AND CLIENT CONTACT MANAGEMENT FOR A SALES AND MARKETING PLATFORM

Abstract: A system and corresponding method provides complete functionality for creating and implementing marketing campaigns. The system formulates criteria for targeting clients based on marketing strategies, identifies and extracts targeted clients from a data warehouse, automatically generates leads/clients and tracks contact with such clients. The system is embodied in a contact service infrastructure (CONI). CONI provides contact management, marketing campaign management, and lead generation for an overall information systems architecture for strategic marketing. CONI enables many of the strategic targeted marketing functions of the overall information system architecture by generating leads or lead records needed to implement a marketing campaign, and tracking the activity conducted based on those leads.

Description: SYSTEM AND METHOD FOR AUTOMATED LEAD GENERATION AND CLIENT CONTACT MANAGEMENT FOR A SALES AND MARKETING PLATFORM TECHNICAL FIELD The present invention relates to database and record management systems. BACKGROUND OF THE INVENTION Companies from many different businesses and industries are engaging in new marketing strategies. To expand their customer base and establish new customers, companies must target potential customers with new or ongoing marketing campaigns and contact development campaigns. Due to global expansion and industry convergence, markets are expanding and the number of potential customers is increasing. Therefore, targeting potential customers must be done efficiently. Previous methods of identifying potential customers included identifying telephone numbers and corresponding customer names to perform mass calling campaigns. Mass calling campaigns are typically no longer effective because such campaigns require large volumes of resources, including telemarketers, telecommunication services, man hours, etc. Furthermore, mass calling campaigns often suffer from high failure rates. Moreover, since such campaigns focus on telephone numbers rather than individuals, the campaigns miss many potential customers. For example, one telephone number at a household could be associated with two or more individuals in that house, each of which may have separate needs, and each of which could be separately targeted. Customer data, including telephone numbers and customer names, are typically stored in a centralized and very large database. Prior calling campaigns would query the database for customers based on their telephone numbers (e.g., area code and/or three digit prefix). More recently, new marketing strategies and campaigns are formulated which query the database for certain criteria related to phone number records in the database. Since the database is centralized and very large, such queries consume significant processing time and are therefore time-consuming. Furthermore, results from such queries are often difficult to effectively employ in a given mass calling campaign. Moreover, marketing strategies and campaigns are limited to types and organizations of data within the database. SUMMARY OF THE INVENTION In a broad sense, the present invention embodies a computer implemented method for generating leads for marketing campaign from client records stored in a data warehouse. The method includes the steps of: (a) creating a mart containing a subset of the client records stored in the data warehouse, (b) selecting a subset of the client records contained in the mart based on a first query, and (c) constructing lead records based on the selected subset of the client records and additional information stored in the data warehouse. In a broad sense, the present invention also embodies a system for generating lead records for a marketing campaign based on client records stored in a database. The system includes a user interface unit, a campaign management unit, a lead qualification filter unit, a lead management unit and a formatter unit. The user interface unit accepts query commands from a user. The campaign management unit receives the query commands and creates a lead qualification filter. The lead qualification filter unit applies the lead qualification filter to the client data to extract selected client records. The lead management unit applies predetermined rules to the selected client records to produce a set of lead records. The formatter unit converts the lead records into formatted lead records for use in the marketing campaign. BRIEF DESCRIPTION OF THE DRAWINGS An exemplary embodiment of the present invention will be described in more detail relative to the following figures. Figure 1 is a block diagram showing an exemplary information system architecture suitable for practicing the exemplary embodiment of the present invention. Figure 2 is a block diagram of a contact service infrastructure shown in Figure 1. Figure 3 is a data flow diagram showing flow of data under an aspect of the information system architecture of Figure 1. Figure 4 is an exemplary data structure diagram of a lead record. Figure 5 is an exemplary data structure diagram of a lead distribution record. Figure 6 is an exemplary flowchart showing basic steps and associated displayed screens of processes performed by campaign management and lead inventory management processes of the contact service infrastructure of Figure 2. Figure 7 is a front view of a computer screen showing an exemplary user log in screen. Figure 8 is a front view of a computer screen showing an exemplary main menu screen. Figure 9 is a front view of a computer screen showing an exemplary status query and determination screen. Figure 10 is a front view of a computer screen showing an exemplary lead marts initial query screen. Figure 11 is a front view of a computer screen showing an exemplary initial query and display for a lead generation process. Figure 12 is a front view of a computer screen showing an exemplary table selection screen. Figures 13 and 14 are front views of a computer screen showing exemplary lead mart management screens. Figures 15 and 16 are front views of a computer screen showing exemplary distribution query and display screens for lead generation processes. Figure 17 is a front view of a computer screen showing an exemplary save, submit or open lead generation queries screen. Figures 18, 19, 20 and 21 are front views of a computer screen showing exemplary results display screens based on lead generation queries. Figures 22, 23 and 24 are front views of a computer screen showing exemplary sales city, forms and media type screens. Figure 25 is a front view of a computer screen showing an exemplary list code screen. Figure 26 is a front view of a computer screen showing an exemplary security screen. Figures 27A and 27B together show an exemplary table built for constructing a lead mart. DETAILED DESCRIPTION OF THE INVENTION An information system architecture, and in particular, a system and method for providing enhanced marketing services based on data stored in a database, is described in detail herein. In the following description, numerous specific details are set forth such as data flow, data formatting, user interfaces, organization and coupling of processes, etc., in order to provide a thorough understanding of the present invention. One skilled in the relevant art, however, will readily recognize that the present invention can be practiced without use of the specific details described herein, or with other specific data flow, data formatting, user interfaces, organization and coupling of processes, etc. Well-known structures, processes and steps are not shown or described in detail in order to avoid obscuring the present invention. 1. Overview An exemplary information system architecture and corresponding method under an embodiment of the present invention provides complete functionality for creating and implementing marketing campaigns, such as telemarketing and direct mail campaigns. The information system architecture permits users to formulate criteria for targeting potential customers or clients (e.g., a query) based on a marketing strategy, identify and extract targeted clients from a centralized database or data warehouse, automatically generate leads, and track client contacts. The information system architecture, and many of its individual components, can be used for marketing efforts in virtually any type of business, such as a long distance telephone service provider. The embodiments of the present invention are described herein with respect to a long distance telephone service provider, however, such description is for exemplary purposes only. The system includes a Contact Service Infrastructure (CONI). CONI is preferably a software-based system that runs on any type or types of computer(s) that meet minimum performance requirements. In its preferred embodiment, CONI provides client contact management, campaign management, and lead generation for the information system architecture. CONI provides many of the strategic targeted marketing functions in the information system architecture by generating leads needed to implement a marketing campaign, and tracking resulting activity based on those leads. CONI provides a graphical user interface (GUI) for users, where such users are typically business strategy units of a company (as discussed below). A user analyzes data from the data warehouse to formulate a new marketing strategy and employs CONI to implement that strategy. Employing the CONI GUI, the user specifies certain criteria to be used to target clients. CONI generates a query and extracts data from the data warehouse which meets the criteria or query to form a localized data mart. Users can add additional criteria to further define or narrow extracted data to a final list extracted from the data mart. The final list is then formatted into leads, complete with relevant data such as names, telephone numbers for telemarketing campaigns, mailing addresses for direct mail campaigns, etc. The formatted leads are then distributed to various telemarketing and direct mail centers. CONI also manages a given campaign by receiving results from each client contact. CONI directs appropriate records to be updated and arranges follow-up for certain leads if requested. CONI also feeds results of each client contact back to the data warehouse to provide a feedback loop in the information system architecture. Such feedback loop ensures that data stored therein is current and accurate. 2. System Architecture Referring to Figure 1, an exemplary information system architecture or strategic marketing system (SaMS) infrastructure 100 is shown. The various components of the SaMS Infrastructure 100 interact cooperatively as shown in Figure 1 to provide many targeted marketing functions, such as those described herein. The SaMS infrastructure 100 performs at least three functions: client management, information management, and contact services. "Client management" includes the process of identifying, tracking and managing all of a company's clients. "Clients" include both current customers and potential customers or leads, and therefore can consist of hundreds of millions of people for many companies. Client management involves descriptive behavioral data about clients as individuals (rather than being based on, e.g., phone numbers). A primary component in the SaMS Infrastructure 100 for client management is a Client Acquisition and Retention Management Architecture (CARMA) 102. CARMA 102 is preferably a software system that provides a database and data processing for client management. An exemplary embodiment of CARMA 102 is described in detail in co-pending U.S. Patent Application entitled "System For Managing Client Sales and Marketing Data," which is filed concurrently herewith and assigned to a common assignee of the present application. "Information management" is the process of collecting, storing, and managing data that reflects entire client populations and trends. Information management provides decision support functions and tools that place raw data in context for product and marketing strategies. Information management deals with descriptive behavioral data about generalized client populations. A primary component for information management is a Decision Support System (DSS) 104. The DSS 104 consists of a large-scale data warehouse, along with processes for collecting, storing, managing, distributing, and analyzing data. In general, a "data warehouse" is a consolidation of information for many departments or "Business Strategy Units" within a company, as well as information extracted from outside of the company. An exemplary embodiment of the DSS 104 is described below with respect to Figure 3. "Contact services" takes conclusions drawn from data warehouse queries and uses them to formulate marketing campaigns and generate leads. It also tracks and manages all contacts made with clients. CONI 106 provides contact services for the SaMS infrastructure 100. CONI 106 is preferably a software system that uses data extracted from the data warehouse of the DSS 104, along with specific strategies formulated by a company's Business Strategy Units to generate leads. CONI 106 interfaces with a Centralized Lead Repository (CLR) 108 to manage and track contacts with clients or leads, as described below. Information regarding such contacts made with clients are fed back to the client management function of the SaMS infrastructure 100. As a result, the client management, information management, and contact services functions of the SaMS infrastructure 100 is a cyclic process: the information management function puts raw data into context to perform research, draw conclusions and form strategies; the contact services function formalizes and implements marketing strategies based on the research, conclusions and strategies produced under the information management function; and the client management function identifies and tracks individuals, collects descriptive and behavioral data, and provides such data back to the information management function. Various data providers 110 provide data to both CARMA 102 and DSS 104. The data providers 110 include any source of data input to the SaMS Infrastructure 100 to provide information on clients. The data providers 110 consist of both internal data sources 112 and external data sources 114. Examples of internal data sources 112 include data feeds from billing systems, customer order entry systems, order provisioning systems, customer databases, marketing databases, customer service systems, accounts receivable systems, and many others. They may also include input from other components of the SaMS infrastructure 100, such as the CLR 108. Examples of external data sources 114 include files of telephone directories, U.S. Post Office directories, credit company reports, and many third party data products that provide specific data on people. These third party data products may include information such as products people buy, where people move to and from, services people utilize, and results from telephone surveys on people's interests and needs. External data sources 114 may also an airlines' frequent flier programs, auto club memberships, health club memberships, travel clubs, and magazine subscriptions. These data are used to aid in tracking clients via clients' memberships and participation in other businesses. CARMA 102 collects data about specific clients from the data providers 110, and uses the data to update client profiles. CARMA 102 then feeds any changes in client data to the DSS 104, but in a generalized form. That is, CARMA 102 does not send to the DSS 104 specific clients' names and addresses, but rather, sends information that reflects generic clients' profiles. CARMA 102 sends a unique client identifier with client profile changes, so that when leads are generated from data in the DSS 104, they can be matched to a specific name, address, and telephone number. In general, clients are typically identified under the SaMS infrastructure 100 based on their client identifiers, which are unique numeric or alphanumeric codes associated with each client. Client identifiers are maintained in CARMA 102 and the DSS 104. The DSS 104 also collects data from the data providers 110. The DSS 104 typically collects data unrelated to specific clients, but rather groups of clients. Such data may include the number of people who moved from one state to another, the number of people who purchased 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 possibilities for data collection by the DSS 104 are numerous, and vary according to the business needs of the user of the SaMS infrastructure 100. The DSS 104 also collects data from CARMA 102, and other sources, as described below. The DSS 104 allows Business Strategy Units (BSU) 116 to access data stored in its data warehouse. A BSU 116 can be a subset of a company responsible for formulating business, marketing, and sales strategies. For example, one BSU 116 can be responsible for international clients, while another BSU 116 can be responsible for domestic clients. Alternatively, the BSU 116 can be the entire company employing the SaMS infrastructure 100. Users or BSUs 116 access the data stored in the DSS 104 for various functions, including data survey, data mining, data drilling, predictive modeling, general queries and results delivery. The data survey function helps the BSU 116 to identify potentially valuable groups of data. The data survey function helps the BSU 116 find unanticipated patterns to guide marketing decisions. For example, a survey of a data mart (described below) may discover that 80% of a population in the northeast and with incomes of greater than $50,000 use cellular service. The BSU 116 can thereafter determine why income and geographic characteristics lead to cellular usage. The data surveying function helps identify and classify large segments of data. The data mining and data drilling functions qualify these large segments of data to further identify and quantify business opportunities. Once a significant pattern has been established, the pattern can be represented as a mathematical model that establishes the correlation between certain characteristics (e.g., income over $50,000, northeastern U.S. population, etc.) to other characteristics (e.g., cellular users). From these models, the BSU 116 can create mailing lists of candidates for a cellular direct mail campaign. The general query function allows the BSU 116 to perform simple queries of data in the data marts via a DSS user interface process. For example, the BSU 116 can query the data mart for the total sales in a given year. The results delivery function allows the DSS 104 to deliver data in numerous ways, such as formatted reports, three-dimensional graphics, etc. Each BSU 116 performs strategic queries of data in the data warehouse of the DSS 104, using certain analytical tools. From the results of these queries, the BSU 116 formulates marketing campaigns. The BSU 116 then uses CONI 106 to implement the selected marketing campaign. As described more fully below, the BSU 116 specifies to CONI 106 criteria to use in extracting lead data from the DSS 104. Lead data is used to identify client leads, which are clients to be targeted in the selected marketing campaign. A "lead" is typically a client who is a potential customer of the company. Each lead is identified by a corresponding, unique client identifier stored in the DSS 104. CONI 106 then generates leads or lead records by matching these client identifiers with a name, address, and/or telephone number obtained from CARMA 102 via an operational data collection/distribution process of DSS 104, described below with respect to in Figure 3. When CONI 106 generates lead records, it places these records in the CLR 108. The CLR 108 is a database, smaller than the data warehouse of the DSS 104, used to track leads and activities performed on leads. The CLR 108 stores both lead records and lead distribution records. Each lead record, stored in the CLR 108, includes fields for client identifier, telephone number, address identifier, and perhaps a field for previous contact. Figure 4 shows an exemplary, more detailed, lead record constructed under Informix, showing numerous, generally self-explanatory fields. The CLR 108 preferably stores only one lead record per client. The CLR 108 also stores lead distribution records. More than one lead distribution record can be associated with each lead record. Figure 5 shows an exemplary, more detailed, lead distribution record constructed under Informix, showing numerous, generally self-explanatory fields. Each lead distribution record includes fields for identifying certain TM/DM centers 118, a number of records descend to each center, dates, priority codes, etc. The lead records generated by CONI 106 and stored in the CLR 108 are distributed by CONI to one or more Telemarketing/Direct Mail Centers (TM/DM centers) 118. The TM/DM centers 118 include call centers from which telemarketing agents perform client contacts, sales, and services over the phone. Often, a TM/DM center 118 is located in each "sales city" in which marketing campaigns are conducted. However, the TM/DM centers 118 can conduct marketing campaigns outside of the cities in which they are located. The TM/DM centers 118 may also include centers from which direct mail campaigns are conducted. While the present invention is generally described below with respect to a telemarketing campaign performed at the TM/DM center 118, those skilled in the relevant art will readily recognize that the embodiment of the present invention is equally applicable to direct mail campaigns. Additionally, the present invention is equally applicable to other methods of contacting clients, either physically or electronically, such as via e-mail or Internet contact. Agents at the TM/DM center 118 use the lead records provided to them by CONI 106 to call or contact clients and perform sales and/or service functions. The agents input the results of these contacts to the TM/DM center 118, which forwards the results to CONI 106. CONI 106 provides information from these results back to both CARMA 102 and the DSS 104 as a data provider 110. For example, if a client is contacted to market to them long distance service, but the client indicates they prefer to switch their local phone service provider instead, an agent records this indication in a file at the TM DM center 118. A file of all clients who prefer to switch their local phone service provider is then fed, as a data provider 110, to CARMA 102 and the DSS 104. CARMA 102 uses this information to update the profile of each client included in the file to indicate this client is interested in switching their local service provider. This information is then fed from CARMA 102 to the DSS 104, in the form of a client identifier and an indicator that represents an interest in switching local service providers, which is stored therein. The DSS 104 can also receive information directly from the TM/DM center 118 (as a data provider), via CONI 106, indicating how many people in a particular city, for example, are interested in switching their local service provider. From this information, the BSU 116 can query the DSS 104 to determine if enough interest exists in a certain city to formulate a local service provider marketing campaign in the city. CONI 106 can then generate leads for the local service provider campaign. The above example represents one of many feedback loops within the SaMS infrastructure 100. When an agent at the TM/DM center 118 signs up a new customer or makes a sale, the agent inputs an order directly into a customer order entry system 120. The customer order entry system 120, in addition to recording and provisioning the order, provides update data to the DSS 104 to indicate the results of, or information surrounding, the order. For example, if the order is for long distance service, the customer order entry system 120 updates the DSS 104 to indicate this client now subscribes to long distance service. The order for long distance service is also provided to National LEC Interface System (NLIS) and Quick Primary Interexchange Carrier (PIC) systems 122. The NLIS and Quick PIC systems 122 provide the order to the client's Local Exchange Carrier (LEC) 124 so that the LEC can convert the client's PIC at the appropriate local Class 5 switch. The NLIS and Quick PIC systems 122 are described in detail in U.S. Patent Application entitled "System and Method for Real Time Exchange of Customer Data Between Telecommunications Companies," (attorney Docket No. 1643/00568; assignee Docket No. COS-96-069) and assigned to a common assignee of the present application. The architecture of the TM/DM centers 118, customer order entry system 120, and NLIS and Quick PIC systems 122 enable the processes of contacting a client, selling long distance service to that client, recording and provisioning the order for long distance service, and converting the client's PIC at the LEC 124 switch to all occur within only a few minutes. The NLIS and Quick PIC systems 122 also provide data to the DSS 104 for unsolicited PIC conversions. If customers of a long distance company switch to another company, their PIC conversions will be provided by the LEC 124 to the NLIS and Quick PIC systems 122. The NLIS and Quick PIC systems 122 provide files of these conversions to the DSS 104. The DSS 104 in turn stores them, and allows CONI 106 to extract all recent PIC conversions and generate leads for a customer win-back campaign. The SaMS infrastructure 100 consists of CARMA 102, the DSS 104, and CONI 106 as a core. The SaMS infrastructure 100 also uses and can include the CLR 108, TM/DM centers 118, customer order entry system 120, and NLIS and Quick PIC systems 122 to provide additional functionalities. The SaMS infrastructure 100 also allows the use of a BSU 116, providing to the BSU the ability to analyze massive amounts of data and formulate marketing campaigns that are automatically implemented via lead generation and provisioning to the TM/DM centers 118. The SaMS infrastructure 100 is described in greater detail in co-pending U.S. Patent Application entitled "Information Architecture For Strategic Marketing Systems," which is filed concurrently herewith and assigned to a common assignee of the present application. Referring to Figure 2, an exemplary internal architecture of CONI 106 is shown. CONI 106 provides a graphical user interface (GUI) 160 for users to interact with CONI in at least two ways: to construct lead marts and to perform queries or searches within such constructed lead marts. Considering first the query of lead marts, users such as a BSU 116 of the company, use the GUI to translate a marketing strategy into a marketing campaign. Examples of screens displayed by the GUI 160 to the BSU 116 are shown in Figures 7-26, described below. The BSUs 116 select options or input data via the screens shown in Figures 7-26 in conventional manner, such as using a mouse or keyboard of a computer. The BSU 116 first specifies criteria for targeting clients. For example, from a prior analysis performed on data in the data warehouse of the DSS 104, the BSU 116 may determine that people who have recently moved from California to Colorado, and have purchased a car in the past year, are likely to subscribe to cellular service and switch their long distance provider. As a result of this determination, the BSU 116 wishes to offer a long distance and cellular service package to these people under a telemarketing campaign. The BSU 116 uses the GUI 160 to input and specify that it wants to pull records of all clients who have (1) moved from California to Colorado, (2) have purchased a car in the past year, and (3) are not currently both long distance and cellular customers of the company. A campaign management process 162 receives the input data or criteria from the GUI 130 and translates such criteria into a lead qualification filter or file. For example, the campaign management process 162 builds a query from the input criteria using structured query language (SQL) statements. The building of a query is described below with respect to Figures 6, 11, and 15-21. A query to produce a list of lead records is generally described herein as a "marketing campaign," as described below. A lead qualification filter process 164 receives the constructed lead qualification filter from the campaign management process 162 and applies such filter to data in the data warehouse of the DSS 104 or in a lead mart 166 (discussed below) to extract a list of clients which meet the criteria specified by the lead qualification filter. The lead qualification filter process 164 employs the lead qualification filter to extract client records as "lead records" for a given marketing campaign, and stores such lead records together in a lead mart 166 (described below). In the previous example, the lead qualification filter may first extract a first lead list of all client identifiers for clients who have moved from California to Colorado, then from this first list extract a second lead list of all clients who have purchased a car in the past year. From this second list, the lead qualification filter then extracts a third, smaller lead list of all clients who are not currently both long distance and cellular customers of the company. The lead qualification filters may also extract other undesirable leads, such as clients who have requested to not be contacted ("suppressions") or clients whose age is greater than 100 (i.e., probably deceased). In general, queries and retrieval of selected data from databases, data marts, and data warehouses under the exemplary embodiment of the present invention are performed using known database querying and retrieval techniques, such as using SQL statements and open database connectivity (ODBC), as is known by those skilled in the relevant art. Thus, to avoid obscuring important aspects of the present invention, such details are generally omitted herein. The lead qualification filter process 164 also constructs lead marts 166 in which to store the data extracted from the DSS 104 based on certain lead qualification filters. "Lead marts" 166 are databases, smaller than the data warehouse, which contain subsets of data from the data warehouse. In general, the lead marts 166 are customized collections of data extracted from the DSS 104 for individual BSUs 116. As is described herein, the BSUs 116, in turn, query the lead marts to develop specific client lists for a given marketing campaign. Each lead mart 166 is typically a single-subject database used by individual groups of users, such as individual BSUs 116 in the company. Examples of such lead marts 166 for a long distance company, in a preferential order, can be a lead mart storing data of all customers of international alliances on partner programs (e.g., frequent flyer programs), a lead mart storing data of all customers who make frequent international calls to non-English-speaking countries, a lead mart with all customers who make frequent international calls to English-speaking countries, a lead mart of all previous customers who have recently switched to another long distance company, and a mass market lead mart of all customers of a particular service. These common lead marts 166 can be used to manage ongoing marketing campaigns. For example, a lead mart 166 of all previous customers who have recently switched to another long distance company would be very useful for managing an ongoing customer win-back campaign. The lead marts 166 may be embodied in a separate computer, such as a Sun Box, manufactured by Sun Microsystems, but do not need to be. In the exemplary embodiment, the lead qualification filter process 164 provides a preferential order or hierarchy of lead marts 166 so that a given client is not identified in more than one lead mart (and thus not contacted repeatedly under various marketing campaigns). For example, the lead mart 166 of customers of international alliances/partnerships has a higher ranking than the lead mart of customers who make international calls to English-speaking countries. The lead qualification filter process 164 can be setup to perform nominal or periodic processing. For example, the lead qualification filter process 164 can be created to perform repeated data extraction from the DSS 104 based on a previously created lead qualification filter. Thus, on a periodic basis (e.g., daily), the lead qualification filter process 164 periodically queries and extracts client records from the DSS 104 (via data warehouse shipping (described below)) that satisfy the lead qualification filter, and updates the corresponding lead mart 166. Thus, the lead marts 166 continuously have currently updated data stored therein. The user or BSU 116 also uses the GUI 160 to input data or lead inventory specifications for creating specific client lists for implementing a given marketing campaign. For example, the user may input data to the GUI 160 specifying how many lead records are to be formatted each day, to which TM DM centers 118 certain lead records should be distributed, etc. A lead inventory management process 167 receives such input data from the GUI 160 and uses the data to manage the extraction of and processing lead records from the lead marts 166. Thus, in a manner similar to that for the lead qualification filter process 164, the lead inventory management process 167 constructs a query based on data received from the GUI 160 and extracts lead records stored in one or more of the lead marts 166 based on a given marketing campaign to produce a "lead list" or list of lead records selected based on the given marketing campaign. The lead inventory management process 167 stores the resulting lead list and corresponding lead records in the CLR 108. While the lead list typically includes a list of lead records, each lead record includes not only the client identifier for a given lead, but also additional information regarding the client, such as a number of times, and associated dates, when the client was contacted, and a code number corresponding to a marketing campaign during which the client was contacted. Generally, leads or clients can be tracked within CONI 106 based on a marketing campaign code created when a marketing campaign is created. Furthermore, the lead inventory management process 167 stores lead distribution records for each marketing campaign. The lead distribution records identify which TM DM center 118 a given lead record is to be distributed (or has been distributed). More than one lead distribution record can be associated with one lead record, since a client under the lead record can be associated with more than one marketing campaign. The lead inventory management process 167 creates lead distribution records for the given marketing campaign which specifies how many lead records are to be formatted each day, to which TM/DM centers 118 certain lead records should be distributed, etc. The lead inventory management process also performs certain screening processes such as ensuring that duplicate client records are not retrieved and stored in the CLR 108. The lead inventory management process 107 ensures that a given client is not identified in two separate marketing campaigns (and thus is not called twice). The lead inventory management process 167 flags each client identified under a lead list in the CLR 108. If a subsequent lead list identifies a client already flagged in the CLR 108, the lead inventory management process 167 compares a hierarchy or rating of the new lead list to that of the former lead list which previously flagged the given client. If the subsequent lead list has a higher ranking than the prior lead list, then the client is flagged for the new lead list. Thereafter, the lead inventory management process, via a formatter (described below), cancels a lead record previously forwarded to the TM/DM center 118 under the prior lead list. Thus, the lead inventory management process 167 can dynamically adjust ongoing marketing campaigns so that more successful campaigns (higher priority campaigns) preside over and accumulate clients from other campaigns. In general, CONI 106 provides two types of data retrieval granularity to the BSUs 116. Under a coarse granularity, the BSU 116, through the GUI 160, campaign management process 162 and lead qualification filter process 164, extract a subset of client data from the DSS 104, and stores such data in a lead mart 166. In a finer granularity process, the BSU 116, through the GUI 160 and processes 162 and 164, develop a subset of client data stored in a lead mart 166 to produce lead lists and extract lead records for certain marketing campaigns. Summarizing, the campaign management process 162 creates lead qualification filters based on queries or criteria input by the BSU 116. The lead qualification filter process 164, in turn, implements such created lead qualification filters to extract the appropriate data from the DSS 104 (to construct lead marts 166) or from the lead marts (to construct lead lists). The campaign management process 162 provides an interface between the GUI 160 and the lead qualification filters process 164, while the lead qualification filters process interacts with the databases/data warehouses. A formatter process 168 receives client data that is extracted from the CLR 108 and DSS 104 based on a lead list for a given marketing campaign. The formatter process 168 matches the client identifier of each entry in the lead list with a name, address (if for a direct mail campaign), and telephone number (if for a telemarketing campaign) to create an appropriate lead record to be ultimately used to contact the client. The formatter process 168 obtains the name, address, and telephone number assignments for client identifiers from CARMA 102 via the DSS 104. As shown in Figure 3, the DSS 104 includes an operational data store (described below) that extracts this information from CARMA 102 and feeds it to CONI 106. The formatter process 168 formats the resulting leads into lead records, and lead distribution records that include an identification and address of specific TM/DM centers 118 to which each lead record is to be distributed; this information is provided by the lead inventory management process 167. The formatter process 168, in the exemplary embodiment, is table driven, and thus employs definition files, similar to templates. Such definition files specify the location of data retrieved by the formatter process 168 for display to agents at the TM/DM centers 118. For example, the definition file can specify that column 1 include phone numbers, column 2 include names, etc. By being table driven, the formatter process 168 does not require underlying code to be changed if a given lead record format is to be changed. Instead, only the definition file needs to be changed in order to change the way in which data extracted from the DSS 104 is displayed to agents at the TM/DM centers 118. The TM/DM centers 118 receive formatted lead records from the formatter process 168. Agents at the TM/DM centers 118 then contact clients identified in such records and record the results of such contacts. A contact management process 169 receives the results of the contacts from the TM/DM centers 118. In the exemplary embodiment, the results of such contact consist of, or include, certain predetermined codes. Such codes indicate whether a client is to be a suppression, whether the client is to be contacted again and at what time, and any changes to be made to the client's profile. Thus, the contact management process 169 arranges a follow-up with a lead if needed, updates stored data, etc. The contact management process 169 forwards the code and or information to the data warehouse of the DSS 104 for storage. The contact management process 169 thereby provides feedback on the results of the marketing campaign. The feedback provided by the contact management process 169 provides historical information to CONI 106. Such historical data can be accessed, via CONI 106, by the BSU 116 to determine how successful a given marketing campaign is. The BSU 116 can then modify a given marketing campaign to help improve its success, if needed. Figure 3 illustrates steps under a typical data flow for collecting and storing marketing data, and using that data to formulate and implement a marketing campaign, in the SaMS infrastructure 100. Process steps or data flow in Figure 3 is identified by reference numbers 1 through 24. Paragraphs below are introduced by a number, 1 through 24, which corresponds to the data flows shown in Figure 3. Where relevant, certain hardware or processes are also described with respect to the data flows 1 through 24. 1. Client information from the data providers 110 is collected by CARMA 102. As noted above, the client information from the data providers 110 can include internal data sources such as the company's customer traffic, billing system records, client contact records, etc., as well as external data such as syndicated lifestyle information. CARMA 102 is designed to accept data in practically any format and from any source. CARMA 102 uses input client information to update client profiles in its client database. 2. Any changes to client profiles in CARMA 102 (generally a result of new client information input by the data providers 110) are captured and fed to the DSS 104. Specific client identification data, such as names and addresses, are withheld. Instead, CARMA 102 provides generic client identifiers to the DSS 104. The DSS 104 uses a data harvesting process 170 to collect and format all input data, whether from CARMA 102 or any other data provider. The data harvesting process 170 includes processes for identifying, extracting, transforming, deriving, aggregating, integrating and conducting integrity checks of data collected from the data providers 110. The identifying process identifies what data elements within the collected data are needed for downstream processes, as well as identifying a definitive source for collected data, not necessarily the first known source. The extracting process copies appropriate data from the data providers 110. The transforming process reconciles the various ways that the same data is labeled as it is received from the data providers 110. For example, values for a client's sex under one data provider or system may be in the form of "m" or "f," while from another data provider be in the form of "1" or "2." The transforming process may instead assign a new value, such as "male" and "female." The deriving process converts some data into another value. For example, two or more fields of data about a client may be converted to a score (e.g., the address and income of a client combined and represented by a two-digit score). The aggregating process combines and summarizes data across a set of transactions or a set of individual clients. For example, the total monthly long-distance spending by a client may be aggregated over a year to provide an average monthly spending value for that client. The integration process matches data with the appropriate client number, and verifies time frames for each piece of data. The integrity check process ensures that data stored in the data warehouse is in the appropriate form/format. 3. The data harvesting process 170 collects from various data providers 110 information for which specific client identification is not needed. This information can be used to identify general trends. 4. The data harvesting process 170 stores all the data it collects in a data warehouse 172. The data warehouse 172 may be partitioned and configured in various schemes to suit the needs of the business utilizing it. For typical businesses, such as a telecommunications company, it must be capable of storing huge volumes of data, perhaps several Terabytes. The data warehouse 172 preferably employs a massive parallel processing (MPP) platform, such as more than 100 IBM SP2 processors. A scaleable database management system is preferably used, such as that offered by Informix Corporation. 5. and 6. A data shipping process 174 extracts specific data from the data warehouse 174 and places this data in data marts 175. The data marts 175 are smaller databases that house subsets of data from the data warehouse 174, and are used to facilitate quick and easy access to the data stored in the data warehouse. The data marts 175 each preferably employ symmetrically parallel processor (SMP). Each data mart 175 is setup for an individual customer or user of the DSS 104. For example, one data mart 175 can be established for a residential marketing BSU 116, and another data mart established for a small business group BSU 116. A user of the DSS 104, such as a BSU 116, specifies in the data shipping process 174 what data they wish to have placed in their data mart 175 from the data warehouse 172, and when. The BSU 116 specifies such criteria via a DSS user interface process 176 (described below). The data shipping process 174, on a periodic basis, then extracts data from the data warehouse 172 under the user's specified criteria, and places this data in the user's data mart 175. Summarizing, the data shipping process 174 moves data from the central data warehouse 172 to departmental data marts 175 in a process similar to the data harvesting process 170 (e.g., users can select requested elements and require additional transformations be applied to data before it is stored in the data marts). 7. and 8. The DSS user interface process 176 is a tool that provides access to and analysis of data in the data marts 175. Users, such as a BSU 116, use the DSS user interface process 176 to perform queries into the data in their data mart, under a query process similar to that described above for CONI 106. For example, the data shipping process 174 may extract from the data warehouse 172 data representing all clients who have recently moved to the United States from a foreign country, and place this data in one of the data marts 175 for the BSU 116. The BSU 116 then uses the DSS user interface process 176 to obtain a list, from this data, of all of these clients who moved to California from Japan, and have selected another long distance company. Generally, more complex methods of analysis are used to determine what types of marketing campaigns can be successful. The BSU 116 examines their data mart 175 to find significant patterns and relationships that can be translated into marketing strategies. Using the DSS user interface process 176, the BSU 116 formulates queries and performs the necessary analysis of data in their data marts 175 to develop marketing strategies and therefrom determine what sort of marketing campaigns to implement. Queries against data in the data warehouse 172 are made using SQL or other query language. The BSUs 116 preferably includes minicomputers or workstations, such as Sun Microsystems SC2000/SPARC20 system. Such microcomputers preferably operate under a UNIX operating system, and run a database management system such as that offered by Informix. The minicomputers (as well as other elements within the SaMS infrastructure 100) are coupled using high-bandwidth connections. For example, the minicomputers of the BSUs 116 are preferably coupled to the DSS 104 and CONI 106 using fiber-optic distributed data interface (FDDI) local-area network connections. The minicomputers preferably communicate to the infrastructure 100 using ODBC. The BSUs 116, in the exemplary embodiment, employ a World Wide Web browser to access hypertext markup language (HTML) applications on the DSS 104 and/or CONI 106. The HTML applications provide a menu of data views and other screens, under a GUI environment (to the BSU 116), as described herein. Thus, the BSUs 116 access portions of the SaMS Infrastructure 100 via an intranet, or via the Internet. 9. Once the BSU 116 has analyzed data and determined a marketing strategy, they use CONI 106 to implement that strategy as a marketing campaign that is targeted for a specific client segment. The campaign management process 162 and GUI 160 within CONI 106 provide the ability for the BSU 116 to state their marketing campaign as specific criteria. 10. Data input through the GUI 160 to the campaign management process 162 is converted by the campaign management process into lead qualification filters under the marketing campaign. The lead qualification filters are then input to the lead qualification filters process 164. The lead qualification filters process 164 is the interface between the data shipping process 174 of the DSS 104 and CONI 106. The lead qualification filters specify criteria that clients need to meet in order to be included in the marketing campaign. 11. The lead qualification filters process 164 extracts data from the data warehouse 172 based on criteria that represents the BSU 116's marketing campaign (under the lead qualification filter). Alternatively, the lead qualification filters process 164 applies the lead qualification filter to extract data stored in the lead marts 166. 12. Client records that meet all lead qualification filter criteria are placed in the lead marts 166 as related lead records. The lead marts 166 are CONI 106 data marts housing client records or lead records for particular marketing campaigns. From the lead records, formatted lead records will be generated (as discussed herein). There may be multiple lead marts 166, but only one record of a single client is preferably stored in one of them. 13. The lead inventory management process 164 creates a lead list based on the lead records selected by the lead qualification filter. Additionally, the lead inventory management process 164, under direction from data input from the BSU 116, creates lead distribution records that specify the number of lead records to make available for calling or mailing, specify which TM/DM centers 118 receive each lead record, specify whole numbers of lead records to assign to each TM/DM center, etc. The BSU 116 can use the lead inventory management process 164 to specify where leads are to be sent, based on agent skill sets, geography, resources available, etc., thereby allowing the TM/DM centers 118 to manage their resources better. The lead inventory management process 164 also ensures that each client is extracted only once from all of the lead marts 166, ensuring no client duplication in various lead lists. 14. The lead inventory management process 164 feeds the lead list and associated lead records and lead distribution record for storage in the CLR 108. The CLR 108 maintains lead records for each client throughout the marketing campaign, including previous contacts and results of contacts under the feedback data flows described herein. The lead inventory management process 167 tracks leads on clients that have recently been provided to a TM DM centers 118, to ensure frequent contacts are not made to the same client and updates lead records in the CLR 108 accordingly. For example, if a lead record on a specific client is passed to a first TM DM center 118 on one night, and another lead record on the same client is provided to CLR 108 from the lead inventory management process 167 the next night, the lead record in CLR 108 will either indicate on the second lead record that this is a second lead record for the same client in two nights, or an indication will not pass this lead to another TM/DM center 118. 15. The DSS data harvesting process 170 collects from CARMA 102 a feed of specific data associated with or assigned to client identifiers such as name, address, and telephone numbers. 16. This specific data is placed in an operational data store (ODS) 178. The ODS 178 is similar to the data warehouse 172, but is generally much smaller. A purpose of the ODS 178 is to store data temporarily, in order to distribute data to other processes or systems. 17. and 18. Upon request by the formatter process 168, the data shipping process 174 extracts from the ODS 178 the specific data, such as the name, address, and telephone number, assigned to the client identifiers in the lead records, and provides this data to the formatter process. The formatter process 168 uses this data to assign a name and telephone number, and possibly a mailing address, to each client identifier that was provided by the lead inventory management process 164, and create formatted lead records. 19. The formatter process 168 retrieves the lead records associated with the lead list from the CLR 108 and constructs formatted lead records using the client data provided by the data shipping process 174. Formatted lead records may include some or all of the following data: client names, telephone numbers, addresses, contact history, TM/DM centers 118 assignment, and other information pertinent to the marketing campaign. The formatter process 168 formats lead records by matching client identifiers, which are received by the lead inventory management process 164, with names and telephone numbers from CARMA 102. 20. The formatter 168 forwards the formatted lead records to the appropriate TM/DM centers 118 based on the lead distribution list. The TM/DM centers 118 import such lead records and contact the clients and conduct the marketing campaign, such as offering long distance services or products. 21. The results of each client contact are recorded locally at the TM/DM centers 118. 22. The results of each client contact are extracted by or forwarded to the contact management process 169 within CONI 106 from the TM/DM center 118. The contact management process 169 can arrange follow-up leads and report on status or results of a given campaign. The contact management process 169 may automatically update lead records stored within the CLR 108. 23. The contact management process 169 provides results of client contacts to the data harvesting process 170, so that the data warehouse 172 can be updated with these results. The data shipping process 174 then updates the corresponding data in the data marts 175. This represents another of many feedback loops built into the SaMS infrastructure 100. As noted above, the BSU 116 formulates and conducts a marketing campaign. The results of each client contact under the campaign are fed to the data warehouse 172. The BSU 116 can then extract and analyze the results of the overall campaign by specifying to the data shipping process 174 an extraction of certain client data. From this, the BSU 116 may formulate another campaign, modify an existing campaign, or identify an unexpected response to the previous campaign. For example, the BSU 116 may formulate a campaign to sell long distance service to a certain RBOC's customers. Many customers, when contacted by a TM/DM center, may respond with a preference to switch local service providers. These responses are recorded in the CLR 108, extracted by the contact management process 169, collected by the data harvesting process 170, and stored in the data warehouse 172. The BSU 116 then analyzes the results of their campaign via the DSS user interface process 176 and previously updated data marts, and determines that a local service marketing campaign to those same customers is needed. The TM/DM centers 118 can also perform direct mail campaigns. For example, CONI 106 can instruct the TM/DM center 118 to mail brochures to selected clients, wait two weeks, then call those clients. 24. The result of a client contact may be that the client requests to not be called again (a "suppression"). As noted above with respect to data flow 22, the contact management process 169 updates the lead records in the CLR 108 to indicate a suppression for the client. An extraction of all suppressions are then fed, as a Data Provider, to CARMA 102. CARMA 102 in turn will feed these suppressions, by client identifier only, to the data warehouse 172. The lead qualification filter process 164 can then filter out any clients with a suppression indicator in future campaigns. Suppressions can also be provided to CARMA 102 from External Data Sources 114, such as a LEC 124. The campaign management and lead inventory processes will now be described with respect to the exemplary flowchart of Figure 6. Figure 6 shows an overall process 200 performed by the campaign management process 162 and lead inventory management process 167. Associated with each step or subprocess in Figure 6 are exemplary screens displayed by the GUI 160 to the BSU 116. Such screens, shown in Figures 7-26, are preferably built using Microsoft Visual Basic. As described below, the screens shown in Figures 7-26 are referred to by the same reference numeral for the corresponding steps under the process 200. If multiple screens are associated with a given step, then the screens are represented by the reference numeral followed by letters A, B, C, In step 202, the process 200 displays a log in screen, as shown in Figure 7. The log in screen requests a user ID, and password for the user. In the exemplary embodiment, three levels of users are permitted access to the infrastructure 100. A highest priority user can access all aspects and processes of the infrastructure 100. A mid-level user can submit lead generation queries, create lead qualification filters, and perform many functions within the infrastructure 100. A low level user can simply view certain data. The following discussion assumes that the user has access to all processes described below. In step 204, after successful log in, the process 200 displays a main menu screen (Figure 8) which permits the user to select one of at least six subprocesses: viewing or modifying lead marts (step 206; Figure 10), viewing or generating leads (step 208; Figure 11), viewing records in the CLR 108 (step 210), viewing tables of data (step 212; Figure 12), performing security functions within CONI 106 (step 214; Figure 26), or creating reports (step 216). The main menu, step 204, also provides certain pull- down functions (in a Windows environment). For example, as shown in Figure 9, the main menu (step 204) can provide a generic table to view columns or rows of data within CONI 106 or other portions of the infrastructure 100. As shown in Figure 9, the user can determine the status of a particular lead, perform local and global queries of leads or records within one or more databases within the infrastructure 100, determine a distribution status of records, display tables of steps necessary to create lead qualification filters, generate reports, count the number of records in a lead mart, determine the status of records in a lead mart, etc. Based on a first selection from the main menu screen (Figure 8), the process 200 in step 206 displays an initial lead mart screen, as shown in Figure 10. Under the lead mart screen of Figure 10, the user can open an existing table previously build to create a lead mart, or create a new record for storage in the lead mart. Figures 27A and 27B together show an exemplary mart table used to create a lead mart under Informix, and fields in the table are generally self-explanatory. In step 218, the user can select one of two tabs for options to manage properties of the lead marts, as shown in the screens of Figures 13 and 14. Referring to Figure 13, a first screen 218 A allows the user to view a summary list of all of the lead marts being built. Referring to Figure 14, a screen 218B displays tables of the lead marts and allows the user to create a hierarchy among such lead marts by promoting or demoting the marts with respect to each other. In step 208, the process 200 displays a corresponding screen that permits the user to input a query or profile to be used in creating a lead qualification filter under a marketing campaign. In step 220, the process 200 displays a screen 220N shown in Figure 15, that allows the user to input distribution criteria, used to create a lead distribution list. As shown in Figure 16, the step 220 also displays a screen 220B that allows the various sale cities or TM/DM centers 118 to be displayed with corresponding data. In step 222, the process 200 displays a corresponding screen shown in Figure 17 that permits the user to save a constructed query, submit the query to the lead qualification filter process 164 to pull corresponding records, and a frequency of refresh of such records. In step 224, the process 200 allows the user to display or obtain reports on various marketing campaigns. Referring to Figure 18, a screen 224A allows the user to display lead records pulled for a given marketing campaign. Referring to Figure 19, a screen 224B displays a total number of lead records (rows), records which failed the lead qualification filter, duplicates that pass the filter, but are already located in the CLR 108 (under another campaign) and those which passed under the filter/campaign. Referring to Figure 20, a screen 224C displays distribution information to the user based on his or her submitted query. Referring to Figure 21, a screen 224D displays errors in pulling lead records under the query. In step 212, the process 200 displays a corresponding screen, shown in Figure 12, that provides four options for displaying tables of data to the user: sales city/media/forms table, distribution default table, list code hierarchy table and miscellaneous table. Referring to Figure 22, a screen 226A displays or allows the user to create a record for a new sales city. Referring to Figure 23, a screen 226B allows the user to select one of several forms for displaying lead records to the sale city (TM/DM center 118). Referring to Figure 24, a screen 226C allows the user to specify the type of media on which lead records are distributed to the sale cities (e.g., disk TRANS, tape, etc.). In step 228, the process 200 permits the user to select one of several distribution formats under previously constructed lead distribution records. In step 230, the process 200 displays a corresponding screen, shown in Figure 25, that lists codes corresponding to the hierarchy of marts and their corresponding lead records. In step 232, the process 200 displays any additional tables of information for user selection by the user. In step 214, the process 200 displays a corresponding screen, shown in Figure 26, of security options provided under CONI 106. Access to various portions of CONI 106 and its processes can be limited to levels of users. Although specific embodiments of, and examples for, the present invention are described herein for illustrative purposes, various equivalent modifications can be made without departing from the spirit and scope of the invention, as will be recognized by those skilled in the relevant art. The teachings provided herein of the present invention can be applied to other businesses and marketing campaigns, not necessary the exemplary telecommunications service provider and telemarketing campaign described above. For example, the present invention is equally applicable to implementing marketing campaigns for other market segments, and contacting clients developed under such campaigns via the Internet. Moreover, aspects of the present invention can be employed to generate organized reports based on complex and voluminous data stored in a data warehouse. All U.S. patents and applications cited herein are incorporated by reference. Those skilled in the relevant art can create source code for the software, processes and functions described herein based on the above-detailed description of the data flows, functions and processes of the SaMS Infrastructure and its related components. While certain operations under the present invention are described as occurring generally in a serial fashion, those skilled in the relevant art will recognize that it is entirely within the scope of the invention to conduct some operations more or less simultaneously, or even in alternate order, from that described herein. These and other changes can be made to the invention in light of the above detailed description. In general, in the following claims, the terms used should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims, but should be construed to include any data processing system that operates under the claims to provide information management, contact services and client management functions. Accordingly, the invention is not limited by the disclosure, but instead its scope is to be determined entirely by the following claims.

Claims: CLAIMS 1. A computer implemented method of generating leads for a marketing campaign from client records stored in a data warehouse, the method comprising the steps of: creating a mart containing a subset of the client records stored in the data warehouse; selecting a subset of the client records contained in the mart based on a first query; and constructing lead records based on the selected subset of the client records and additional information stored in the data warehouse. 2. The method of claim 1 wherein the step of creating includes the step of creating a filter that determines which client records in the data warehouse are contained as the subset in the mart. 3. The method of claim 1 wherein the step of selecting includes the step of creating a lead qualification filter that determines which client records in the subset of the mart are selected. 4. The method of claim 1 wherein the step of constructing includes the step of retrieving certain data in the client records in the data warehouse based on a client number. 5. The method of claim 1 wherein the step of constructing includes the step of formatting the lead records for display on a computer screen. 6. A system for generating lead records for a marketing campaign based on client records stored in a database, the system comprising: a user interface unit configured to accept query commands from a user; a campaign management unit coupled to receive the query commands and create a lead qualification filter; a lead qualification filter unit coupled to the database and coupled to receive the lead qualification filter, wherein the lead qualification filter unit is configured to apply the lead qualification filter to the client data to extract selected client records; a lead management unit coupled to receive the selected client records, wherein the lead management unit is configured to apply predetermined rules to the selected client records to produce a set of lead records; and a formatter unit coupled to receive the set of lead records, wherein the formatter unit is configured to convert the lead records into formatted lead records for use in the marketing campaign. 7. The system of claim 6, further comprising a lead data mart coupled to the lead qualification filter unit and the lead management unit, wherein the user interface unit is configured to accept a profile, and wherein the lead qualification filer unit is configured select client records in the database for storage the lead data mart based on the profile. 8. The system of claim 6, further comprising a lead data mart coupled to the lead qualification filter unit and the lead management unit, and wherein the lead qualification filer unit is configured extract the selected client records in the lead data mart based on the lead qualification filter. 9. The system of claim 6, further comprising a contact management unit coupled to the database and coupled to receive client data for one of the formatted lead records corresponding to one of the selected client records, wherein the contact management unit is configured request the database to alter the one client record based on the received client data. 10. The system of claim 6, further comprising a centralized lead data repository that stores the set of lead records and a lead data mart coupled to the repository and coupled to receive client data for one of the formatted lead records corresponding to one of the set of lead records, wherein the contact management unit is configured alter the one lead record based on the received client data. 11. The system of claim 6 wherein the formatter unit is coupled to the database and receives data from the database corresponding to each lead record in the set of lead records to produce the formatted lead records. 12 The system of claim 6 wherein the user interface unit is configured to receive commands from the user via the Internet. 13. A computer-readable medium holding computer-executable instructions for performing a method comprising the computer-implemented steps of: creating a mart containing a subset of client records stored in a data warehouse; selecting a subset of the client records contained in the mart based on a first query; and constructing lead records based on the selected subset of the client records and additional information stored in the data warehouse. 14. The computer readable medium of claim 13 wherein the step of creating includes the step of creating a filter that determines which client records in the data warehouse are contained as the subset in the mart. 15. The computer readable medium of claim 13 wherein the step of selecting includes the step of creating a lead qualification filter that determines which client records in the subset of the mart are selected. 16. The computer readable medium of claim 13 wherein the step of constructing includes the step of retrieving certain data in the client records in the data warehouse based on a client number. 17. The computer readable medium of claim 13 wherein the step of constructing includes the step of formatting the lead records for display on a computer screen. 18. In a computer system having a database holding client records that hold information regarding clients for marketing contact, a method comprising the computer- implemented steps of: creating a subset of lead records from the database of client records, wherein each lead record in the subset contains less data than a corresponding client record in the database; selecting a plurality of lead records from the subset; retrieving additional information from the database based on the selected plurality of lead records; and creating formatted records for marketing contact from the additional information and the selected plurality of lead records. 19. The method of claim 18, further comprising the step of forwarding the formatted records to a marketing terminal for display thereon.

Inventors: BINGHAM DAVID WAYNE, DE LOLLIS ANTHONY J, GOLDBERG VICTOR ALAN, KRUEGER ALVIN HERMAN, LIPSCOMB GEORGE MICHAEL, PIEPER BRUCE ROGER, ROOT RANDAL WILLIAM, BINGHAM, DAVID, WAYNE, DE LOLLIS, ANTHONY, J., GOLDBERG, VICTOR, ALAN, KRUEGER, ALVIN, HERMAN, LIPSCOMB, GEORGE, MICHAEL, PIEPER, BRUCE, ROGER, ROOT, RANDAL, WILLIAM
Applicants: MCI COMMUNICATIONS CORP, MCI COMMUNICATIONS CORPORATION
Application year: 1998
Main classification: G06F17
IPC codes: G06F17, G06Q10, G06Q30