Note: Descriptions are shown in the official language in which they were submitted.
CA 02287159 1999-10-21
WO 98/49641 PCT/US98/06721
1
SYSTEM AND METHOD FOR AUTOMATED LEAD
GENERATION AND CLIENT CONTACT MANAGEMENT
FOR A SALES AND MARKETING PLATFORM
TECHNICAL FIELD
S 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 efI'lciently.
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
' andlor 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
CA 02287159 1999-10-21
WO 98/49641 PCT/US98/06721
2
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.
S 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
I 5 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 I 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.
CA 02287159 1999-10-21
WO 98/49641 PCT/US98/06721
3
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 S 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.
CA 02287159 1999-10-21
WO 98/49b41 PCT/US98/06721
4
Figure 25 is a front view of a computer screen showing an exemplary Iist
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
1 S 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
.... ,. r,...... ..,...... . . , ,_... t_ ...... .....w. .. .. .... .. , . . .
.
CA 02287159 1999-10-21
WO 98/49641 PCTIUS98106721
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
computers) that
5 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
Refernng 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
CA 02287159 1999-10-21
WO 98149641 PCT/US98/06721
6
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
CA 02287159 1999-10-21
WO 98149641 PCT/US98/06721
7
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
IO 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 I 12 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
CA 02287159 1999-10-21
WO 98/49641 PCT/US98/06721
8
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
S 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 I 16 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 fiznctions qualify these large
segments of data to
CA 02287159 1999-10-21
WO 98/49641 PCT/US98106721
9
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.~, 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. CON/ 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
CA 02287159 1999-10-21
WO 98/49641 PCT/US98106721
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 TMIDM centers
118, a
number of records descend to each center, dates, priority codes, etc.
5 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.
10 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
1 S 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 CO1VI 106. CO1VI 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
. ,
CA 02287159 1999-10-21
WO 98/49641 PCT/US98/06721
11
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.
CA 02287159 1999-10-21
WO 98/49641 PCT/US98/06721
12
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 I04 in turn stores them, and allows
COIVI
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 TMIDM 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. CO1VI 106 provides a graphical user interface (GUI) 160 for users to
interact
with COIVI 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
CA 02287159 1999-10-21
WO 98/49641 PCT/US98/06721
13
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 GUl 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
CA 02287159 1999-10-21
WO 98/49641 PCT/US98106721
14
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
S 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
ailiances/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 i64
can be
.. ~ , r..
CA 02287159 1999-10-21
WO 98/49641 PCT/US98/a6721
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
5 qualification filter, and updates the corresponding lead mart I66. 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
10 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 I64, the lead
inventory
15 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
COIVI 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
CA 02287159 1999-10-21
WO 98/49641 PCT/US98/06721
16
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 1 I8
1 S 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, CON/ 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.
,.r
CA 02287159 1999-10-21
WO 98149641 PCT/US98/06721
17
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 CO1VI 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 I 18 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
CA 02287159 1999-10-21
WO 98/49641 PCT/ITS98/06721
18
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 COrII 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
1 S 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 ali 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
,.
CA 02287159 1999-10-21
WO 98!49641 PCT/US98/06721
19
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 "I" 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.
1 S 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 I75. 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. Far
example, one
CA 02287159 1999-10-21
WO 98/49641 PCT/US98/06721
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
5 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
10 similar to the data harvesting process i 70 (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
15 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
20 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
. ,
CA 02287159 1999-10-21
WO 98/49641 PCT/US98106721
21
operate under a U1VIX 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 CO1VI
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 CONT 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
1 S 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.
CA 02287159 1999-10-21
WO 98149641 PCTNS98/06721
22
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 l I8 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 I 18, 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 I 18
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.
I5. 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.
wT. ~_ , , t
CA 02287159 1999-10-21
WO 98149641 PCTIUS98146721
23
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
1 S 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 COlVI 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.
CA 02287159 1999-10-21
WO 98/49641 PCT/C1S98/06721
24
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.
.. , ,
CA 02287159 1999-10-21
WO 98149641 PCT/US98/06721
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
5 Figure 6 are exemplary screens displayed by the GUT 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
10 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
15 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
20 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 COlVI 106 (step 214;
Figure 26),
or creating reports (step 216). The main menu, step 204, also provides certain
pull-
25 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
CA 02287159 1999-10-21
WO 98/49641 PCT/US98I06721
26
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 218A 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 220A,
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. Refernng 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
T ... , , T
CA 02287159 1999-10-21
WO 98/49641 PCT/US98/06721
27
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
S citylmedia/forms table, distribution default table, list code hierarchy
table and
miscellaneous table. Referring to Figure 22, a screen 226A displays of allows
the user to
create a record for a new sales city. Refernng to Figure 23, a screen 2268
allows the
user to select one of several forms for displaying lead records to the sale
city (TMIDM
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.
CA 02287159 1999-10-21
WO 98/49641 PCT/US98106721
28
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 Sa.MS 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.
f... ..~ , , ,
