HK1125476A - Sales process support system and method - Google Patents

Description

Sales processing support system and method

The present application is a divisional application of the chinese invention patent application having an application date of 1996, 10/17/10/78, an application number of 96199069.4, and an invention name of "sales processing support system and method".

The present invention relates generally to sales and service support systems and methods, and more particularly to electronic sales and service support systems and methods for specifying customer services and identifying sales targets, assigning sales leads, enhancing sales tools, and tracking sales performance and sales personnel.

To improve competitiveness, financial institutions have begun to adopt sales and service technologies that have succeeded in other fields, just like other service providers. However, market finance services have unique challenges. First, most people do not purchase financial services. However, something in the life of a customer causes the customer to make or face changes. In life, there are situations when inertia is overcome by, for example, migration, death, family formation, or opportunities arise when customers become bored enough to make changes. For this reason, a large pervasive market for financial services is often ineffective. Rather, the market for financial services must be oriented toward customers who tend to make changes or open other accounts. In the past, it has been very difficult, if not impossible, to accurately identify those customers who opened changes and predict when these events occurred. Thus, there is a need for a better system and method for predicting when a customer or potential customer will open an account change.

In order to anticipate customer needs and support targeted sales, a service provider must know its customers. Knowing one's customers is very important for improved customer service, another proven way to obtain and maintain new customers. The customer base spectrum of large financial institutions presents an obstacle to certain sales attempts because it becomes very difficult to learn about a single customer as the number of customers increases and the frequency with which each customer contacts a particular employee decreases. In today's financial community, a large financial institution may have tens of millions of households or customers, each of which has a unique set of accounts. The data for these homes, customers and accounts is so cumbersome that it has not been fully utilized for market expansion to date.

In an effort to run large customer databases, stores traditionally maintain customer records. In some cases, these records are all recorded in simple paper form, but recently electronic records have become popular. Initially, a separate data store was used for each electronic record keeping application. Thus, for example, each department in a financial institution has a program that creates and maintains the required records for its own purposes. A problem with this approach is that the information must be widely repeated. For example, the customer name and address may appear in separate files in several separate departments.

There is also a problem with applying dedicated data storage. Since the client's information goes into more than one file, any change in state is often entered into each file by a different person. The accuracy and consistency of the data will deteriorate over time. In addition, the use of dedicated data storage requires more data entries and more storage space.

Much work has been done on overcoming this problem with respect to the database concepts introduced more than two decades ago. In one database, data is stored in the central portion so that duplication of data does not occur. A database manager is used to manage the database. Examples of database management programs currently available include DB2 (for large databases) and dBase (for personal computers).

Typically, a database management system (DBMS) is used to manage the creation, storage, access, modification, deletion, and use of databases. Typical DBMSs build databases and their structures; providing means for control and data management in a database; providing means for users and applications to access, enter, modify and process data in the database; providing a reporter handler; providing a "special" query tool; providing user status reports to managers accessing the database and to activities performed; providing reports of hardware usage, current and other monitoring data to an operator; and to provide an automatic backup and restore procedure for data in the database.

There are many additional requirements for multi-user databases. This includes maintaining system performance, controlling parallel access to data, maintaining privacy, and managing databases as the number of users increases.

There are four database models: (1) hierarchical, (2) network, (3) relational, (4) target-oriented. The hierarchical and network models use files for storing data. The data relationships in the hierarchical database follow a hierarchical structure, or tree, that reflects one-to-one or one-to-many relationships in record types. The data relationships in the network database follow many-to-many relationships in the records. The data relationships must be defined when building a hierarchical or network database. Relational databases use a plurality of tables for storing data. The data relationships may be dynamically determined by the user and need not be defined at the time of building the database. Relational databases use a database query language to access and process data in the database for users. The example queries and the composed query languages are two database query languages. The target oriented database stores the data along with the processes in the target.

A relational database consists of a number of tables in which data is stored. A table in a relational database must have a plurality of unique rows and each cell or segment must contain only item information such as name, address or identification number. A relational database management system (RDBMS) allows data to be easily created, maintained, processed, and extracted from relational databases.

In the most sophisticated databases, the data is extracted by querying the database. The query language allows the user to set specific records based on the obtained data. Known query languages include specific programming languages, structured query languages, natural languages, and paradigm queries. When using a query language, the user typically specifies the principles followed by the program to select the records to be extracted. These principles are used as criteria for judgment. Only those records that match the established criteria are extracted.

In a relational database, the data relationships are not predefined. The user queries the relational database and spontaneously establishes data relationships by entering common fields. Database query languages are used as an interface between users and relational database management systems.

Two basic query forms are used in relational databases: (1) an example query, and (2) a structured query language. In an example query, the database management system displays the field information and the status of the query that the user entered into the desired field.

Structured Query Language (SQL) is a standard database query language used by relational databases. SQL is not a separate stand-alone software program, but is part of the DBMS. SQL allows users to build and run sets of related information stored in multiple tables. The core of SQL is flexibility in querying databases.

This flexibility is made possible by the way the data is stored in the relational database. The data is stored in a table having specific properties. These characteristics include: (1) one or more named fields, (2) the data in each column is of the same data type, (3) zero or more rows (zero rows occur when the table has been defined but no data has entered), (4) each row is unique, (5) a single data value is contained in the intersection of any field and row, and (6) the order of the fields and rows is irrelevant.

There are two basic forms of extracting data from a database: collective and recordable. Each of which has its own advantages and disadvantages.

The aggregated database allows the user to focus on the characters of the data rather than the tangible structure of the data. The user works with data in groups or sets or multiple tables rather than as single table data. The DBMS using SQL, such as an indicator of SQL server (Oracle) and SQL schema are assembled.

The record database accesses data based on the actual structure and index of the data. The record pointer allows the user to manipulate one record at a time through one table. It can easily access the rows or records in the table. However, it is a disadvantage that developers of database management systems must write programming code to cycle through each desired record. Examples of DBMS using the record-type method as such are dBASE and Clipper (slicer).

In SQL, privacy is maintained by granting permissions. Rights may be granted to the entire database, to a table, or to certain commands. A database operator may access the entire database to enable it to be properly saved, while a user typically needs to access a particular table or a portion of a particular table. For example, a person may have access to a personal list but not to a salary field in that list.

Attempts to build and use customer databases have various limitations. In general, there are two types of such restrictions: limitations in the source and nature of data input to the database and limitations in the ability of a person to search and retrieve data from the database. In some cases, these limits operate in opposition to each other. For example, as one improves the size and characteristics of a database, it becomes more difficult to search and extract data from the database.

In recent years, financial institutions such as banks have used targeted markets (particularly direct mail order and long-distance markets) to market a wide range of financial products and to serve existing and new customers. To facilitate these efforts, banks have used traditional databases containing, for example, customer lists and mailing lists. However, these traditional targeted market sources do not have the full advantage of being information compatible with fully servicing financial institutions.

A full-service financial institution typically provides customers with a wide variety of financial products including traditional deposits, investments, loans, mortgage accounts, and a variety of financial services including credit cards, man-in-the-middle transactions, direct access, business access, cash checks, telephone account delivery, and insurance checks. In addition, financial institutions now typically provide access to financial services via a variety of means including Automated Teller Machines (ATMs), Customer Activation Terminals (CAT), screen phones, bank-specific personal computers, personal digital assistants, voice response systems and smart cards, as well as traditional bank tellers. Information from these various sources provides exceptionally complex graphs for customer financial behavior and needs. Therefore, storing and retrieving this large amount of data in a meaningful way has great commercial potential. Even without considering the commercial potential, there is a need for systems and methods for building a comprehensive database from these various sources and extracting information from a central database in a meaningful and practical manner.

There are a number of deficiencies with existing systems and methods for building customer financial data and extracting information in marketplace and customer service systems. First, most users (e.g., bank employees) never learn how to use complex query languages. The proficiency of language requires special training and skill. In addition, developers write customer applications that are used by users who have only a slight knowledge of the program. Thus, the ability of a customer to use a database is often limited by the customer's application written by someone for his application. In this way, large-scale database systems are available that typically do not have the flexibility to allow users, i.e., those familiar with the market, to employ their own knowledge and experience to select criteria for extracting data from the database for the target market. Instead, the user must rely on a set of predefined queries that may or may not provide the desired results. As a result, sales activities can typically only target new or existing customer groups that can be easily determined, such as all new customers or all existing customers with some kind of account. Because there is no efficient way to quickly generate and distribute a sales lead list for a particular group of people most likely to subscribe to new financial services offered, customers who are most likely to need or want additional products offered by a financial institution are not always targeted for the sales activity. This results in a reduction in the success rate of the factory sales activity.

In addition, accessing the entire relationship of the customer using a financial institution or sophisticated demographic information about the customer (i.e., the customer's "profile") does not present the customer in a market change. Thus, with all of the knowledge of the customer's background and financial efforts, it is difficult to intelligently address the target customer for direct mailing and for distant market traders. Basic information about existing customers is not often available or the response time required to archive existing customers is too long. Both of these problems result in a very poor reading and not optimal sales behavior for the customer.

In addition, the sales activities of banking departments, department managers, and other persons responsible for marketing activities are not efficiently analyzed and tracked. A complete display of sales activity is typically only available after the sales campaign is completed and the results of the campaign are manually collected and analyzed. This usually requires a series of paper-based forms and a special system that is generated by relatively slow feedback to the sales personnel. Therefore, there is also a need for a system for providing up-to-date online review reports related to each product and sales service by each department, as well as behavioral display of individual sales personnel.

In short, there is also a need for an improved integrated system for identifying sales goals, distributing sales leads, enhancing sales tools, and tracking large sales campaigns and individual salespersons' performance activities as well as financial institution profits to maximize customer satisfaction.

It is an object of the present invention to provide an electronic sales and services support system that can provide improved identification of sales targets using a centrally controlled database and that acts as a tool for improving customer service and established relationships. In particular, the present invention, as a system, allows a bank to predict and utilize the precious moments when inertia is overcome and also allows the bank to establish or enforce relationships with existing customers and new customers when the customer opens an account to change banks or open new accounts.

The system of the present invention is also used to improve customer service and reduce customer losses by enforcing the relationship between the bank and the customer. In particular, research has shown that as the customer's relationship with the bank expands, the customer balance increases, and therefore the customer's interest in relation to the bank also increases. Furthermore, the more closely a customer is in relationship with a bank, the more difficult it is to change banks. The present invention provides a tool for establishing long-term and broad relationships with customers by allowing those responsible for the market to access and discuss the full range of financial services currently in use for the customer and only targeting the best customer base for each market activity conducted.

It is another object of the present invention to provide a system and method for standardizing and familiarizing information from internal and external sources to a financial institution centrally controlled database to support marketing activities.

It is a further object of the present invention to provide a system for building and extracting information from a centrally controlled database containing large amounts of financial and demographic data to support marketing activities.

It is yet another object of the present invention to provide a system that can quickly generate and distribute sales lead lists to sales personnel.

It is a further object of the present invention to provide a system that provides a dynamic presentation of a customer's financial and demographic profiles to the marketer during a marketing transaction.

It is a further object of the present invention to provide an online performance tracking system for tracking the performance of sales activities and individual salespeople.

Additional objects, advantages and novel features of the invention will be set forth in the description which follows and will become apparent to those skilled in the art upon reading and practicing the invention. The objects and advantages of the invention are realized and attained by the means of the appended claims.

The present invention accomplishes the above-mentioned objects by providing a system and method for building a comprehensive database from various sources and extracting information from a central database in a meaningful and practical manner. The system and method of the present invention is primarily, though not exclusively, intended to support large-scale sales activities, particularly for large financial institutions.

The system and method of the present invention preferably includes a central database, one or more micro-marketing centers having a plurality of user workstations, a central customer information system ("CCIS") having a plurality of departmental workstations, and an account opening system ("AOS"). These components are linked to each other by long-range communications or other means, thereby enabling the micro-marketing center, CCIS and account opening system to communicate with a central database. The central customer information system ("CCIS") preferably includes a relationship profile section, an account management section, a thread management system, or a sales tracking and reporting (management information system or "MIS") section.

Broadly speaking, the system of the present invention links various departments of a large commercial bank, particularly a large central database to a user workstation to allow a user to query the database. According to one aspect of the present invention, a graphical interface is provided to allow users who are not familiar with structured query languages to still obtain information from the database. The database is also connected to a Central Customer Information System (CCIS). The present invention ties all of these components together and provides a systematic way to target customers and track the effects of customer demand.

Using the system of the present invention, a department can determine a business and coordinate the business with a local micro business center. The system of the present invention can target multiple customers and generate multiple tables.

According to an important aspect of the present invention, the system of the present invention is directly connected to the online department system. In this manner, the cues loaded preferably by the micro-marketing center are automatically communicated to the departments. Local micro-marketing centers are particularly important to the system and process of the present invention. In particular, the present invention provides a micro-marketing center capable of generating a plurality of tables for identifying various mail order addresses and providing links to an online CCIS department system. This gives the local micro-marketing center all the capabilities available at the resolution workstation. However, the micro-marketing center may hide various addresses, such as stores or legitimate addresses. The cues generated using this method may be automatically loaded onto a system the evening before to provide the cues directly to the institutions.

With respect to the local micro-marketing center, the system of the present invention includes a graphical user interface that allows the local micro-marketing center to generate tables identifying various mail order addresses and connections to the online CCIS department system. This allows the primary sales center to directly provide leads to specific business activities. In general, the process flow may be described as follows. Initially, a department user (bank administration) decides to promote a sale. The concept of promotion is communicated to the local micro-marketing center. The system allows the local sales center to generate the lead using the user workstation. Generally, one request can be executed for 5 minutes to 24 hours depending on the type and size of the request. The cues are automatically loaded into the system for providing the cues to departmental users and private bankers during the night of the previous day. The banker may then use the lead and the relationship established with the sales payment request.

The central customer information system ("CCIS") preferably includes a relationship profile section, an account management section, a thread management system, or sales tracking and reporting (management information system or "MIS") section. Each section can generate a report that is provided to the department for a complete sales process.

The electronic sales and support system is preferably capable of interfacing with the system for opening a single account including a full range of financial components. The integrated system of the present invention therefore preferably includes a system for opening an account, preferably in a single transaction. The system preferably communicates with the central database, micro-marketing center, central customer information system and departmental systems of the present invention to enable data to pass between these legitimate and appropriate systems.

The central database forms the basis for all applications of the present invention, such that the central database information (and in some cases, the central database is provided with information) can be accessed using the micro-marketing center, CCIS and account opening system. The central database of the present invention is a comprehensive and rich database that contains information about all customers and products in a financial institution, including department products, bank cards, travel and banquet cards, student loans, investments, insurance and mortgage products, and the like.

The central database is designed to ensure the accuracy of the information and to make it easy for non-skilled personnel to use. Thus, the system includes means for cleansing and standardizing the upcoming information, housekeeping, profiling processes, computing state codes holding multiple tables and computing policy flags. Most of the fields in the central database are preferably modified monthly with information obtained at the end of the month.

In a preferred embodiment, a central database stores information from stores and markets within the financial institution at one location. The central database may include information relating to existing customer financial information, externally sourced information, and demographic information about existing and potential customers. In the preferred embodiment, the central database is hosted and includes a financial and demographic data repository. Information is fed into the database from a variety of sources including stores and credit cards provided by the financial institution and for each product and service offered by the institution and external vending machine feeds. The external delivery point feeds preferably include all publicly available demographic information, telephone numbers, addresses, taxes, and appropriate records, etc.

Data from these sources is stored in a unified format. For this purpose, a unified memory or home algorithm, name and address normalization process, and merging process may be used. In addition, information is preferably maintained in the central database in a three-tiered hierarchy so that it can be selectively accessed at the home, customer, and account levels. A given household may have one or more customers, and each customer in the household may have a number of different accounts.

Thus, the central database acts as a single central repository for storing customer-related information throughout the store. As will be described later, the central database may be used for a wide variety of customer service, financial analysis, and marketing purposes.

While a single central repository for storing all customer-related information throughout the store provides the effective possibility, the database needs to be large enough to identify problems that arise. For example, the inventors have recognized that databases of this size are virtually impossible to use for direct retrieval. Thus, according to another aspect of the invention, the system of the invention includes a means for allowing a user to dynamically create a plurality of programs to retrieve the central database.

The inventive micro-marketing center workstation comprises a device, preferably designed in the form of software, for operating a general-purpose computer for generating a program for operating a Windows system^TMPC or Macintosh^TMA graphical user interface ("GUI") of a computer. Still preferably, said means running a general purpose computer in software provide a local copy of all tables and are constituted on the basis of a central database used by said workstation. This ensures that all users have the latest definitions and fields.

In addition, the system includes a means for the user to walk through each step of searching the central database by using drop-down windows, icons, drag-and-drop, and other features familiar to the user. The system also includes a means for building an "appropriate" SQL query for each request, and hiding the specialized code and required syntax to ensure that the queries are run. Finally, the system also includes a means for downloading reports and files to a local printer or storage device.

In other aspects, the workstation of the micro-marketing center also has the ability to retrieve information contained in the central database and generate a list of leads (i.e., sales targets) for the sales activity. The micro-sales workstation allows a user to create a query, specify or design a report, run the process, i.e., run the query, run the results of the query into a report, and then download or output the report.

The micro-marketing workstation also allows users to generate marketing information or cues and provide these cues directly to the CCIS. A plurality of micro-marketing workstations may be used within the micro-marketing center to respond to requests from department managers for lead lists of selected sales solutions (i.e., sales activities related to new or existing products or services offered by the financial institution). The micro-marketing center is hosted by a department manager to determine a profile of a home, customer, or account that is most likely to purchase a product or service. The micro-marketing center then forms a specific query, runs the query against the central database, and generates a report containing the best lead list to perform the sales campaign.

A workstation located at the micro-marketing center can retrieve the central database and retrieve all home, customer or account tables that meet specific selection criteria. The thread list is used to target families, customers meeting specific selection criteria in a sales campaign by direct mailing or to be directly passed to the CCIS for telephone marketing.

The CCIS of the present invention is a marketing, management and sales tool. It includes a series of integral components for viewing customer information and managing customer connections and relationships. Relationship management becomes a support for integrated sales processing. The system provides the feature of a relationship profile that allows the appropriate staff to view family and customer account and balance information in a detailed and simple manner; account management features that allow bankers to program customers into programs such as portfolio management and personal relationship management; a relationship establishing feature for transmitting prioritized request lists on-line and tracking the results thereof; a promotion suppression function that provides information to customers and non-customers who do not wish to be contacted by telephone and/or mail; and a contact history feature that shows recent promotional contacts with each customer.

The CCIS performs a number of functions related to sales activities. To better understand CCIS, the hierarchical structure of financial institutions using CCIS is first briefly described. Large financial institutions such as douglas-bang n.a are all organized into a number of separate public banks located in different geographical areas. Each public bank includes a plurality of individual banking departments. The banking department is usually provided with a department manager, and several bankers. The CCIS preferably includes a workstation located in the banking department for communication with an individual banker or department manager, and may also be located in the main office of a public bank for communication with a bank officer or sales manager. Each of the various workstations may have different functions depending on the user's reimbursement capabilities and responsibilities within the bank.

The department manager receives the list of leads generated by the micro-marketing center and distributes them among selected individual bankers within the department by electronically loading the leads into the CCIS workstation. The department manager assigns the lead to the best qualified individual banker for processing the lead, or according to the workload and the available possibilities of the individual banker.

After the tables are generated by the micro-marketing center and communicated with the CCIS, the individual banker receives access to the clue tables on the CCIS workstation. The individual banker then conducts marketing transactions (e.g., telephone calls) with each customer on the thread list. Prior to and during the marketing transaction, the individual banker uses the CCIS to view the entire profile of the customer's relationship with the bank (in a detailed and brief form) and other demographic information about the customer contained in the central database. This enables an individual banker to intelligently talk to customers during marketing transactions and thereby increase the success rate of sales activities.

Next, department managers and bank officers use CCIS as a tracking and reporting management tool to automatically capture daily sales information. The department managers and bank officials use the CCIS to access detailed sales transactions associated with each individual banker and view sales results for various activities to track performance and adjust the activities as needed. The department manager and bank officer also use the CCIS to redistribute cues among individual bankers and/or departments to optimize the use of sales resources.

The invention preferably further comprises a system for opening an account, preferably in a single transaction, comprising: a means for collecting data relating to customer financing and/or investment scenarios; means for performing a desired analysis based on the collected data; means for displaying account information; means for making recommendations based on the necessary valuations; means for inputting a customer component selection; means for adding account components to a single account to establish a single account that provides all of the services that the customer wishes to provide and to maximize customer needs; means for executing a credit check; means for determining a single fee based on the services provided; means for authorizing a customer to use a remote access product including an issuing bank card and a pin device; means for identifying missing data and means for urging a user into a location that has not yet been provided with data. The system also includes means for linking the data fields in each component so that once a set of data is collected, the set of data is provided to all appropriate data segments. In addition, the system is structured to enable the user to bypass the data segments and provide such data in later transactions. The system is preferably able to communicate with the central database, micro-marketing center and departmental systems of the present invention to enable data to be transferred between these legitimate and appropriate systems.

An important aspect of the system of the present invention is that it is processed to allow data to flow up and down so that once a significant set of data is collected, it is transmitted to each location where it is needed. In other words, all similar data fields are linked together. This provides a number of advantages. First, even when some other user collects the data, the user (bank employee) never asks the customer for the data that has been previously provided. Second, system users have the flexibility to collect data at the appropriate time during their introduction to the customer. Third, in legal and appropriate circumstances, information can be obtained from other sources, such as the central database of the present invention, to simplify processing. Similarly, the information obtained during the opening process of an account may be used by other components of the overall system of the present invention, such as the lead management system or sales tracking and reporting (management information system or "MIS") component of the central customer information system ("CCIS").

The system of the present invention preferably further comprises a pending file storage means for storing the characteristic data that has been collected but is not immediately required. In this way, if such data is needed during a customer visit to the bank, the data can be extracted without requiring the customer to provide the data that he or she has provided. In addition, the information obtained during the opening process of an account and stored in the pending file may be used by other components of the overall system of the present invention, such as the lead management system or sales tracking and reporting (management information system or "MIS") component of the central customer information System ("CCIS").

Accordingly, the present invention provides an integrated sales processing support system comprising: a central database, means for inputting data from a plurality of sources to the central database, means for normalizing the input data in the central database to a plurality of organizational levels, a plurality of user workstations geographically remote from the central database, each of the user workstations comprising a database and a display device; the plurality of workstations including means for generating a graphical user interface for a user to select a search criteria block to graphically build a graphical structural search query, the graphical user interface including a drop-down window, icons, and drag-and-drop operations; a plurality of departmental workstations connected to each user workstation by remote communication means; and means for transmitting the data records from the user workstation to a plurality of departmental workstations; a central customer information system geographically separated from but linked by electrical communication to the department workstations, means for converting the search query in a graphical structure into a text query comprising the required code and syntax to ensure that the text query can be run; means for allowing data communication between the user workstation and the central database; means for retrieving a database response in response to receiving a structured query from one of the user workstations and identifying records matching the query; and means for downloading data to the user workstation regarding records matching the query.

The central customer information system comprises a plurality of customer documents, and the file of each customer comprises demographic information and customer financial information including credit information and financial targets; means for performing a desired analysis on the basis of information contained in the central customer information system, recommending an account to the customer on the basis of the desired analysis and extracting information related to the selected components of the account to the customer; and means for allowing data communication between the central customer information system and the central database.

The central customer information system is preferably geographically remote from the central database. When used throughout this application, the terms "geographically separated" and "geographically distant" refer to an effective spatial separation, such as at different urban or national locations, and not to spatial separations of adjacent rooms or adjacent levels of a building. In connection with the preferred embodiment, "geographically separated" and "geographically distant" systems are maintained in different urban areas such as, for example, New York, Washington, California, Texas, and Florida.

The system may further include a means for tracking customer arrivals at the department office; wherein said system further comprises a means for tracking and reporting information about the arrival departments associated with new and existing customers who have undergone a sales process, the information comprising the following information: arrival form, wait time, sales transaction time, average transaction time, use of sales instruments, product type, price of each product, name and address of the customer, product type, visit purpose, and sales representative ID.

The present invention also provides a process for identifying sales targets, distributing sales leads and enhancing sales tools for marketing campaigns, for use in conjunction with a system comprising a central database; means for inputting data from a plurality of sources into a central database; means for retrieving a database response to a structured query and identifying records matching the query; at least one micro-marketing center having a plurality of user workstations in electrical communication with the central database; a plurality of geographically separated departmental systems, each departmental system comprising at least one departmental workstation; and a central customer information system geographically separated from but linked together by electrical communication with workstations at the departmental systems.

The treatment comprises the following steps: inputting data from a plurality of sources to a central database; standardizing and housekeeping the entered data into a plurality of organizational levels within the central database; informing the micro marketing center of the concept of the sales activity; generating cues for defining a list of customers as targets during the sales activity by inputting criteria into a user interface of the user workstation based on the concept of the sales activity; creating a structured query responsive to the selected criteria and using the structured query to retrieve the central database, identifying records in the central database that match the selected criteria, and generating a customer table as a target during the sales campaign and electronically distributing the customer table to the departmental workstations.

The process further comprises the steps of: displaying a profile of relevant customer information on the customer table included with the customer from the department workstation at the time of a sales transaction with the customer during a sales campaign. Additionally, the process may include the step of using a graphical user interface that allows the micro-marketing center to generate a document containing the mailing address and to transmit the document to a geographically separate departmental system.

The process may also include a step of tracking customer arrivals and tracking and reporting information about the arrival departments associated with new and existing customers undergoing the sales process at the department office, the information including: arrival form, wait time, sales transaction time, average transaction time, use of sales instruments, product type, price of each product, user name and address, product type, visit purpose, and sales representative ID.

Furthermore, the terms "geographically separated" and "geographically distant" as used in this application refer to effective spatial separation of locations such as different cities or countries and not to spatial separation of adjacent rooms or layers of a building. In connection with the preferred embodiment, the "spatial separation" and "spatial distancing" are maintained within different urban areas such as, for example, New York, Washington, California, Texas, and Florida.

The invention will become more apparent from the description of the invention with reference to the accompanying drawings, in which:

FIG. 1 is a high level diagram of the sales and services support system of the present invention;

FIG. 1A is a flow diagram of a sales process using the system and process of the present invention;

FIG. 2 is a schematic diagram showing the components of a central database;

FIG. 3 is a block diagram showing three basic levels of storage of (in-home) information in a central database;

4A-4D are block diagrams illustrating various tables that make up a data connection device for accessing a central database;

FIG. 5 is a flowchart showing the processing steps for generating a clue table from the central database based on criteria for selecting a workstation to enter a micro-marketing center;

FIGS. 5A-5H are displays of various graphical user interfaces for workstations within a micro-marketing center that illustrate the process of registering a registry, structuring a query, defining a process for running the query and generating a report, providing the leads to a particular campaign, and downloading a file to an online department system;

FIG. 6A is a flowchart showing initialization processing steps for accessing and entering information from a central customer information system;

6B-6C are flow diagrams illustrating processing steps for viewing various client and home document screens from a central client information system workstation;

FIG. 7 is a flowchart showing the process steps for using the account management functions of the central customer information system;

8A-8C are flowcharts illustrating the process steps of a relationship establishment system using a central customer information system;

9A-9B are flowcharts illustrating process steps for sales tracking and reporting functionality using a central customer information system;

FIG. 10A is a block diagram illustrating the steps of a preferred embodiment of a method for opening an account to a new customer in the integrated financial system of the present invention;

FIG. 10B is a block diagram illustrating the steps of a preferred embodiment of a method for opening accounts to existing customers in the integrated financial system of the present invention;

11A-11C are flow diagrams illustrating processing involved in the account selection/required analysis step of the method illustrated in FIG. 10;

FIGS. 12A-12E are flow charts illustrating preferred embodiments of the processing steps for creating a personal profile according to the method of FIG. 10;

FIGS. 13A-13M are flow diagrams illustrating a preferred process for performing the step of establishing an account in the method of FIG. 10;

14A-14G are flowcharts illustrating processing included in the account service steps in the method illustrated in FIG. 10;

FIG. 15 is a flowchart showing steps performed in the method of FIG. 10 to execute a print registration form;

FIGS. 16A-16F are flow charts illustrating an optimal process for performing the step of setting an access level according to the method of FIG. 10;

17A-17B are flowcharts illustrating processing for performing the tracking step in the method of FIG. 10;

18A-18C illustrate an embodiment of a financial statement fax screen display generated by the system of the present invention.

To facilitate the sales process, the system of the present invention links all the departments of a large commercial bank together. In particular, a large number of databases are linked to the user workstation to allow the user to query the databases. According to one aspect of the invention, a graphical interface is provided to allow users who are not familiar with structured query languages to obtain information from the database. The database is also linked to a central customer information system ("CCIS"). The present invention ties all of these departments together and provides a systematic way to target customers and track the effects of customer needs.

Using the system of the present invention, a department can determine an activity and coordinate the activity with a local micro-marketing center. The system of the present invention can be used to target customers and generate multiple tables.

According to an important aspect of the invention, the system of the invention is directly linked to a online portal system. In this manner, the cues, preferably loaded by the micro-marketing center, may be automatically transmitted to multiple departments. The local micro-marketing center is particularly important to the system and process of the present invention. In particular, the present invention provides a micro-marketing center capable of generating tables identifying various mailing addresses and providing links to online CCIS department systems. This gives the local micro-marketing center all the capabilities available in the analysis workstation. In addition, the micro-marketing center can hide various addresses, such as business or legal addresses. Cues generated using this approach can be automatically loaded into the system the evening before to provide the cues directly to multiple departments.

With respect to the local micro-marketing center, the system of the present invention includes a graphical user interface for allowing the local micro-marketing center to generate a plurality of tables for identifying various mailing addresses and linking to the online CCIS department system. This allows the original sales center to directly provide the lead to a particular event. In general, the sales process flow can be described as follows with reference to FIG. 1A.

Initially, a department user (bank administration) decides to promote a promotion. The local micro marketing center is informed of the concept of promotion. The system allows a local micro-marketing center to generate multiple cues using a user workstation. Typically, a request may be executed for 5 minutes to 24 hours, depending on the size and type of request. Cues are automatically loaded onto the system (preferably a component of CCIS) to provide the cues to departmental users and individual bankers the evening of the previous day. The individual banker may then use the lead and relationship documents (preferably also components of CCIS) associated with the sales invocation.

The central customer information system ("CCIS") preferably includes a relational document component, an account management component, a thread management system or sales tracking and reporting (management information system or "MIS") component. Each component can generate a report that is provided to the user (department management) to complete the sales process.

The electronic sales and services support system is preferably capable of interfacing with a single account for opening all financial components. Thus, the integrated system of the present invention preferably further comprises a system for opening accounts, preferably within a single transaction, which preferably communicates with the central database, micro-marketing center, central customer information system and departmental systems of the present invention to enable data transfer between these legitimate and appropriate systems.

Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings.

Fig. 1 and 2 show an overall view of the present invention. The system includes a central database 10, a micro-marketing center 11 having a plurality of workstations 12, a central customer information system ("CCIS") 13, and an Account Opening System (AOS) 17. These components may be "geographically separated" or "geographically remote" from each other and linked together by remote communication links 14, 15 (e.g., an X2.5 network) or other means to place the micro-marketing center 11 and the CCIS13 in electrical communication with the central database 10. When used throughout this application, the terms "geographically separated" and "geographically remote" are intended to provide effective spatial separation of locations such as different cities or countries rather than to provide spatial separation of adjacent rooms or adjacent floors of a building. In connection with the preferred embodiment, "geographically separated" and "geographically distant" systems are maintained in different regions of the country, such as New York, Washington, California, Texas, and Florida.

In particular, the workstation 12 of the micro-marketing center 11 includes software such as Omnis7, Omnis7 communicating with the host computer of the central database 10 through a SYBSE inter-network connector and a token ring network. In this manner, the system can be accessed by any remote location provided the user has authorization to obtain the requested query or report.

As used in the following description, a "thread" is a customer or non-customer that is specifically targeted at a sales attempt on a potentially needed basis. The clues are self-identifying and may be part of an ongoing attempt or part of a short-term activity. An "activity" is a group of targeted sales leads (customers or non-customers) managed via the CCIS13 for the purpose of introducing or deploying new and existing products and services offered by the financial institution.

As used herein, "transaction" generally refers to a telephone-based meeting between a personal banker or other sales representative and a customer that results in the sale of a product or results in a service being delivered to the customer and/or other members of the customer's home. Transactions are employed to meeting customers, discussing the needs of the customer management department, and providing products and services to meet customer needs.

The term "product" generally refers to a financial institution's savings, investment, loan or mortgage account, among other terms. The term "service" generally refers to something other than savings, investment, or credit account such as credit card, brokerage, direct access, check for cash, telephone delivery, insurance check, etc., provided by a financial institution. The terms "product" and "service" are used interchangeably throughout this application.

The various components of the present invention are described in detail below.

Central database

The central database 10 is the basis for all applications of the invention. The central database 10 is a comprehensive and rich database that includes product information about all customers and includes department products, bank cards, travel and hospitality cards, student loans, investments, insurance and mortgage products. The central database 10 captures daily and monthly supplies from financial institution processing systems and establishes a very large "data warehouse" to enable easy access to such information. The central database 10 receives information from internal files of a plurality of financial institutions and receives external demographic and other publicly available information to augment the database.

The central database 10 is designed to ensure the accuracy of the information and to make the information readily available to non-technical personnel. Thus, the system includes a means for cleansing and standardizing the information to be retrieved, housekeeping, profiling processes, calculating status codes, maintaining a plurality of tables, and calculating policy flags.

The purpose of the central database 10 is to store information from various stores and departments within the financial institution at one location. In the case of a bank, for example, a particular customer having a billing account, having a student loan and the fact that they have been requested multiple times by bank cards or related to various products may be stored in the central database 10.

The central database 10 may include information relating to existing customer financial information, information from external sources, and demographic information about existing and potential customers. In the preferred embodiment, the central database 10 is located within the host computer and includes a large repository of financial and demographic data. Information is provided to the database from various source feeds 21-25, where the source feeds 21-25 include business and credit card feeds 21 and 22, customer demographic feeds 23, customer phone number feeds 24, and feeds 25 from various external distribution points within the financial institution for each product and service offered by the institution.

The data from the various suppliers 21-25 are stored in a unified format in the central database 10. For this purpose, it is preferable to use a uniform memory, a home algorithm, a name and address standardization process, and a merging process. In this manner, the central database 10 acts as a single central depository for storing all of the customer-related information obtained by the financial institution. The family algorithm links different accounts into a single unit that is considered a family based on information such as the same last name and the same address, or the same name or a specific secret number representing different accounts of the same person or people living in the same family. The home process provides a reasonable way to obtain data from the central database 10 and logically extract these data.

As indicated in fig. 3, the information is preferably maintained in the central database 10 in a three-tiered hierarchy-family, customer and account. A given household may have one or more customers, and each customer in the household may have a number of different accounts. As will be discussed below in connection with the database device, the three-tiered hierarchy provides "keys" at each of the home, customer, and account levels that meet the user criteria associated with queries, observations, and reports. The central database 10 may be used for widely varying customer service, financial analysis and marketing purposes.

The central database 10 includes a plurality of database components for supporting the operation of the present invention, including a privacy database 30, a domain database 31, a parameter database 32, a production database 33, a query output database 34, a selected query domain 35, and a home-client-account repository 36. These components of the central database 10 are coupled to each other and to an external communication supply using the database means 40.

The secure database 30 stores a table of storage permissions along with user IDs and passwords for each system user. Since the financial institution uses highly confidential and important information, it must limit each user's access to only those database areas necessary to perform his or her job. For example, when a user registers with the system from a geographically remote workstation (described below), the database will perform a security check to ensure that the user provides the appropriate user ID and password, and then restrict the user's access to the database based on the permissions defined for that user.

With respect to each user profile, the secure database 30 holds information about the user workstation, such as the amount of RAM contained in the workstation and the size of the hardware device. The secure database 30 also determines whether the user can access certain accounts, such as sales mortgage accounts and private bank accounts, and whether the user is given access to sensitive name and address information.

The domain database 31 stores definitions and descriptions of all data elements contained in the central database 10. In the preferred embodiment, the system of the present invention loads the elements and data descriptions contained in domain database 31 into user workstation 12 as an initial step in retrieving database 10 from the micro-marketing center. This information is preferably in the form of a data vocabulary or index associated with the central database 10. This data vocabulary or index includes a description of all the elements contained in the central database 10 and all the values of these elements. Thus, for example, if a user wants to view the status of an account, the workstation 12 of the present invention may access values from the domain database 31 that are appropriate for the status of the account. In this example, the system of the present invention may show the user that a particular value is an indication as to whether the account is "open" or "closed".

The system of the present invention has sufficient dynamics such that the system will check the description that a particular element has upon receiving a user request related to that element. If no such description exists, the user must edit the processing details about this element. After initial download from the domain database 31, the data vocabulary and indexes are preferably saved locally on the user workstation to enhance the operation of the system.

The query output database 35 contains the actual results of the search performed on the central database 10. Each report and key file generated during the search is transmitted to the DB2 output table in the output database 35. Once the report is in the DB2 output table in the output database 35, it can be dynamically formatted and accessed as described.

Logical database device component

The database device 40 has two logical components. The first component extracts a key that meets the user criteria. These keys are preferably located at the home, customer or ACCOUNT level (HH _ NO, HH _ NO + CS _ SUST _ NO, or HH _ PO + ACCOUNT IDENTIFIER, respectively).

The second component (data extractor component) picks up all the data item time required by the user. These two components may work together in the same job, or the user may retain the key for processing at other times. In addition, some types of queries do not require key extraction at all, and can obtain data directly without intermediate key extraction steps.

If the user requests and retains the key, the user can use the retained key to pick up different sets of fields at different times (using the data extractor component of the database apparatus). In addition, the user can also reduce the key code groups (and retain new groups, or replace old key code groups) by applying additional criteria to the old groups.

Two components are related to two components of the query-specific transformation: 1) in one component, the user specifies criteria for identifying a domain search; 2) in another component, the user specifies the tags that the user wants from the selected domain. The two components may be executed at once or separately. When executing component 2, the user can provide a previously established key field. In addition, a new key code group may be obtained from a previous key code group established by applying additional criteria.

The key is reserved by using the DB2 table with the user ID as AUTHID. This means that the key code table can only be accessed by the user for which it was built. The job control/scheduling assistance system preferably keeps track of the users/queries/executions to which the key code group belongs. The job control system will delete keys that remain unused for a period of time and are not reused on a periodic basis (e.g., for purposes of generating periodic program trace reports).

Even if the user does not want the reserved key, the database apparatus may temporarily reserve an intermediate key set (one way to obtain the final result) if it is indeed able to enhance the operation. Some schemes for this operating condition will be described below.

The data extractor component of the database means 40, which can be executed alone or together with the first key extraction component, has the function of obtaining the desired data from the database once the key is extracted. If it is executed with the first component, the key may not necessarily remain in the table, but should pass through the main program parameters from the previous SQL statement.

Typically, a user wishes to have a family (or customer) series of account relationships. The account data is stored separately in tables of a central database, which tables are hereinafter referred to as asset/debt (ALA) and Bankcard (BC) tables. Often, users seeking relationship information prefer to see accounts of the same family with each other. To avoid having to sort the order desired (UNION ALL would access the ALA tables before the BC table), the program would open a cursor on each account table and provide output in home (key) order using merge logic. When the key from the key table is read only once, as it is held in memory by DB2, the advantage of this arrangement is that the I/O on the ALA and BC tables can be processed in parallel. In addition, since data is read out in the order of the cluster key, dynamic sequential prefetching may be connected in all tables, with the result that processing speed is increased.

A typical SQL SELECT statement used by the invention is as follows:

SELECT output columns

FROM ALA table，KEYS table

WHERE

HH_NO in ALA＝HH_NO in KEYS table

for ALA series accounts, and

SELECT output columns

FROM BC table，KEYS table

WHERE

HH_NO IN BCO＝HH_NO in KEYS table

bank card set for account.

If the user wishes to get data from the family and/or customer tables, these other tables will be linked in each SELECT statement. If the family key is arranged in family member order, this linking is very quick since DB2 will dynamically prefetch on each table in succession. In addition, since two SELECT are performed in parallel, performance is very superior since DB2 often finds home (and/or customer) rows in memory. With this convenience, the access speed of data is particularly fast through such a very large DB2 database.

If the key is not in the reserved table or from another SELECT statement in the program, the SELECT is modified only by deleting the key table link and replacing the key value stored in the main variable of the WHERE clause statement. DB2 still dynamically prefetches all tables to obtain data.

The generator includes a simple merge logic for outputting in key order. To obtain the required access path, an ORDER BY command may be required in the SELECT statement, assuming that the key table is accessed first and then the nested loop chaining method is used. Otherwise, key tables and use primary variables instead of link conditions are taken separately.

The SELECT statement described above assumes that all of the series of account relationships associated with each family will be extracted at a time. However, the user may request data from only one of these three tables and/or add additional criteria to limit the output. The application of additional criteria should be a task undertaken by other components of the database apparatus.

In some cases, it may not be necessary to extract the key first, e.g., a relational query with unique criteria at the home or customer level, which may use an accumulated column, may be performed without first extracting the key. However, such queries may require post-extraction classification since accounts associated with the same household are not together in the output (due to the use of UNION ALL). Non-relational queries, i.e., single table queries and rule links, also do not require retention of the key.

The word "path" is used to describe a particular group criterion for a particular group of data. In the present invention, there are an account path, a home path, a registration path, and, inherently, a program tracking path and a special super-home path.

The advantages of the path concept are two: first, it organizes the query specification in an intuitive and relational consistent manner, such as where a user specifies that the household must (or need not) contain accounts with certain characteristics in using the account path. Second, the path specification has a fairly straightforward correspondence to SQL, making it easier to transform into SQL statements.

When using the concept of path to describe some details related to the database means 40, the concept of path need not be understood in a user session. The workstations 12 and CCIS13 of the micro-marketing center 11 prompt the user through questions of query rights to generate parameters that can be used to analyze queries about the path.

The account path allows the user to select a family (or other key) that fits a single account registration criteria. That is, the account path is provided to all households that contain accounts for a given product, where the product also has certain other attributes, as may be desired. The SELECT statement associated with the account path is:

SELECT DISTINCT HH_NO

FROM ALA

WHERE

(PRODUCT _ CODE

The product code may be a P-type, S-type, or source product code. Specifying these values (dialogs) may be somewhat complex, as the unique values or codes may depend on the combination of columns. If the user wishes to specify a product code at the service type level, the query can be answered in one step using a tag and accumulated variables at the home level.

However, even in this case, the user may wish to specify other characteristics (opening data, individual account balances, etc.) that must be possessed only by products that may vary at the account level. This query will collect all households for accounts of the appropriate products and related characteristics. The criteria in brackets are provided for one product. The DISTINCT clause may be used in a query to delete exactly the same family that may occur with more than one account of the requested type.

A user may wish to have a family of one product with certain characteristics or a family of other products with certain other characteristics. Alternatively, the user may wish to have a family that contains other types of products simultaneously or no other types of accounts.

Generally, this is a theoretical problem. It may be treated as each individual account path resulting in a SELECT statement that gets executed and gets a series of keys at the home level (group HH1, group HH2.. group HHn) or the customer level. The final desired set of families comes from the following logical statements:

HH1 AND HH2 OR HH3 NOT HH4....

where parentheses are used to clarify the order of operations. All the above are equivalent in SQL. For example, the following SQL statements:

SELECT DISTINCT HH_NO

FROM ALA

WHERE

(PRODUCT_CODE＝？)AND

(.. other Account specific terms linked by and/or)

AND HH_NO IN

(SELECT HH_NO

FROM HH2_TABLE)

Similar to the first two sets of ANDed's, where the first SELECT statement represents the HH1 set, and the internal sort uses the previously selected and retained second set of keys (HH 2). If two groups of HH1 and HH2 are represented by keys stored in multiple tables, an and relationship can be obtained by simply linking between the two groups.

The above approach to the problem is not optimal because it requires multiple paths to the database. In many cases, only one path is required. Different scenarios are discussed below.

This approach requires two if the user wishes to obtain a family with one account or anotherIndependent of each otherAccount path specification (dialog), two SELECT statements are generated. Each selection statement will be executed and two sets of families are obtained. These two sets will then be ored.

However, the same purpose can be easily achieved by adding other brackets to the insert in a SELECT statement:

SELECT DISTINCT HH_NO

FROM ALA

WHERE

(PRODUCT _ CODE

AND (.. other account-specific conditions linked by AND/OR)

OR

PRODUCT _ CODE? (second product code)

AND (.. other account-specific conditions linked by AND/OR)

The statements in parentheses specify all the characteristics associated with a particular account that the family must have. The OR operator allows the user to specify all the characteristics of other types of accounts that the family must have. For example, the second account may have a different balance, etc. If the selected household has at least one account with one of two sets of characteristics, the household may be selected using a query. Since the logic is applied to one row at a time, the OR logic can be performed at one data entry.

Another way to specify OR logic is to use the IN object, as follows:

PRODUCT _ CODE IN (PRODUCT list)

However, by using this statement, any other condition specified in the WHERE clause will likely be applied to each PRODUCT selected (e.g., andbellance > 4000 will be applied to each PRODUCT individually). The workstation software ensures that the dialogs in the two OR logic cases are different to avoid errors.

If the user is looking for a family with two (or more) accounts at the same time, then the query has two (or more) account paths, with the result that the selection statement will be more complex. There is another way to be able to compose a selection statement for two or more account paths. The first related sub-query is as follows:

SELECT DISTINCT HH_NO

FROM ALA A

WHERE

({A.PRODUCT-CD＝？AND(A. ...)})

AND HH_NO IN

(SELECT HH_NO

FROM ALA B

WHERE

A.HH_NO＝B.HH_NO

AND

({B.PRODUCT-CD＝？AND(B. ...)})

the home table in the sub-selection may be retained and brought back as a key table. This key code table may be linked to a higher level selection (meaning that the household must meet both criteria) or may be linked to an external SELECT in the same way (AND HH NO IN..).

An additional and more efficient way to do this is to link between the two original tables, as follows:

SELECT DISTINCT HH_NO

FROM ALA A，ALA B

WHERE

A.HH_NO＝B.HH_NO

AND

({A.PRODUCT_CD＝？AND(A. ...)}

AND

{B.PRODUCT_CD＝？AND(B. ...)})

the use of related sub-queries avoids two paths to the data. However, the linking approach is the same, since data relating to other rows within the same household will likely be located in memory. In either case, a database manager benchmark should be included to validate execution.

In addition, a query may be corrupted and intermediate results for family members are stored. An index for the product code is preferably used to increase the speed of retrieval. The extracted different HH _ NO can be saved and reused later. Or directly to the second data extractor component.

The NOT path always requires two data paths. If the user wishes to obtain a family that does not have an account of some kind, the database means 40 first looks up the family that has an account of that kind. The system then finds the complements of these households. The following selection statement provides an example of a NOT path:

SELECT DISTINCT HH_NO

FROM ALA A

WHERE

HH_NO NOT IN

(SELECT HH_NO

FROM ALA B

WHERE

({B.PRODUCT_CD＝？AND(B. ...)})

the NOT path is used for two reasons that are NOT as simple as it seems. First, the unrestricted complement may not be sought by the user, and second, the query may perform quite poorly if in the manner proposed.

Typically, when on the account path, the user will specify products that are not only conditioned by using variables that depend entirely on variables such as financial (account balance, amount transferred, etc.) and descriptive (open data, sales status) variables, but also other conditions by using variables that are indirectly related to the account, such as organizational level, geographic location, etc. Relatedly, these variables are part of foreign keys, their presence in the account row establishes the relationship between the account unit and the ORG or geographic unit.

Preferably, the logical intent of the user is that the retrieval of the household should be limited to this organizational level, geographic location, etc. In this case, the SELECT statement described above cannot fulfill the user's intention. This will be made clear by the SELECT statement developed below:

SELECT DISTINCT HH_NO

FROM ALA A

WHERE

HH_NO NOT IN

(SELECT HH_NO FROM ALA B

WHERE

((B.ORG AND B.GEOGRAPHIC，etc.conditions)

AND

({B.PRODUCT_CD＝？AND(B.other_product_conditions...)})

in this expression, the sub-selection has the ORG/GEOGRAPHIC condition, so the product condition is retrieved in this account sub-group (family). However, when performing the complement, without such a limitation, the database will retrieve all households that do not belong to the organization and geographic location. The generated family group will typically be large and not desired by the user.

To overcome this problem, the ORG and GEOGRAPHIC conditions must be repeated in the external selection. The most appropriate expression for the NOT path SELECT statement is as follows:

SELECT DISTINCT HH_NO

FROM ALA A

WHERE

(A.ORG AND GEOPRAPHIC，etc.conditions)

AND

HH_NO NOT IN

(SELECT HH_NO

FROM ALA B

WHERE

((B.ORG AND B.GEOGRAPHIC，etc.conditions)

AND

({B.PRODUCT_CD＝？AND(B.other_product_conditions...)})

however, since many households have multiple accounts with different ORG and GEOGRAPHIC values, the question arises as to whether the system allows those households that have smaller accounts with ORG/GEOGRAPHIC conditions and at the same time do NOT have an account of the desired type NOT to be closed. This is called the original (Prime) versus real problem; whether the system should use the PRG/GEOGRAPHIC of the legacy account (stored in the home or customer table) or the PRG/GEOGRAPHIC of any account. If the answer is original, then the external selection will look at the family table.

This query must set a benchmark in the database manager. When there are too many households IN the NOT IN table, there are two options to reduce the time for querying. First, the IN table can be stored and re-read out IN order, using an index, via a process that does not match the remainder of HH _ NO IN the database. Second, the home key may be stored in a table using a home index. With either of these two options, the database will perform NOT IN logic very efficiently.

The NOT ACCOUNT PATH can be easily added to the previous ACCOUNT PATH using the SELECT statement as follows:

SELECT DISTINCT HH_NO

FROM ALA A

WHERE

(A.ORG AND A.GEOGRAPHIC，etc.conditions)

AND

({A.PRODUCT_CD＝？AND(A.other_product_conditions...)})

AND

HH_NO NOT IN

(SELECT HH_NO

FROM ALA B

WHERE

(B.ORG AND B.GEOGRAPHIC，etc.conditions)

AND

({B.PRODUCT_CD＝？AND(B.other_product_conditions)})

the following discusses home paths, enrollment paths, and program tracking and superfamilies paths and their combination with account paths.

The home path is used to specify conditions that apply to the entire home. These conditions may be specified directly or indirectly. The direct specification is made using a plurality of columns in the home table. The following is an example:

SELECT HH_NO

FROM HHD A

WHERE

(A.ORG AND A.GEOGRAPHIC conditions)

AND

A.HH_CHK_TOT_BAL＞10000

the last condition is an example of using a pre-accumulated variable.

Whenever the home is composed of conditions using existing home variables, the home path conditions and any one account path conditions can be combined and executed at one data portal by means of the link. The following SELECT statement provides one such example:

SELECT HH_NO

FROM HHD A，ALA B

WHERE

A.HH_NO＝B.HH_NO

AND

(A.ORG AND A.GEOGRAPHIC conditions)

AND

A.HH_CHK_TOT_BAL＞10000

AND

({B.PRODUCT_CD＝？AND(B.other_product_conditions...})

however, at some point, the home level condition may not be specified by using the stored home variable. This is true for the accumulated variables needed at a product level lower than the accumulated service type level in the home table. This family path must be executed in a separate SELECT statement using the GROUP BY and HAVING clauses. Typical examples are:

SELECT HH_NO

FROM ALA A

WHERE

(A.ORG AND A.GEOGRAPHIC conditions)

AND

({A.PRODUCT_CD＝？AND(A.other_product_conditions...})

GROUP BY HH_NO

HAVING

(SUM(ACCT_BALANCE)＞500

AND

(SUM(ACCT_CR_LIM)＞10000

AND

COUNT(*)＞3)

family-generated groups may be retained (permanently OR temporarily) AND combined with other family groups IN the same OR other queries (AND/OR/NOT IN).

These queries will be particularly fast to execute if the index is used for balance, loan limits, ORG, geogeraphic variables, etc., and includes family members among them. The dialog may combine the specification of this request with the specification of the account path since the accumulation exceeds the account data. The database means may optionally be arranged so that the ORG and geogerapic variables are referenced to actual and/or initial variables.

The customer path is very similar to the home path. The main difference is that with this path, the combination of home and customer values is reserved for use as a key.

Definition table

The block diagrams shown in fig. 4A-4D illustrate various tables relating to maintaining definitions associated with the database apparatus 40 and used to access the central database 10. FIG. 4A illustrates a definition table for the parameter database 32; FIG. 4B shows a definition table used to generate database 33; fig. 4C shows a reference table for the database apparatus 40; and FIG. 4D shows a definition table for the domain database 31.

Referring to FIG. 4A, the definition table for the parameter database includes, for example, a "Query Run" table with the abbreviation "QRN" for the first letter abbreviation of the table, which is populated with information from the initial Query input to the workstation 12. The database means 40 continuously reads the Query Run table to see if any new requests are being made.

The Query Run table tells the system whether a new request has been processed. If a new request is processed, the Query Run table reads the other parameter tables and extracts all the information provided by the workstation 12. The Query Run table then generates SQL and Cobal programs for the Query. The database means 40 then accesses and extracts data from the central database 10 by generating a query for the home, customer or account table run.

The other tables shown in FIG. 4A are look-up logical task tables. This table contains information about how many jobs must be logically executed to generate a particular query.

Shown below the Query Logical Task table in FIG. 4A is a path relation table. This table targets domains that are relevant to a particular query. That is, the path relation table determines whether the database means 40 generates a home level key, a customer level key, and an account level key associated with each query, or generates an output specification for extracting actual data. The path table refers to a path relation table and informs the database means whether to use the home or account path.

The QLT entry table tells the database device 40 whether the query is an output description or whether it is fetching a report or key. This table also provides information about which type of program is being used to extract a report.

The path look-up table is used to explain to the database means 40 which central database the user needs to access. The path row reference table contains information that tells the system the type of path (path id) to be used. For example, the path line reference table is used to tell the system whether to generate a "container". The continain is a command that is used to withdraw all homes, customers, or accounts that have (or offer) certain financial products (e.g., checks, deposits, CDs, etc.). continain can also be used to retrieve only some households in a particular bank or department.

The path clause table provides additional restriction information that the user can type in. For example, in addition to a person having a check and a deposit, a query may be limited to a person also having a deposit balance greater than $10,000. This information will be stored in the path clause table.

The generation database table shown in FIG. 4B contains some of the same tables as the parameter database shown in FIG. 4A. The area in which the query is run is read again using the database means 40. The generation database contains all the information generated on the basis of the information in the parameter database. This information is read and logically manipulated to build SQL, which is then inserted into the Cobal program to extract the data. The SQL code table contains the actual SQL code generated by the database. After the SQL code information is stored on the SQL table, the other components of the database apparatus 40 read the information from this table.

The other components of the database device 40 extract the SQL codes from the production database and insert them into the Cobal program. The system then uses this Cobal program to build the JCL. The system uses a standard JCL to generate all the JCLs it needs, and then submits this job to the internal reader where it is compiled. This job in turn generates another job that submits the actual execution job, which then extracts the required data from the central database 10.

The reference table shown in fig. 4C includes various reference information tables for providing a formula query. The key type table contains key types to be extracted and information on each key column. The system control table is a parameter table for giving a supply related to parameters used by the dynamically changing system. The job registry maintains a registration of any errors that occur. The restriction type table contains information about the organization to be accessed (e.g., a certain number of accounts in a particular bank or department). This information is used for statistical purposes to determine the best way to generate the SQL. As described above, there are some ways to construct SQL statements, which makes SQL more efficient for retrieving large amounts of accounts or information.

For example, when a query is entered, the system will determine how many accounts are included in each of the different types of accounts that need to be retrieved (e.g., checks, deposits, CDs, etc.). The account type with the least number of accounts (the least number of rows in an account row) will be placed first in the SQL for maximizing speed and efficiency of retrieval. The same process is used for multiple tissues. That is, if more than one organization (bank, department, etc.) needs to be retrieved, the system will first retrieve the organization with the fewest number of accounts.

The job activation table contains the status of the job when executed. The organizational table contains a description of each bank and department. The product table contains a description of each product. The view relationship table contains information about which intent is related to which other intent and which table is related to which other table. The error table registers all errors that occur during system operation.

Referring to FIG. 4D, the domain database tables include SView, PView, Groups, Elements, and EFunc tables. These tables are stored in the high-level data dictionary and in the database means 40. Information from these tables is extracted and placed into another set of DB2 tables containing the intent id. The oversized intent is used to define logical paths related to the query and to link certain related tables together.

The database arrangement 40 allows a user to type or click-through information on a user-friendly graphical interface at the workstation 12 to enable the user to easily and quickly access the large and rich central database 10. The workstation 12 communicates the acronym and the pseudorandom code to the database means 40 and then converts the code into a logical access path to extract the data from the central database 10. Since the database apparatus 40 generates SQL associated with each query, the user does not need to know how to write a program and a line of code for accessing the central database 10. The logical access paths generated by the database apparatus 40 greatly increase the performance of the system, whereby a very large database can be efficiently retrieved.

Micro marketing center

The present invention includes one or more micro-marketing centers, each of which includes a workstation 12 preferably used by banking departments for identifying customer tables for selling new financial products and services based on demographics, account balances, products, ownership, and the like. It would be desirable to provide a plurality of geographically dispersed regional micro-marketing centers. The micro-marketing center 11 generates a plurality of files containing sales leads that can be directly downloaded to the CCIS 13. These downloaded threads are then passed through CCIS13 to the department manager coordinating the efforts to run the threads using CCIS13 to sell the new products and services being offered.

When a single central repository for storing all customer-related information throughout the financial institution provides a large potential customer, a very large database is required so that it cannot be retrieved practically directly. The invention therefore comprises a means for allowing a user to dynamically set up a program for retrieving the central database 10.

The system of the present invention includes at least one and preferably a plurality of workstations 12 in the micromilling center 11 to allow users to retrieve information contained in the central database 10 and to generate sales lead (i.e., sales target) tables related to sales activities. The preferred embodiment includes two different types of workstations- -an analytics workstation and a micro-marketing workstation. The analysis workstation allows the user to create a query, specify or design a report and run the process, i.e., run the query, and then form the results of the query into a report. The report may then be downloaded or output. The micro-marketing workstation allows the user to perform the same functions as the analyzing workstation and also generates marketing information or marketing cues and provides these cues directly to the CCIS 13.

The workstation 12 within the micro-marketing center 11 includes means, preferably in the form of designed software, running on a general purpose computer and for generating a graphical user interface ("GUI") for dynamically building programs associated with retrieving the central database 10. The workstation 12 downloads a local copy of all tables and structures from the central database 10 that can be retrieved using the workstation 12. This ensures that all system users are provided with the latest definitions and fields each time they access the system.

In addition, the system includes a means for the user to walk through each step of establishing a search request, including the use of drop-down windows, icons, drag-and-drop and other features similar to those of modern computer users. In addition, the system includes a means for building "appropriate" SQL queries associated with each request and hiding the special code and syntax required to ensure that these queries will run. The system also includes means for downloading the reports and documents to the local workstation 12.

The micro-marketing center has the ability to generate systems for identifying various mailing addresses and linking online CCIS departments. In this manner, the files themselves may be loaded into the online department system. For business or legal reasons, it is desirable for micro-marketing centers to have the ability to hide various addresses.

The plurality of micro-marketing workstations 12 preferably form the micro-marketing center 11 to respond to requests from department managers for lead lists associated with selected marketing programs. The sales process typically includes sales activities related to new and existing products or services offered by the financial institution. The micro-marketing center 11 works with department managers to determine the profile of households, customers, and/or accounts that are most likely to purchase products or services for sale campaigns. The micro-marketing center then forms a specific query, runs the query against the central database and generates a report containing the best lead list associated with each sales activity.

The workstation at the micro-marketing center provides a means for retrieving the central database 10 and retrieving all home, customer or account tables that meet certain selection criteria. These thread lists are then used to target direct mailing to customers or households that meet certain selection criteria related to the sales activity, or are passed directly to the CCIS 13.

Referring to fig. 5, the micro-vending workstation 12 first displays a registration screen after power-on. The registration screen provides security control of access to the workstation 12 and the central database 10. After entering the user ID and password, the workstation 12 activates a remote procedure call to verify the user ID and password against the central database 10. If the user's ID and password are valid, the registration window disappears and provides access to the rest of the system, including the lower level menus of the micro-sales workstation. If the user is authorized to access, the user profile, priorities, and appropriate remote procedure calls are read in for initializing and normalizing the operator interface.

After a valid registration, it will be the billboard message for the current user ID that is checked. If an unread message is found, the user will be prompted to view the list of unread messages, but the user can ignore the prompt and read the message at a later time. Immediately after registration, a menu is displayed, as shown in FIG. 5A, that allows the user to select between the analysis workstation and the micro marketing function. The menu also provides the user with access to other functions, including utility, licensing capabilities, customer base profiles, and transaction reports, among others.

Upon selecting an analysis workstation or micro-marketing from the menu of FIG. 5A, the workstation will next display a main menu, as shown in FIG. 5B, to provide high level access to the functions required to create and open the query, report and process objectives used by the workstation 12. From this main menu the user is given the option to set up a new query, report or treatment, or to open an existing one. If the user chooses to create a new query, for example to fulfill a department manager's request, the user may then enter various parameters relating to the query structure.

After the query is composed, the user then enters various parameters relating to the report format, and finally the user specifies a process to run the query and report, submit the query and report to job queuing, and run the query and report against the central database 10. When the query and report is completed, the workstation 12 will display or print the results of the search and download the results onto an output file or transmit directly to the CCIS13 for transmission to the banking department that needs the report.

To ensure that the query is logically composed, a dialog always follows a combination of subsequent and/or logical steps combined with almost free-hand user interaction. The best dialog is a quick-select dialog. The quick selection dialog begins by asking the user for the type of query he or she wishes to perform. There are two main forms: relational or non-relational. Dialogs for non-relational selection can be considered a subgroup of relational dialogs.

The program tracking file interfaces with the quick selection by creating a relational key table using an account document previously registered in the system. The driver document uses the same program. After the drive or program tracking file is entered into the system and processed so that the key table is built and retained, the user can proceed by selecting any of the options and methods described above.

The user is first asked if she wishes to perform an analysis at the home or customer level. The answer decides whether the key will be retained at the home or customer level. It may also decide certain link conditions, etc., to be generated for the user secret. The user will begin by composing a query consisting of standard blocks that specify the desired home, customer, and/or account domain. After composing the appropriate query, the user will run the query by composing a process consisting of blocks of processing steps such as queries and reports.

For example, as shown in fig. 5C, the standard block defining the home domain is constructed so that it can restrict the domain of homes and NYB new york banks having more than one open service as reporting banks. In the standard block of fig. 5C constructed, the user is prompted to populate the standard columns by selecting "# (open services)" and "REPORTING BANK" from the standard table loaded from the central database. In the case of selecting "# open SERVICES", the user first selects the category "SERVICES" from the additional criteria menu shown in fig. 5D, and then selects "# open SERVICES" from the additional criteria submenu shown in fig. 5E. The condition "greater than" and the value "1" are entered or selected from the menu display shown in fig. 5E. The criteria block may also be structured to define the domain of the selected customer and account.

As shown in FIG. 5C, after the query is built, the user runs the query by building a process using the display shown in FIG. 5F. The process shown in FIG. 5F, for example, submits two steps, Query and Report, to the central database. The reporting step is established by defining the report type and report parameters using the display shown in fig. 5G. Upon selection of Run from the display screen shown in FIG. 5F, the specified processing is performed with the system, i.e., running the query against the central database and building a report based on the query results and the specified reporting parameters. As shown in fig. 5H, a display screen is provided to allow the user to directly index a line to a particular activity well to load the file directly to the departmental system.

Complementary code and general restriction criteria

The user will be required to enter his own complement (realm) restriction criteria and the level to which it will be applied. The complement restriction criteria is a criterion that will restrict the family (or customer) group that is retrieved when the complement of the criterion needs to be selected. The complement search typically has NOT IN or NOT continens logic or functions.

The way these functions are computed is to first find the key (home or customer) that meets a positive condition. The complements of these keys are then obtained. For example, if it is desired to obtain some households that do not have a certain product, the system will first find households that have that product and then find the complements of those households. During the search for the complement, the set of households that are searched must be limited or the result is generally undesirable. The standard that restricts the retrieved homes during the subsidizing operation is called the subsidizing limiting standard (supplement limiting criterion).

The two complement limiting criteria that are best used in the present invention are: location (organization) criteria and geographic criteria. The position criteria will always be required. The initial value may be set from a user profile. Each user is assigned a maximum level of organization to which the user has access to their data. Default location criteria are assigned to the user's query, which criteria can be changed by the user as long as the user restricts further data (by specifying one or more lower levels in his own hierarchical path). The job is scheduled as a fast and long running job using the position criteria.

The location criteria field is preferably located in its own selection table. The workstation will ensure that neither input will invalidate the user profile. However, the user will be forced to go through these selection processes at least once.

The geographic criteria include fields such as country code, divided zip code, etc. These fields should also be located in their own window selection table.

In addition to the above-mentioned complementary restriction criteria, restriction criteria are provided that typically have common characteristics at all levels of the database hierarchy (home, customer, and account). At the account level, a common limiting criterion is the Actual (Actual) value associated with each account. At the home and customer level, these criteria are values derived from the initial (Prime) account.

Thus, the complement restriction criteria can be applied in three ways: at the actual level, at the initial level, or at both levels. The user is asked at which level he wishes to perform the analysis and then the workstation generates the appropriate selection criteria whenever any level is desired.

If the initial level is selected, it will be applied to the Board Committee (borad). If the actual level (or two levels) is selected, the user is given the opportunity to change the complement limit criteria each time an account path is entered.

If the key table is kept, it can be operated on by NOT IN as long as NOT IN appears with the AND operator (AND NOT INKEY table).

The application level of the complement restriction criteria may be required within its own window associated with the location and geographical selection table described above.

By: 1) specifying whether she wishes to retain the generated key; 2) the previously retained key is programmed into the current selection process, giving the user an opportunity to specify key table operations.

If the user does not wish to retain the generated key, the user will later be forced to specify a table of output columns, output formats, etc. In other words, the user will be forced to go through the output specification dialog. The key will be retained for later re-use at the level specified by the user (home or customer), as desired.

If the user wishes to reuse the previously retained key code list, a window is opened on the workstation interface to show her an available key code list. The user may click on one of the key code tables to obtain further information about it. The ability to reuse and improve the key code table makes the system very flexible.

Once the basic problem is solved, the workstation can show a menu comprising a series of selection tables indicating the various groupings of data available to the user, each member of the family, the customer and assets and liabilities and long bank account tables. Each selection table has an associated selection criteria window in which the user can see the criteria established using the data of that table.

In addition to the data selection window, there is a path correlation window where the low level selection criteria under each window relate to logical operations and parenthesis (parenthesis) in themselves, as will be described below.

Workstations in the micro-marketing center provide operations for using the data selection table in generating queries and qualifying reports. The use of these data selection tables is explained below.

Family and client selection lists or paths

A first set of windows is provided on the workstation interface to establish selection criteria for using the family and customer columns, respectively. The workstation will assist the user in performing this task graphically.

For example, the user may click on a column, select in an SQL operation, and pick from a table of valid codes. When the user has fully identified all SQL attributes, the attributes are moved into the relevant selection criteria window in a "ghost" manner. The user can then pick up the attribute AND insert it into a particular component of the selection criteria window, at which point the user can select among AND/OR/NOT AND bracket operators to associate the attribute with other criteria already within the selection window. In a similar scenario, the user may move or delete previously entered attributes within the selection criteria window and/or add/delete/move any brackets.

The workstation assists the user in building attributes including any SQL function and/or a set of arithmetic operators so that the user can include these attributes in the selection criteria. Any initial attribute into the selection criteria window associated with the data window will automatically establish an entry for the data path within the path-related window, which can be controlled as described below.

Account: selecting tables or paths

There are some special cases of account selection tables under relationship selection. First, the account selection table works with the account path function. There are 4 initial account path functions:

1. family (customer) includes accounts

2. Family (customer) does not contain account

3. Family (customer) containing accounts with certain aggregate characteristics

4. A family (customer) with some aggregated characteristics does not contain an account.

With respect to the family inclusion/non-inclusion account path function, a function is taken and then a criterion is specified at the account level associated with that function in a manner similar to the criteria specified for the family and customer. This provision also establishes an entry in the path correlation window.

Each of the functions has its own specific characteristics. The first two (which will be referred to hereinafter as account paths) allow access to the selection criteria associated with being primary account paths. There are three primary account path standard versions:

1.CG_PROD_TYPE＝A AND(CG_ACCT_BAL＞1000 AND...)

2.(CG_PROD_TYPE＝A AND(CG_ACCT_BAL＞1000 AND...)

OR

(CG_PROD_TYPE＝B AND(CG_ACCT_BAL＜3000 AND...)

3.CG_PROD_TYPE IN(A，B，C)AND(CG_ACCT_BAL＞1000 AND/OR....)

3 formulas for primary account path criteria are possible, but they provide very different answers. The second formula is a generalization of the first and the third formula is a special case of the second. For non-expert users, it is appropriate if the workstation limits the user to one and two. Thus, a single selection criterion may constitute a family inclusion function that selects a family having any one or more products with particular characteristics.

The selection criteria for a family inclusion/non-inclusion account with some aggregate characteristic function has two components. In the first component, the user specifies the product whose properties are to be aggregated. This first component is similar to the primary account path criteria described above.

In the second component, the user specifies which characteristics are to be aggregated and the aggregation conditions at which household (or customer) is to be selected. The aggregation may be counted, summed, or averaged. The general criteria are:

in the case of the WHERE clause,

CG_PROD_TYPE＝A AND(CG_ACCT_BAL＞1000 AND......)

in the case of the HAVING clause,

(SUM(CG_ACCT_BAL)＞5000 AND COUNT(*)＞3)

a select product function is also comprised by the workstation. Instead of the different column names (CG _ SERV _ TYP, CG _ PROD _ TYP and CG ═ SUB _ PROD _ TYP) existing, the workstation has a hierarchical structure of one product. The hierarchy is preferably presented in graphical form and includes higher level aggregations (assets or liabilities, savings versus loans, transferability versus non-transferability, etc.). The user may select groups of products located at any level of the hierarchy. If the selected product group is not stored as a value/column IN the database (e.g., turnaround flag), then the workstation will generate a composite attribute or IN table with values that lie within a hierarchy equivalent to the user's desired product group.

If the selection is made at the CG _ SERV _ TYP level and an aggregation function is required, the workstation will recognize these already existing at the home (customer) level and use them. The database will find out whether the user has specified a criterion at the account level that is consistent with the criteria stored at the home or customer level in the central database 10.

When the user enters selection criteria (and uses the account function) associated with different data selection tables, a higher level of internal path logic must be defined. The user will be required to enter logic operators and/or parameters to define these logics. This is a high level of logic that will direct the generator. As described above, the user can click in & type an attribute component and drag (move) or delete it, etc., with respect to the individual selection criteria associated with the data path. Double-clicking activates a detailed selection criteria window associated with the attribute component (the key table component will display a description of the key table). At the same time, the user may print this or any other data/selection criteria window for the query, or the entire query details.

Although SQL provides a language to establish the selection criteria, the high-level functions supported by the system require one such set of machine passwords. The set of passwords is used at the path correlation window, however, the set of passwords is useful at each individual selection criteria window. To give the desired set of advanced passwords, the best common format is shown using the following example.

Universal format

{ Path } { (high level function @ function-seq-no } { (SQL or other clauses and/or parenthesis) }

Examples of paths

HHD-Standard input at Home.

CUS-criteria entered at the customer.

LOC Lv 1-position criteria at initial (P), actual (a) or at two levels (PA).

GEO × Lv 1-geographic criteria at initial (P), actual (a) or at two levels (PA).

ALA-criteria for asset & liability accounts.

BC-standard for bank card accounts.

Examples of higher-level functions

CONT-family (customer) contains accounts for specified products

NCONT-family (customer) does not contain accounts specifying products

AGG-products with certain aggregated (Home, customer) characteristics (SUM, AVG, COUNT) for the Home

NAGG-family (client) lacks products with certain aggregate (family, client) characteristics (SUM, AVG, COUNT)

Examples of clauses

PROD-primary product (account type) criteria. Products may be limited to various levels (SERV-TYP, PTYPE, STYP, or a prescribed group such as all assets, all debts, all loans, non-loans, etc.)

HAVING-describes the desired polymerization characteristics of the chosen primary product standard.

The above-described password is combined using AND, OR, NOT (in) AND an input word within the path correlation screen OR on the selection criteria screen. For example, within the path interrelationship screen, the password may be combined as follows:

HHD AND CUS AND LOC*P AND GED*P AND

((ALA*CONT@l AND ALA*AGG@2)OR

(SAVED-KEY-TABLE))

at the individual routing window, a password may be composed for the asset/liability account, as follows:

(CONT@1[PROD(SERV_TYP＝’CHK’AND CG_ACCT_BAL＞2000)]

AND

AGG@2[PROD(PROD_TYP＝‘CD6’)

HAVING(SUM(CG_ACCT_BAL)＞1000 AND COUNT＞＝1)])

at the selection criteria window, the user will see details of the high level logic described within the path interrelationship window. AGG, CUT, etc. are used as identifiers for higher level functions. In DAX/Prime type queries, these functions do not exist and the selection criteria look similar to the direct SQL standard. Additionally, the path correlation window may be avoided by having the workstation generate a simulation of it to analyze the primary frame, or by having a database generator at the primary frame do more work to drop the request.

The workstation may be provided with processing attributes that span the entire path, as shown, for example, in the following statements:

(HH _ FIPS _ ST _ CD ═ 36 'or CG _ FIPS _ ST _ CD ═ 36'

However, such criteria are not typically required other than location and geographic data and these cases are only considered when asking if the user wishes to apply such criteria at an initial or actual level.

After the user has completed all of the steps described above, she may submit her execution-related query and follow its progress on the job control subsystem. In addition, the user may output a description to use with the selection criteria (domain selection).

Central customer information system

The CCIS13 preferably includes workstations located in the banking department for each of the bank's staff and department managers and workstations located in the main offices of commercial banks for officers and/or commercial bank sales managers. Each of the various workstations of CCIS13 can have different functions depending on the task and responsibility of the user within the bank.

The department manager receives the list of leads generated by the micro-marketing center and electronically loads the leads into the CCIS workstation for distribution within selected individual banks within the department. The department manager assigns the leads to a more competent individual banker to handle the leads, or to assign the leads based on the individual banker workload and capacity.

After the table is generated by the micro-marketing center and communicated with the CCIS, the individual banker receives access to the cordage table on the CCIS workstation. The individual banker then conducts a marketing transaction (i.e., a telephone call) with each customer on the thread list. The individual banker uses the CCIS13 to view all documents of the customer's interrelationship with the bank and the customer's demographic information (detailed or generalized) about other customers contained on the central database 10 before and during the marketing transaction. This enables an individual banker to intelligently talk to customers during marketing transactions and increases the success rate of sales activities.

Department managers and bank officers next use CCIS13 as a tracking and reporting management tool to automatically capture daily sales information. The department managers and bank officials use the CCIS13 to access detailed sales transactions associated with each individual banker and to view sales results for various activities to track performance and make adjustments to the activities as necessary. The department manager and bank officer can use the CCIS13 to reassign the lead among individual bankers and/or departments to optimize the use of sales resources.

Thus, CCIS13 is a marketing, management, and sales tool. CCIS13 includes a series of integral components for viewing user information and managing user contacts and interrelationships. The operation of CCIS13 is described below.

Referring to FIG. 6A, the workstation of CCIS13 first requires a registration and validation process similar to that of the micro-marketing center 11 workstation. The user enters their user ID and password into the workstation, which the system verifies against the central database 10 to establish the user's interface settings and options and to determine the user's rights. Upon entry of a valid user ID and password, the workstation displays a main menu giving the user the following choices: a relationship profile component, an account management component, a thread management system, or a sales tracking and reporting component. Each component is described below.

Relationship archive component

The relationship profile component of CCIS13 allows appropriate work members to discover and view family, customer, and account level information. The relationship profile component shows current and past financial and behavioral information about the overall relationship of the home or customer with the financial institution. It contains information about the individual accounts themselves, how the customers do their banking transactions at the financial institution and whether they are managed by a particular individual banker. The relationship profile component provides a sales preparation tool that displays all of the information available about the customer, the relationship between the customer and other customers, and deep account information on all accounts owned by the customer and/or the entire household.

Detailed and summarized information is available in the relationship profile component. In combination, the information in the relationship profile may be used to estimate the depth of each banking relationship to better prepare sales and service sessions.

The relationship profile component includes a promotion prohibition feature that allows the financial institution to mark or otherwise identify these customers and non-customers who have not requested contact via telephone, mail, or both. Customers who do not like promotional contacts may be registered on the promotion prohibition screen in the relationship profile or in the relationship establishment function if the customer is listed as a lead during the campaign. Non-customers who do not wish to be solicited may also be registered on the inhibit screen from the main menu.

Once the customer identification is identified, the inhibit flag is automatically passed to all applicable customer information screens and becomes a component of the table generation process to ensure that these customers are not contacted.

The relationship document component also includes a customer promotional contact history file containing information regarding contact with customers who previously participated in a mailing or telemarketing campaign. The customer contact information may be viewed using a relationship profile component or a relationship establishment function.

Contacting the history file is particularly important as it enables stores in the financial institution to avoid "over-contacting" customers. It helps to unify and manage the customer contact process.

Referring to FIG. 6B, in the case where a relationship profile component from the Main Menu is selected, the user is given the option to: namely, a family search function, a promotion prohibition function or an assignment of a shift key to each relationship file screen is selected. If the home search function is selected, the user is prompted to enter selection criteria (e.g., unique identification number, name, address, bank, department, service, etc.) to discover and view information about a particular customer, home, or account.

The retrieval function can be used in two ways: facilitating a small search for a particular client or viewing a registry client form. Each function enables a user to select a particular customer for viewing information about that customer.

During viewing of the registry client table, the user can enter the personal number of the personal banker and the name of the registry. The system would then provide an alphabetical list assigned to the individual banker, with the ability to select any of these families to view information about that family.

Once a particular household, customer, or account is identified, a number of customized display screens may be available to represent information about the customer. For example, as shown in FIG. 6C, the user may select from a general customer information screen, a family profile screen, a customer needs and notes screen, an account details screen, a family documents screen, a family financial profile screen, a family demographics screen, a family contact history screen, and a family link details screen.

The general customer information screen displays general customer information including the product owned by itself, the service used, and the characteristics of the customer. The customer information on this screen includes the name and address of the customer and the "best" phone number based on the matching of the supply and the outside, inside the central database, and the name of the customer's personal banker (if any). The customer information on this screen also includes details of the customer's activities, including check number written, teller transactions, ATM usage, electronic and telephone banking services used, check delivery from financial competitors, current and past balance of balance, net income of the customer, credit card usage patterns, department of customer initial account signing address, department of customer optimality based on frequency of use, and other products and services used by the customer, etc.

The family account profile screen shows accounts and other information related to all members of the selected family. By selecting a product or account from the table displayed on the home account profile screen, the user is able to see detailed product and account information.

The customer needs and notes screen identifies potential sales opportunities based on account owner, credit balance, and customer characteristics. These are systems that generate auxiliary information. The screen also allows the user to add the user's own annotations to capture information about the customer (e.g., householder, children, competitors, store address changes, etc.) or to record remote access to the customer.

The account details screen shows information about a single account. The top of the screen shows customer information, while the bottom of the screen shows details about a particular account, including applicable balance history.

The family profile screen displays information about the entire family. It includes aggregated financial and product information, specific information about each family member, and additional external "best-forecast" demographic information used in planning visits or for studying sales plans. The family document screen also displays the initial name, address, phone number and department for the family that can be retrieved from the family initial account.

The family/customer financial profile screen aggregates accounts owned by all members of the family or by a particular customer into product types (primary services) and balances against previous months and years. A profile may be obtained for all accounts, private bank accounts, business only accounts, or retail only accounts. All products owned by the home or account will be displayed, including investment services such as commission accounts and administrative funds, loan services such as banking cards, credit lines, mortgage credit, and commercial and professional loan products, and other fee-based services such as savings and security insurance.

The family demographic screen displays additional family information purchased from an external source. This screen may also display information inferred about other information about the customer. For example, repeated use of a credit card at a child store may be used to infer that the customer has one or more children.

The family contact history screen displays family level information about telephone marketing and mailing contacts. This information is from a customer contact history file that captures information about customer contact (telemarketing visits and mails) from the financial institution stores and from the use of the relationship establishment function.

The home link details screen displays the links used by the central database 10 to link the home process to the customer account. It displays the account number, the last name on the account or store name, zip code, type of link, and link value.

In order to properly manage certain households, two or more households must be linked together or parts of a household are unlinked to segment multiple households. The CCIS13 includes an account linking or unlinking means for linking multiple accounts together based on information received from the source system, such as public names and addresses, social security numbers, and account links.

Account management component

The account management component of CCIS13 is a system in which account officers manage groups of households and/or customers by registering them in specific programs provided by financial institutions. Once a family or customer is registered in a program and designated to an individual banker, the individual banker can provide customer personal relationship management to better manage the customer's banking relationship. The customer will be marked as a managed household to alert other sales personnel to the customer's exclusive relationship with an individual banker. It also ensures that the cues distributed from the micro-marketing center 11 are assigned to the individual bankers associated with that customer. The customer has the added benefit of having only one individual banker who knows the needs of the customer.

The account management component includes an online report viewing and printing facility for generating a monthly report for use by individual bankers and their department managers to rate program growth. The reports represent the account manager information in a variety of ways, from individual account and customer level information to a view of the entire traffic profile.

Referring to FIG. 7, in the case of an account management component selected from the main menu, the user may select account registration, registration preservation, account officer reassignment, traffic financial profiling, or report submission facilities. These functions will be described in succession.

By selecting account registration, the workstation displays a registration selection screen. The registration selection screen allows a user to select a program, provide program information, and register a plurality of households in a specific program. The registration program table is updated and saved in the central database 10.

After selecting a specific program or programs from the table, a family registration screen that allows the user to register a plurality of families in one program at a time will be displayed. The user enters information associated with each household including an account number and a specific address, if any. The registration is then processed in the central database 10 and displayed by selecting a registration details screen. To avoid registering a family in more than one program or personal banker, CCIS13 automatically displays a registration details screen and CCIS13 alerts the user whenever the user attempts to register the customer in an account management program, and when the family has been registered in a valid program.

By selecting the register save from the main menu, a mailing address or register save screen is displayed for selecting or establishing a particular home and/or store address that is valid only for the CCIS13 registration program, or making registration changes or deletions on CCIS 13.

By selecting account official reassignment from the main menu, an account official reassignment screen is displayed to reassign or delete all traffic relating to multiple households of the individual banker in the registration program. This feature is most useful for those users who have the right to control officers.

Reassignment may be to all registered programs or only selected programs and may be used to reassign the same officer to a different department or to reassign registered programs to different officers in the same department or in different departments.

By selecting the traffic finance profile from the main menu, the user can select a report format and display a dynamic report indicating the current registration. The traffic finance profile is an online report that displays aggregated information on account basis for households that are registered in a program assigned to individual account officers. It aggregates the accounts in the traffic into product types and compares the balance of revenue and compares the net income of the customer with respect to the last month and year. Separate reviews are preferably available for the general account, tax free account (taxsharer), business account, and retail account.

By selecting the report submission facility from the main menu, the user can run the reports and place them in a file so that they can view and/or print from the report viewing facility, or transfer them to a central database for printing. These reports preferably include account officer profiles, traffic profiles, growth measurement summaries and home traffic profiles. The reports are "instant" reports available at the personal banker, department, area, and bank level.

Thread management system

The thread management system of CCIS13 provides full thread management capabilities to individual bankers via online delivery of sales tables. It utilizes manual selections associated with work leads to support a comprehensive sales process with numerous options for work leads, including placing active leads into a calendar for other activities, joining a new lead (current and non-customers), and communicating the lead online to a particular or other individual banker in the financial institution for future activities.

The thread management system is a contact management component of CCIS 13. The thread management system provides paperless delivery of threads to individual bankers, paperless delivery of appropriate expert work arrangements and paperless capture of sales activities within the financial institution.

The thread management system supports integrated sales processing. The individual banker has a number of options for working sales leads. They may work on meeting schedules, without regard to prioritized "next" clients in an activity, "next" clients related to a particular activity, or threads that are already in progress.

The thread management system also allows the user to directly add threads to the CCIS 13. These cues may be cues that they work personally or cues that they will refer to other experts within the financial institution.

The individual banker is provided with all the bulk of the sales preparation information about the campaign and customer in order to prepare for the sales contact. The results of the contact are put into a personal calendar function that is updated in real time. This allows the individual banker to place and track each sales call.

The bank manager and regional director may view lead statistics such as the ratio of leads being utilized to those that are not utilized in the department associated with the activity and in the individual bank's home within a particular department. Threads can be specified and re-specified so that they can be allocated more efficiently.

The thread management system starts with a thread database for each individual banker. These are organized and prioritized by a program so that the best clues are used first. These cues are also subject to account officer assignments so that the cues are first provided to the individual banker or officer assigned to the relationship.

Referring to fig. 8A, the thread management system provides a means for selecting a number of functions from the main menu. The department manager may specify the availability and product characteristics of an individual banker using the user profile characteristics of the system administration/table keeping functions. This functionality allows the department manager to communicate user utilization and product characteristic information for the system. This information is then used to determine: which individual banker is accepting new leads and which is on vacation, etc. that are included in a particular plan; which individual banker is receiving clues at multiple locations; product characteristics such as mortgage and investment that should be used in a given thread.

Referring to fig. 8B, the lead management system also provides an activity registration function for establishing new sales activities. The campaign registration function is preferably centrally performed by the management of the CCIS13 in cooperation with the management of the micro-marketing center. However, the clues may also be manually entered by the individual bankers and department managers. When an activity is in progress through the activity registration function, client and non-client cords are separately listed and joined in the activity.

Threads are established according to management priorities. The activity registration process has three components. First, the activities must be planned and coordinated. This also includes threads that are prioritized by the organization that will use the thread. Second, a quality critical cue file must be created and transmitted to CCIS 13. Third, the activity must be registered on the activity registration screen.

The activity registration screen captures information for distributing cues and performing the activity. The information input to the activity registration screen preferably includes: a description of the activity including collaborator name and address and explanation, the purpose of the activity, and any limiting factors; rank assessment of a certain activity of all activities; whether a work dispatch thread can be added to the activity; whether new hints can be attached or whether the activity should be re-established when refreshed; major events such as start and expiration dates, retention periods, purge dates, etc.; how to rank cues in the activity (e.g., by settlement, aggregation, profitability, or a particular priority order); and on what basis the department chooses to run the lead (e.g., where to deliver the account; where to do more transactions, mailing address, etc.).

The cues are then assigned to the individual banker on a pre-prioritized basis. The lead management system honors existing individual banker relationships. Clues associated with the customer or family registered in the account management program are automatically assigned to the individual banker who manages that relationship.

The thread management system has a calendar function, an automatic thread transfer function, facilities capable of joining additional customer and non-customer threads, and an automatic activation tracking capability. In addition, the user may be "tethered" to other screens of the thread management system or customer profile system using the transfer key to view customer information or perform other functions.

The sales processing function of the thread management system is explained in detail with reference to fig. 8C. The sales processing functions provide a number of features including thread tracking, activity selection, thread selection, sales preparation, sales profiles, thread input/work assignment, and thread review trails.

When the user selects the lead tracking feature, all scheduled appointments and events are displayed with date and time. The subscription may be used for main tracking, telephone calls, or face-to-face meetings. The user may use this feature to view information about the activity or customer such as contact history, customer notes, and sales tips to revise customer information and contact results, provide the customer to other vendors, or reschedule a planned activity.

When the user selects the activity selection feature, the feature lists all of the activities specified to departments and/or individual bankers having a certain number of leads and lead status associated with each activity.

When the user selects the thread selection feature, the feature displays the thread on the basis of how the display is requested. The clues may be displayed in columnar order or alphanumeric order. From this screen, the user can view activity or customer notes, view product and settlement information, view contact history, view reminders, correct customer information and contact results or schedule tracking activities, or update customer contact information and provide customers to other vendors.

When the user selects the sales preparation feature, the feature displays all activity related to the customer and the customer contact information such as name/address, phone call, best call time, barring information, and previous contact history. This feature also provides sales preparation hints and comments from other sources of the system. For example, the customer's prompts and comments come from the customer information in the relationship profile component. The activity prompt originates from the activity registration function, while the activity annotation is entered by the person running the thread on the "infinite" annotation book. Activity hints and annotations are located within the thread.

When the user selects the sales profile feature, the feature is used to capture the results of each sales contact and sales attempt. The system will present an appropriate screen to enter information for closing the lead, saving the lead in progress, scheduling the next event associated with the lead, updating the customer information or entering customer notes, etc.

The sales profile properties provide information to the meeting schedule (thread tracking screen). If the date is entered the meeting schedule will be updated and the event will be scheduled as well. The sales profile screen will also provide information to various facilities to summarize the list of leads such as call attempts and to provide various administrative activity statistics for use by the authorities.

When the user selects the lead entry/job assignment feature, this feature is used to assign or reassign both customer and non-customer leads to an activity and a particular department and/or individual banker. The lead input/work assignment screen can also be used to capture new leads or to capture information on work assignments to enable leads to be added to the activity or transmitted to other individual bankers.

The thread that is always assigned to a particular activity may relate to an existing customer or non-customer. The cues may come from walk-in stores, clients attending seminars, work assignments from current clients, and the like.

When the user selects a thread to check the trail feature, the feature informs the individual banker whether any of the other individual bankers have also run their designated thread. The thread check trail screen displays threads that have been run by other individual bankers or that have been transmitted to or out of a list of individual bankers. The department manager may examine all individual bankers in their department who examine the nature of the traces using the cues.

Campaign selection management functions are used to balance the campaign load in individual bankers and departments. The departmental load balancing screen shows how the cues associated with each activity are assigned to the individual banker in the department and indicate "new" cues relative to these "in-progress" cues. This screen allows the lead to be moved from one individual banker to other individual bankers, from one individual banker and all individual bankers in the given department redistributed equally, or retransferred together and exited from the activity on a workload basis.

The activity load balancing screen is similar to the departmental load balancing screen, but shows how the cues associated with each activity are distributed among the departments rather than within the individual banks. This screen allows for threads to be moved from one department and assigned to another, moved from one department and reassigned to all departments on an average basis on a workload basis, or moved together and exited all of the activities.

The administrative reporting function displays or prints an organizational or activity level report indicating the status of the cues in each activity. The reporting function also displays a listing of all departments within an area or bank that are associated with a particular activity and a listing of all activities associated with each particular organizational level.

Sales tracking and reporting component

The sales tracking and reporting component is a management information system ("MIS") that provides daily online sales integration reports and services for organizations related from banks and regions to departments and individual bankers. The sales tracking and reporting component utilizes the central database 10 to analyze and report sales transactions associated with each individual banker or other customer service representative.

The sales tracking or management information component of CCIS13 preferably takes the form of a general purpose programmable computer linked to other systems of the present invention using remote communication means such as an X.25 network. In particular, the sales tracking and management information component is linked to the other components of the system so that every transaction occurring within the system can be tracked. This provides numerous opportunities for tracking and reporting sales information to facilitate the sales process. For example, the sales tracking or management information component preferably includes a means for receiving input from the departmental system and a means for tracking and reporting online totals according to two different hierarchies, products and organizations. Online viewing and printing on a daily basis is available and totals are available through departments and sales representatives in the store. In addition, information may be reported on a time period of days, months, quarters, and years.

Sales transactions are stored in the central database 10 for a scheduled time (e.g., 24 months) after entering the CCIS 13; the sales transaction can be captured from the actual order during the marketing transaction and can be obtained in real time after transmission to the central database 10. The sales tracking and reporting component includes a sales summary stored in the central database 10 that is updated daily so that the latest sales information is available at the beginning of each business day.

Referring to FIG. 9A, the sales tracking and reporting component includes three functional components: "sales tracking" for establishing the report; "table save" for viewing or updating the table; "department inputs" for adding transactions, correcting transactions, entering information related to other types of sales activities.

As shown in fig. 9B, the sales tracking function includes a series of preset formatted reports displaying detailed sales information by using information stored in the central database 10. Sales performance reports show sales in terms of debts, assets, investment products made by several accounts and with new and existing dollars. This report also provides a comprehensive report on the tables of departments and individual bankers.

The service report shows such sales as direct access, enhanced telephone and check with cash. Cross-sell (cross-sell) performance reports indicate the number of products sold to new and old customers per transaction. The funding source report shows whether the funds provided to the account are from other competing banks, investment companies, and specific types of accounts. The customer source report shows the campaign and advertising effectiveness. The department activity report shows the department activity entered via the sales tracking and reporting components. The performance versus goal report shows whether a particular department or individual banker achieves the goals set by the campaign manager.

Referring to FIG. 9A, the transaction and form preservation functions of the sales tracking and reporting components provide several department input screens. Based on the user's privacy profile, the user may use the department entry screen to add, delete, or edit information related to the entire transaction, customer, product, service, funds, or other type of sales activity. The input information is then processed and updated on the central database 10 and made available for viewing using sales tracking and reporting functions.

Sales tracking and reporting functions are preferably used to provide an objective indication to facilitate the compensation of the owner. For example, the sales tracking component provides an indication of the amount of revenue generated by each individual banker and department manager associated with the financial institution. This in turn provides a direct indication to the financial institution of the value of the individual banker or department manager. Customer attendant techniques for sales tracking provide rapid, time-printed data excerpts from customer databases.

When used in connection with departments that employ greeting stations or some other method of tracking user arrivals as described below, the sales tracking or management information component of the CCIS of the present invention preferably includes a means for tracking and reporting the number of customer arrival numbers or sales planning strategies executed by type (postal, telephone in person) extracted from the greeting queue. The sales tracking or management information component exchange of the CCIS may include a means for tracking and reporting the average number of transactions that do not result in an account opening or the number of times a sales plan document screen has been accessed.

The sales tracking or management information component can generate a number of additional reports when used in connection with departments that employ greeting stations or some other method of tracking user arrivals as described below. For example, the system can track and report information related to the arrival of new and old customers in the department for processing via sales, including the following: arrival type, wait time, sales transaction time, average transaction time, use of sales tools, product type, price per product, customer name and address, product type, and visit purpose and sales representative ID.

The sales tracking or management information component of the CCIS may also track and report information about some instances of customers abandoning waiting queues, including the following, when providing a greeting station and some other way of tracking customer arrivals: type of arrival, time of arrival, all wait times, time desired to wait, customer name, customer address, and purpose of visit.

The sales tracking or management information component also tracks and reports information related to examples of exceptional loan and liability rate guidelines given to the customer during account opening. This report includes the following information: customer name, account number, customer type, reason for disclaimer, sales representative ID.

The sales tracking or management information component also tracks and reports information about where providing loan and debt rate guidelines to customers during account opening is precluded. This report includes the following information: customer name, account number, account type, instructional pricing rate, exception cause, and sales representative ID.

Customer scoring and contact strategy

An integrated customized life-time value (LTV) score is determined for each customer using the information contained in the central database 10. The LTV score is calculated based on all revenue contributed by the customer over the entire distribution of products and services used by the customer. Revenue from all products and services is grouped together to provide an indication of the customer's total to the bank. The LTV score is then converted into selectable characteristics on each customer record so that sales and service programs can be designed around the lifetime value. For example, activities related to certain banking products or services are limited to customers having a life value exceeding a predetermined amount.

In addition, a score is generated that dynamically updates the customer's net revenue for indicating a current value of the customer's individual revenue. This score may be used to compare commercial financial institutions to select candidates relevant to the sales/department program, and to identify the contribution of primary or exempt strong customers.

A number of affiliation policy models are preferably used in the present invention to identify and target sales leads that are the best candidates for each sales activity. These models are based on expressing the client's preferences in some way. For example, a customer who meets certain criteria, such as having one family, having multiple children, having educational funds for college and having low savings or investments, has a greater likelihood of using certain credit products. The affiliation strategy model uses the objective cues generated in the micro-marketing center 11 to increase the success rate of the salesperson's affiliation to customers through the CCIS 13.

The name/address standardization component provides a systematic way to select the "main" names and addresses from among the many possible customer names and addresses in the database and standardize them to generate the names and addresses that are best suited for mailing. By standardizing names and addresses, forms may be facilitated to be generated from end-user desks.

The distance from the department component provides a customized system method for selecting the three department locations closest to the given address, accessing the geographic characteristics of an account such as a river, etc. This feature enables the three banks or departments closest to the address to use a targeted marketing program that utilizes the radiation marketing technique.

Account opening system and process

Another important aspect of the present invention is the interface to the electronic sales and services support system and the process for opening a single account that encompasses all areas of financial content. Thus, the integrated system of the present invention preferably further includes a system 17 for opening an account, preferably in a transaction. The system preferably communicates with the central database, micro-marketing center, central customer information system and departmental systems of the present invention to enable data to pass legally and appropriately between these systems.

In its most preferred form, the system 17 and process for one-step account or relationship opening includes a series of general steps or stages of generation. They are: account selection, necessary rating, creation of personal documents, creation of customer accounts, selection of customer services, registration with remote access services, printing of registration forms, issuing of bank cards, determination of personal identification and numbers that can be accessed to an account and ultimately are suitable for being tracked.

The means for accomplishing these steps include a specially programmed general purpose computer, a modem, a printer and card holder. The computer is programmed to provide various active (but not activated) "hard-wired" unified accounts that are connected to each other rather than on a specific basis. Generally, the system includes a means for collecting data relating to the status of the customer's financing and/or investment; means for performing the necessary analysis on the basis of the collected data; means for displaying account information; means for proposing a proposal based on the necessary valuation; means for inputting a customer component selection; means for displaying a facsimile or representation of a customer-bank statement; means for adding account components to establish a single account for providing all services required by the customer and maximally satisfying the customer's needs; means for updating a display of a facsimile representation of a customer bank statement; means for executing a credit check; means for determining a single fee based on the services provided; means for registering a customer with a remote access service, the means comprising means for issuing a bank card and personal identification credential code; means for identifying missing data and means for prompting a user to enter data that has not been provided.

FIGS. 10A and 10B show one current optimal sequence of the advanced elsewhere account opening process of the present invention. In particular, FIG. 10A shows a process for a new customer and FIG. 10B shows a process for an existing customer. The process is quite similar. The difference is that the bank already has basic information about the existing customer and the existing customer typically has some knowledge of the services and access devices provided by the bank. In general, differences in processing steps reflect differences between account criteria and account conversions. As will be explained below, the order of the particular steps may be changed without departing from the central goal, i.e., one-step account opening. The preferred embodiment of the system for performing the steps of fig. 10A-10B will be described in detail in conjunction with the flow chart of fig. 11A-11B.

User identification (greeting) system and procedure (100)

An optional but useful step in the one-step relationship opening method is the initial scanning step, which is sometimes also referred to as the greeting step. The purpose of this step is to greet predefined customer information and clarify customer visits.

On the basis of banking contacts, customers are greeted and queued, typically by entering departments. This initial greeting step is useful for identifying new customers. For a new customer, the customer's name, address and purpose of visit are required. For an existing customer, the customer can be identified in a series of different ways: by account number, name (single or with address and zip code), social security number and bank card or by entry of a number or by bank card insertion or personal identification number (PIC) entry. The system includes a device such as a specially programmed general purpose computer or workstation and an input device (such as a keyboard, card reader, mouse or touch screen) that allows a user to input data obtained from the customer.

The greeting then builds (in the case of a new customer) or invokes (in the case of an existing customer) a document that allows (a cashier or personal banker) to learn as much information as possible about the customer; including but not limited to credit card information, mortgage information, tax masking information, etc. The system of the present invention preferably allows different levels of access depending on the needs of the user and the desired flow of customers. For example, a greeting or teller typically has limited access because the bank requires that they complete a transaction as quickly as possible. On the other hand, an individual banker will typically spend more time with customers and will provide more access. If the greeting does not capture a pre-limited identification document, the system will prompt the next user to capture the pre-limited document before conducting a credit check. Thus, the system allows this initial information to be gathered at one of two steps. In particular, the system of the present invention can be programmed to allow data entered using one step to flow up or down into other (preferably all) relevant data fields for use in other, and preferably all, steps.

The initial greeting step 100, which does not go through the necessary steps in the system of the present invention, is helpful in achieving the goal of not having to ask the customer for information already provided, as simply as possible to do so for the customer. The greeting can also determine the purpose of the customer's access. The guest address is modified to change access and meet the needs immediately when available. The initial greeting step also makes it possible for the next user to prepare for the customer as described below.

The greeting step is particularly important when the account opening system and process are used as part of the integrated system of the present invention. In particular, in addition to the foregoing advantages, the greeting step provides useful information relating to the customer and potential customers entering a department and allows a determination to be made of, among other things, how long the customer is waiting online and how often the customer visits a particular department. As noted above, this is useful for the management information system component of the CCIS of the present invention.

View document System and procedure (200)

Before meeting a customer, the user (individual banker) should view the customer profile to prepare a sales session. To this end, the system preferably includes a general purpose computer and/or a plurality of networked workstations. Of course, the computer or workstation should include some type of display. The primary goal of profile viewing is to prepare sales transactions with customers. Furthermore, during this step, additional information legally and suitably obtained from the central database may be used.

Address direct need system and step (300)

Customers sometimes need to be in contact with the user's bank for very special and simple reasons that can be handled quickly and do not require close personal assistance. Examples of such include purchasing credit certificates or american savings bonds. In this case, the customer should be served as soon as possible. The system determines whether the customer is interested in simple transactions that can and should be processed directly by prompting the user. In this regard, the system may include a general purpose computer or workstation having a display or other means for prompting the user.

Account type selection system and procedure (400)

After the customer is greeted and immediate needs are considered, the customer is greeted by the next user (usually by a personal banker) if not desired in the immediate needs of the address, and the customer profile continues on the same system. An individual banker (also a user) will present some basic questions to the customer to determine the customer's financial needs in general and how best to assist the customer. In particular, the type of account required by the customer is determined (assuming the bank provides more than one account classification). The account opening process is flexible enough to support customers interested in opening an entire account, such as short term credit certificates, as well as customers willing to spend a long time discussing their financial needs and opening the individual components best suited to their integrated account. To facilitate this step, the system includes a general purpose computer or workstation programmed to prompt the user to provide certain data, receive the data, and transmit the data to all relevant data segments. The system may also comprise suitable input means to allow a user to interact with said computer.

The discussion with the customer will also give the customer (typically a personal banker or customer banking telephone service center representative) the component of the present invention that the customer is specifically interested in and the component that the customer needs to sell to the customer within the all-in-one banking account. The system has flexibility to address the large differences in customer interaction. To accomplish this, the system is programmed to allow data to flow upstream and downstream to any location it needs and to check at each step to see if the needed data has been received. A programmed general purpose computer is used for this purpose and the computer works as if the data fields associated with the account components are "hard-wired" to each other. In this way, data will be requested once and only once at the point in the process where the user feels most convenient. As will be discussed below, the system also provides an "pending" file for storing the collected relevant but not immediately required information.

As shown in fig. 10A-10B, the process after the account type selection step is slightly different for new customers than for existing customers. In particular, the process for the new customer presents each step in sequence. However, for existing customers, the user may choose to avoid account introduction altogether or require a rating step. This again allows the user (the personal banker) to make use of his or her judgment. For both processes, the process steps are substantially the same, as will be discussed below.

Need to assess value System and procedure (500)

The need valuation system is essentially a sales tool to allow users and customers to select the best account and account components associated with particular customer needs. The system for requiring the steps of valuation is flexible so that data consistent with the sales qualification of the user or telephone service center representative and the express needs of the customer can be provided in order. In addition, the system includes a computer programmed to accomplish this by transmitting data upstream or downstream to its desired location. In this way, the user can temporarily delay entering the standard data.

The need-assessment step involves entering data in response to more detailed questions identifying particular customer needs and/or relating to the user's sales opportunities. These questions will help the user to customize the integrated bank account associated with the customer. The system is again programmed to pass the data input in this step to other relevant fields.

A description of one embodiment of the account selection and valuation required steps is shown in fig. 11A-11C. This process can be easily understood by referring to the flowcharts and the flow charts of fig. 11A to 11C. However, a series of characteristics must also be recorded.

As shown in fig. 11A, once the user enters the account process, they have a screen provided with a selection of accounts or access needs. Thus, if an account is interested in a particular type of account, such as a "CITIBANK" or "CITIOLD" account, the demand analysis process can be bypassed.

In the example shown in FIG. 11A, when the user SELECTs "SELECT AN ACCOUNT", the user will get a table of available ACCOUNTs to make further selections. On the other hand, if it is desired to perform the analysis-needed, the user selects "ASSESS NEEDS" and performs the processing shown in fig. 11C. In the particular embodiment shown in FIG. 11A, a default selection of "CITIBANK ACCOUNT" may also be selected.

FIG. 11C illustrates an example of the present invention requiring a valuation account opening process. As shown, after the user decides access needs, they are provided with a menu that allows them to select "CREDIT", "FINANFIAL GOALS", "PERSONAL" or a special area by default "FINANCIAL PICTURE". Upon selection of this point, the user is prompted to provide information regarding the particular region selected or, in the case of "FINANCIAL PICTURE," information relating to a different region. This process continues until the required valuation is completed.

Fig. 11B illustrates a process for providing product information. As shown, this system allows a user to provide information relating to a particular area of the customer. The process may repeat until all questions have been answered. At this time, the user may select the processing of the personal document component.

Furthermore, flexibility is an important aspect of the system of the present invention. If the customer should not be asked to provide information at that time in his or her discretion, the user may choose not to provide certain information. Thus, no data entry will be required at that step, but if this step is bypassed, some logging must be done to enable data to be collected at a later time.

The information captured during the valuation needed step is ultimately stored in a customer document along with answers to the basic valuation needed questions. In this manner, other users (bank employees) of the bank will be able to access the account information wherever the customer contacts the bank.

As described previously, the system of the present invention includes an "pending file" (pending file) for storing information that has been collected but is not immediately needed. In particular, the system preferably includes some form of storage means from which it can be extracted. Furthermore, additional information obtained from the central database may be used legally and appropriately during this step.

The system may include a number of customer sales tools, including borrowability analysis using the data collected at this step. For example, the user will have the ability to display and print pricing information.

Other sales tools that are available include information relating to 24 hour access, financial announcements, exchange rates and services, etc. The system is flexible enough to get all of these tools while at the same time allowing the user to quickly bypass these entire sales tools. To implement the BPA pricing information and any other sales tools, the system includes a programmable general purpose computer and/or workstation.

Thus, when used in conjunction with the system of the present invention, a valuation step is required to capture and store customer information to identify existing and future customer needs. The information is preferably opened via allowed available and legitimate accounts. In addition, information collected during account opening is preferably provided via the central customer information system of the interface of the present invention and used to turn off clues; formulating the business volume of a customer to an individual banker; reporting the arrival of each day; tracking new account typical statistics, etc.; specifying work assignments and follow-up from pending files.

Account introduction system and procedure (600)

For new accounts, this step involves the introduction of various integrated accounts provided by the bank. The available ingredients and monthly prices are also preferably discussed. This step includes the interpretation of the new integrated account for the existing customer.

Additionally, a credit check is performed once the user has an explicit indication that the customer wants to open an account. Typically, the credit check involves two separate steps — an initial scan to see if the client is in a bad client table, such as a CHEX scan; second, credit agency reports are standardized.

To facilitate credit checking with external services or agents, the system preferably includes a modem or other communication device.

Typically, the system will perform both steps of the credit check simultaneously, and display the relevant responses on the same screen. However, in the event that one response is not available (i.e., due to a system problem), other responses may be displayed and not blocked until additional responses are available. The system has the flexibility to enter basic data related only to credit checks, i.e. such as name, address, social security number, birthday and citizenship, and optionally occupation, income and housing costs. If this identification data was not previously obtained, then this identification data must now be captured. For example, if the last credit check (which was stored) was made within the past 12 months, the system is flexible enough to decipher existing customers from this scanning process. In addition, the two steps of the credit check are performed separately and the system has the ability to give appropriate rights regardless of the initial scan results. If the user has the ability to obtain occupation, income, and housing information, the system will be able to return a particular loan amount whenever any product is part of a credit eligible offer. The credit eligibility amount (if any) will be displayed on the same screen as the credit check response.

If the customer has no limited liability, the system allows the user (typically through the authorization of the loan manager) to determine if the reason for it can override the account opened. If the account is open, the discard/invalidate event is captured and stored using the customer's demographic information. If the account is not open, an "advertisement type" notification showing the name and phone number of Chex and/or acquisition information must be printed at the department or customer bank telephone service center and provided to the customer's credit agency.

The result of the credit check and the need to assess is an account suggestion that the user relates to the components that will best serve the customer's needs. The system provides the user with a sales tool such as a screen or set of screens that will allow the user to clearly demonstrate how an all-in-one account, its components, and the customer can best access their account rights.

In addition, the system includes a programmable computer and appropriate input devices for prompting the user and collecting data to perform this step.

Personal document System and procedure (700)

Once the account selection/analysis required step is complete, the system proceeds to the personal documentation step. During this step, the user will collect any other personal information that has not been completed so far. Due to the flexibility of the system, the data collected here will vary according to the data previously collected. Furthermore, a computer with suitable input means is used for this purpose. A modem or other communication device is preferably provided to allow the computer to communicate with, for example, an external credit agency.

In some cases, this credit check will be performed in this step if it has not been performed previously. After the personal information, any professional information that has not been collected will be completed. There will be one screen for capturing personal information (each mr. on the account) and one screen for capturing professional information (still each mr.). The information included on the job screen would be the name and address of the current and previous employers, the time of the current and previous employers, and job selectors from the directory pickup list. If performed, a set of information for entering a professional verification method will be provided on this screen, and if entered, this set of information will be transmitted to the credit agency with the application, so that the verification does not have to be performed when reviewing credit decisions.

An account opening system according to the present invention will also enable a user to capture the customer's preferred language for later use and to capture enhancements such as inclusions in a magnetic stripe on a bank card, if for example the customer is a non-longlived foreigner, the customer will be flagged so that this fact and preferred language is displayed on the customer's documents relating to subsequent services.

A preferred embodiment of a system and method for performing personal document processing steps is shown in the flow chart of FIGS. 12A-12E. In addition, this process begins once the account selection/valuation required step is complete. As shown in fig. 12A, the process involves collecting identification and information such as account ownership, customer name, home address and phone number, citizenship, social security number, and birthday. The system includes a programmable general purpose computer and/or workstation with appropriate input means for carrying out this step. During this step, additional information, for example from a central database, is again legitimately and appropriately used.

As shown in FIG. 12A, the system generates and displays to the user an initial document screen showing the required data fields with any data that has been collected in the fields. Thus, for the purposes of the present invention, the customer no longer needs to provide this information.

After collecting the preliminary document data, the system determines whether a credit check has been performed in a previous step. If so, the system can move to the process flow shown in FIG. 12D to continue building the personal profile. If the credit has not been invoked, the system queries whether there are additional signatories on the account. If so, processing returns to the flow shown in FIG. 12A until the preliminary document data is collected for each additional signatory.

After the preliminary document data is collected for each signer, a determination is made as to whether to invoke a credit agency. If the credit agency is not invoked, processing may continue but no credit is provided. If a decision is made to invoke the credit agency, a quality check is made to determine if the data is complete. If not, an error message is generated and the user is allowed to continue with the pending document. If all the data is complete, then processing continues to the flow shown in FIG. 12C.

As shown in fig. 12C, this component of the process flow begins with a call to a credit agency. A programmable computer and a communication device such as a modem are used for this purpose. The system checks to see if the transmission of information to the credit agency. In the preferred embodiment, a two-step check is performed as discussed.

On the basis of the credit agency report results, a decision is made as to whether the account is approved. If the account is approved, process flow continues as shown in FIG. 12D. If an unapproved decision is made, credit report results and override capabilities are displayed on a screen to the user, bank employee. If the user chooses to override the rejection, processing continues as shown in FIG. 12D. On the other hand, if a negative decision is not overridden, the user is given an option to print a bad behavior report and the end of the transaction.

FIG. 12D illustrates the subsequent processing in the event that the customer's application for the account is approved. As shown, the process begins by prompting the user for vocational-related data. If the customer already has an employer for two years or has obtained information about a previous employer for less than two years, the system continues by prompting for information relating to work address, work phone, and revenue. If the user wishes to rely on an additional source of revenue, additional revenue data is collected. The process is repeated for each signatory in the account. Once data is collected for all signatories, processing continues as shown in FIG. 12E.

The process of creating a personal profile ends with the display of a document screen associated with the user ID. If there are more than two signators, the process repeats until all signators are displayed. Finally, a quality check is made to determine that the complete data has been received. If the complete data is not received, a message is generated and the user is allowed to continue using the pending file. If the complete data has been received, then processing continues to the next step, namely establishing an account.

Account setup product selection System and procedure (800) (including Credit determination (810))

Another particularly important aspect of the present invention is an apparatus and method for establishing an account. In particular, the present invention provides an intuitive interface that allows users and customers to view the account while it is being established. 18A-18C illustrate examples of visual displays used in the account setup process.

As shown in fig. 18A, the system displays account information on the subject of a bank report on a computer screen, i.e., displays a copy or description of the bank report. The use of the bank report topic in connection with the account establishment display is an important component of the present invention and is consistent with the underlying goal of having a consistent interface to the customer. This display shows the contents of the customer's bank report prior to the account being established. Core components such as inspection, deposit, IMMA, CD, retirement, commission, line credit, and credit card are included in the examples. Typically, the displayed report reflects a zero balance associated with each account. When other components are added to the account as described below, they will also appear on the displayed report.

To establish the account, the user selects (using an input device) one of the listed components. If, for example, the "check" component is selected, the system will display a check component setup screen as shown in FIG. 18B. The screen allows the user to select a particular component and to enter a quantity to be credited to the selected component. In the example shown, the user has selected a fixed exam component. The system also prompts the user to enter a quantity to be assigned to the exam component that has been selected.

If, for example, the customer selects the allocation $5000 for review, then the user enters this number and returns to the displayed report screen.

As shown in fig. 18C, the displayed report is updated to reflect a check balance of $ 5000.

In this manner, the customer and user can establish an integrated account for the customer specification and progressively view the account being established. In addition, the information is present in a bank report format consisting of all other customer access points for interfacing banks.

Once the bank account components that the customer wishes to establish are determined during the transaction, the user will select a function on the account opening screen. First, the user will select any product to be opened during the transaction. At this point, the system will automatically specify the component numbers for the liability components in the customer's bank account. The automatically assigned numbers may be disregarded when needed.

The user will then complete any necessary details such as the time frame, initial deposit, and exchange rate of interest. The user will then enter the account name and the special data required for any account (e.g., the signer number required if not a default). The preferred embodiment of the system for establishing an account is shown in figures 13A-13M. The system includes a programmable general purpose computer for performing these steps.

As shown in fig. 13A, the system begins the account setup process by displaying a report setup screen. Preferably, this display provides the user with an opportunity to select each component of the unified account. In the preferred embodiment shown, the user can select between twelve components. The amount (savings, credit) is displayed, for example, on the report setup screen shown in fig. 18A and 18C, as the ingredients are selected in the account and account setup.

Typically, the quantity associated with each component and the associated information relating to that component are provided by selecting a component and performing the processing associated with creating that component. However, in the preferred embodiment shown in FIG. 13A, the amount may be entered directly into a report setup screen for review, deposit, and if desired, secured money market accounts.

As shown in fig. 13A, the system always provides the user with a choice to return to the previous step, i.e. to create a personal document or move forward to the next step, i.e. the account service. In the absence of one of these selections, a component of the system shown in FIG. 13A operates in a closed loop state, whereby the customer selects a particular component and process via the prescribed process shown in FIGS. 13B-13M associated with that component, and then returns to the report setup screen, which is gradually updated to include the component at the time they were setup.

If the user selects to check the components, the system follows the path shown in FIG. 13B. In particular, the system displays an inspection component screen or screens. The user then enters the number to be assigned to the examination. The system then queries as to whether there is a different owner or a different address associated with the inspection component. If so, the system then enters a subroutine to obtain additional information relating to different signatories and/or address changes. Furthermore, an important aspect of the present invention is that the user initially has a screen for displaying all the salient information collected so far. Thus, even in the subroutine, only the customer and user are required to provide information that has not been previously obtained. Once the check component is established with respect to the customer specification relating to the owner and address. The system offers the possibility to build up other examination components. If the customer chooses to create an additional exam component, a message is displayed and the procedure is followed again. On the other hand, if the customer chooses not to create other exam components, then the system returns to the report creation screen shown in FIG. 13A and the user can select other components.

If the user selects a credit composition from the report setup screen, the system follows the path shown in FIG. 13C. The process for creating the credit composition shown in fig. 13C is substantially the same as the process for creating the check composition. In particular, as shown in fig. 13C, the user is prompted to enter an amount associated with the deposit component, and is then allowed to provide any additional information needed to account for the different owners or addresses. This is still achieved through the use of subroutines. Finally, the user is allowed to choose to set up another credit composition. When the credit composition satisfactory to the customer has been established, the system returns to the report establishment screen shown in fig. 13A.

When the user selects the Insurance Money Market Account (IMMA) component, the process follows the flow shown in fig. 13D. The process is still similar to the process for creating, checking and depositing components. The user enters the IMMA amount and is then given an opportunity to update information relating to the owner and address. Finally, the user is given an opportunity to set up another IMMA account and the process is repeated if desired. Once all IMMA components have been created, processing returns to the report creation screen shown in FIG. 13A.

If the user selects a security for which to deposit components, the system follows the flow shown in FIG. 13E. In particular, the securities of the deposit screen are displayed and the user then enters the deposited amount of securities. The system then prompts the user to enter a security for the deposit component including the term, the delivery scheme of interest, and the deposit instructions, etc. The process is repeated until all parameters are input. Once all parameters have been entered, the system allows the user to make decisions based on the authorized symbols associated with this component. This subroutine begins with the display of an authorized signatory based on previously collected data. The user may then add additional signatories. If the additional signatory to be added has already added the document, no further information is required. On the other hand, if the new signer is listed, the system marks the list of the new signer and the document will be needed later. Once the signatory is in line with the customer's wishes, the system allows the user to create additional CD components. If the user chooses to do so, then the process repeats. On the other hand, if the user chooses not to create other CD components, the system returns to the report creation screen shown in FIG. 13A.

If the system selects the IRA/401K component, the system follows the flow shown in FIG. 13F. The flow shown in FIG. 13F is a very high level consisting of only the variable selection display followed to perform the processing associated with establishing these selections. The process for establishing these selections, in accordance with the present invention, consists only of a series of processes for establishing inspection, credit, IMMA and CD components as shown in figures 13B-13E. Once the IRA/40K is established to the satisfaction of the customer and user, the system will return to the report setup screen.

If the user selects a privacy or brokerage component, the system may follow the flow illustrated in FIG. 13G. In particular, the system displays a secure work window that allows the user to enter a designated date and time or request a reply. The reason for this is that the information relating to the establishment of the security component must generally be processed by an authorized bank employee. If an appointment is made, the system will create a privacy confirmation message and the system returns to the report creation screen.

The system also includes a means for restricting access to certain authorized or licensed users to ensure compliance with applicable rules. For example, the information obtained in the "Brokerage" section would be "investment information" and any other information that may be specified to the Brokerage. According to this rule, "investment information" can only be discussed by individually authorized clients. Thus, access to these screens is limited to only those users who are permitted. The means for restricting access is preferably a programmable general purpose computer.

If the user selects a debit or loan component, such as check plus, the system follows the flow shown in FIG. 13H. In particular, an initial determination is made as to whether the loan is approved. If the loan is not approved, then the user will not be allowed to establish this component of the account. On the other hand, if the loan is approved, the system will display a check-plus-offer and selection screen that includes information relating to the amount of loan available. A customer passing through the user may accept the offered loan amount, request additional loans (where the system does not show the case of having to go into a separate process) to seek approval for the additional amount, choose to accept less than the offered loan, or decline the loan. The system then returns to the report setup screen shown in fig. 13A.

If the user chooses to create a non-secure loan component, the system follows the flow shown in FIG. 13I. In particular, an initial determination is made as to whether to approve the loan, which would not allow the user to create the unsecured credit card component if not approved. If the loan is approved, the system will display a non-confidential loan selection and loan rate. The system will then perform a non-secure loan component creation process. Once this process is complete, the system will return to the report setup screen.

If the user selects a secure loan component, the system will follow the flow shown in FIG. 13J. In particular, the system will display various security loan selections including security sources, fixed proportion home security loans, mortgages, best lines, best loans, security loans, and basing lending and student loan selections on security. The system may also display loan rates and other information. Once the selection is made, the system will perform the secured loan component creation process until all desired and available selections are created and then the system returns to the report creation screen shown in FIG. 13A.

For some special security loan products, there is additional information necessary to complete the application. If the credit agency does not indicate that the customer has "credit eligibility," this screen will not be displayed unless the customer makes a special request for a loan product. Included in this screen are information such as property information, housing costs, government monitoring/HMDA information, etc. Any information that is captured as part of the BPA will flow into any appropriate set of information on these screens.

Before credit information is transmitted to the credit agency for credit determination, the system will need to perform a quality check on the basis of the data that has been entered to ensure that all the required data is entered. If any messages are lost, the system will request the appropriate information. If the information is available, the user is given an opportunity to enter it; if this information is not available, the ability to place the application "pending" will be provided.

In accordance with the present invention, the credit decision screen is accessible in an account opening process to remove the need for the account to open transactions beyond and into other systems.

The user is able to complete any loan activity necessary on the series of screens during the verification and account opening process. Verification done on one loan product will flow to any other loan product in the transaction. Various factors such as line size and product type determine the verification that is performed; the verification performed will update all products that the customer has applied for.

If the user selects one of the credit card selections, the system follows the flow shown in FIGS. 13K-13M. The system flows shown in fig. 13K and 13L are the same and the differences depend on the differences between the ordinary and gold cards provided by a particular bank. The basic process involved is an initial decision of whether or not the loan followed by the information screen relating to a particular card is approved, and then the user enters the information required for the card including card type, line of credit, credit card holder, add-on card, name and light card, etc. The credit limit determination is then made and the system returns to the report setup screen.

If the user selects another card offered by the bank, a similar procedure is followed except that when the customer selects a particular type of credit card, the customer and the user are given a choice to choose to transfer the existing bank credit line to this account or, conversely, to transfer another credit line to a bank credit card. After this process is completed, the system returns to the report setup screen shown in fig. 13A.

This portion of the process will be used to ensure that the customer is familiar with the various services available. At the same time, a programmable general purpose computer is believed to be the most suitable means for performing this step.

These screens will have another opportunity to see how the customers use the banks to manage their money and achieve benefits that deepen their relationship with the consuming banks. If appropriate, the screen will need to combine the data records with the product/service characteristics observed by the customer.

A preferred embodiment of a system for performing the account service steps is shown in fig. 14A-14G.

As shown in FIG. 14A, the system begins by reviewing previously collected data to see if the customer is already able to check for service in an overdraft protection scenario. If so, a flag is set and the system continues. If not, the system continues without setting the flag. The system then determines whether more than one service is activated in the account selection need process. If so, a flag is set to cause the selected service button on the Citibank account services screen to display highlight and display the account services screen. The system then continues with the flow shown in fig. 14B. At the same time, the user may choose to set up a service or to give information related to said service. If the user chooses not to set up a service or to give information about a service, the user is given an opportunity to note the customer's interest in one or more additional services. If the user indicates an interest in one or more additional services, the system takes care of the need to track and proceed with printing the registry.

If the user indicates a desire to set up a service and get information, it is clear that the flow associated with the particular service is proceeding. Naturally, banks can provide various services. However, in the preferred embodiment shown in FIG. 14B, the system is capable of providing information or establishing automatic transfers, bill delivery services, direct deposit, direct access to deposited funds, automatic dividend deposit, confidential lending, overdraft coverage, automatic payment, and electronic payment.

If the user chooses to set up the automatic transfer, the system follows the flow shown in FIGS. 14C and 14D. In this process, the system allows the user to set up an automatic transmission and a transmission that occurs again using the process shown in FIG. 14D.

If the user chooses to create or present information related to the bill delivery service, the system follows the flow shown in FIG. 14E. As shown, the user is allowed to establish a standard payee and a specific payee. If the user chooses to establish direct deposit or direct access to the deposited funds, the system will follow the flow shown in FIG. 14F. If the user chooses to set up the auto-pay, the system follows the flow shown in FIG. 14G. As shown in this figure, the system allows the user to establish a variety of delivery methods for credits and credit lines and to select the frequency of such deliveries.

In each case, after the completion of the specific process related to any one of the services selected, the system returns to the flow shown in fig. 14A and 14B. The system then performs an access step whereby the various access points are made available to the customer.

Here, a bank card Personal Identification Code (PIC) is selected. Telephone banking will be discussed and TPIC (telephone personal identification number) will be selected. If applicable, a check will be made.

The system allows a user (a personal banker or a telephone representative) to register a customer with a remote access service. A programmable general purpose computer may again be used for this purpose.

The system may provide for automatic registration and capture of the customer's PC-type records and floppy disk size (if needed) in home banking. The components that are issued and linked to the bank card will be automatically linked for home banking. The system will also allow the use of screen phones.

A preferred embodiment of a system for performing the accessing step of the present invention is shown in fig. 16A-16F. As shown in fig. 16A, the process starts with accessing a screen display. The user is then given an opportunity to revise or accept a recorded account name. The subroutine for this process is shown in fig. 16D.

The system then proceeds to a Personal Identification Number (PIN) entry routine shown in fig. 16D. If the account is a federated account, a name receiving routine and a personal identification entry routine are executed for a second name in the account. The system can then be decorated and issued to customer bank cards. This step may also be postponed. To facilitate decoration, the system preferably includes a conventional decoration mechanism linked to a general purpose computer. If the decoration is unsuccessful, the system will perform an error screen process, but allow the entire process to continue.

Flow continues as described in fig. 16B. In particular, the system allows for the selection of a verified phone identification code. Processing is undertaken for any joint signer and then processing continues as shown in fig. 16C. Here, the customer is given an option to remotely access the bank using a PC. If the user accepts the service, a determination is made as to whether the client knows all of his or her computer parameters. If so, relevant parameters such as computer type, floppy disk size, modem type, and modem speed are input to the system. If the customer does not know one or more of these parameters, the business displays and stores the information about the tracking that will be needed for use in the tracking step. The system then proceeds to the process shown in fig. 16E. At this point, the customer is given a choice to access the bank using the screen phone and the system makes an explanation of the customer's choice and proceeds with the process shown in FIG. 16F. Here, the client is allowed to schedule the examination. The system starts to change the personalization flag by displaying a default check command and giving the user an opportunity. This relates to information such as name, address, billing information, and mailing address. The user is then given an opportunity to customize the default command, and the user then has an opportunity to schedule the examination. Processing then proceeds to a special instruction step or to perform the processing of the outcome shown in fig. 17A and 17B.

Special instruction system and procedure (1000)

This processing step is used to collect any remaining data and process any special account status that has not been processed in the account opening process. This would include such things as: the "best time to call", or "not to contact" indicia, not to share data with other devices, a "mailing address", a "best postal greeting", and the like. The system can also participate in checkout in other institutions. The system may include a printer and a computer that will generate prints of collected correspondence to be transmitted to other institutions. By communicating the "Power of Attribute" status to the account, the system can also accommodate the appointed Power letter, eliminating the need for second day file saving. The user may also establish a meeting with the investment advisor or establish a meeting with the mortgage advisor if the user is not licensed. Client requests associated with any of the changes may be accommodated.

A preferred embodiment for establishing the process is shown in fig. 17A-17B. The system begins by displaying the information needed to close and authenticate the various accounts. In addition, the system again allows data flow up or down, so that only information that has not been previously provided is called in this step. The system also provides an opportunity to display information about how to contact the customer and allows the opportunity to display multiple appointments. Finally, the system indicates the remainder of the items needed to complete the opening of a single, fully integrated account.

Printing/delivery system and procedure (1100)

After the establishing step is completed by obtaining all the information, the system performs a step of printing the registration package.

The print function will produce any necessary paper work that the customer needs to sign and that any entity/individual cannot communicate electronically with the relational banking system. This should include, for example, mortgage and landmark work assignments, tax free applications, premium account applications, brokerage applications, confidential investment validation, collecting letters, signature cards, notification of adverse behavior, instant credit certificate bulletins, insurance formats, bankbooks, and the like. To accommodate these steps, the system includes a printer connected to a general purpose computer.

The customer will be required to view all crisis demographic information about themselves, such as name, address, occupation, phone number, etc. This registration report will show the accounts opened in the transactions settled on the date of the opening. For the customer bank account, account number, unlimited savings, exchange rate and term will be displayed in the relevant portion of the report.

The main difference between the department and the customer banking telephone service center is that the customer does not actually sign or take a hand-off for any documents. This means that the customer bank telephone service center fulfillment area will have to mail documents to the customer.

The preferred embodiment of the process for printing a registered form is shown in FIG. 15. As shown, the system first confirms that the printer has been activated. If the printer is not started, the system cannot process until the printer is powered on. The system then instructs the printer to print the registration form and confirms whether the printing was successful. If the printing is unsuccessful, the process cannot proceed forward and if the cause of the unsuccessful printing is identified, the process will typically be repeated. After confirming that the registration form was successfully printed, the customer is required to sign on the print form. If the customer is not signed on the registry at a time, such as when a transaction is being made using telephone, the application is retained in an undetermined file.

Transaction summary (tracking) system and steps (1200)

Finally, the system enters a transaction summary. All appropriate documents must be signed by the customer. If the job is approved, the account opening information will have to be passed to Tax evasion shelters (Tax shelter) or mortgage consultants. The request is for work distribution on schedule rather than via paper copy.

If the tracked transactions are established for the customer, the user will have an option to print a meeting reminder to the customer. This order will include the date and time of the meeting (if available), the purpose of the meeting (e.g., entered by the user via free form input from the data entry field), and the name of the client banker with which the client is to meet. If a particular meeting date/time cannot be set, a client banker will be designated to contact the client. This leaflet should include the customer's name and mailing address so that if the account is opened via telephone processing, it can be placed in a windowed envelope for mailing to the customer.

After the customer leaves, the user can enter a free form notification from the basic need for valuation; extracting and viewing detailed assessment-required answers and updating the answers as needed; basic and detailed rating information is transmitted.

Pending document

During the account opening process, the ability to place the transaction pending may be obtained. The primary place in the flow that often causes pending processing is before transmission to the credit agency (if the SSN is not available) or after quality control checks and the required information is marked as missing information. The customer also requires departure, as it will result in a time limit that is pending at any point. The customer may also simply go through the valuation required and to return to continue the application process at a later date. The system makes it possible to transfer a part of the transaction, such as a commission, and the remaining components, such as customer banking.

When an existing client is profiled in the greeting function, that fact is noted in the document if there is any transaction pending (sessions pending) associated with that account. If the user (greeting) does not document the customer, he can still push any pending applications via pending functions. The undefined items have multiple ways to be accessed, including by customer name, by user ID, by department, and by product.

An pending application is provided to the user in the account opening screen flow. The user is also allowed to perform quality control checks to enable the system to identify missing items that are needed before transmission to the host.

The customer will have a choice to enter their selected department to complete the account opening. The department staff should also have access to these pending applications. The workstation screen should also be able to mark pending customer representatives as they enter the "identify customers" screen.

Thus, with the integrated account and account opening system of the present invention, all components of the customer's bank account will be provided. The process is flexible enough to support customers who only want one component of all of these interesting offerings. Once customer data is entered into the system, the customer will never repeat the same information to any bank employee. During account opening transactions, information will flow between bank employees (users) without gaps to improve customer experience. Existing customer data is readily available at all customer contact points that are legally restricted based on data sharing that may exist. This capability will be provided to issue the bank card to all customers even if the only component activated is a bank deposit passbook or certificate. The bank card is used as a customer identifier on the phone at the cashier window or telephone service center and will be available for connecting new components when they are activated.

The result is that the customer will utilize multiple unified account components. This will increase revenue and improve customer satisfaction, maximize the time available for sale associated with the department staff and provide a telephone service center with identification capabilities for the department.

By linking the account opening system to a central database, the information in the database can be used to facilitate account opening and the information collected during the account opening process can be supplied to the central database of the present invention for home, customer and account level information. Thus, the present invention allows a user to query the central database of the present invention for a variety of information at a customer level that would otherwise not be available. This information includes: the service that the customer has signed during the account opening process (direct access, bill delivery, ATM, etc.) registers and sales tools for each customer with the type of tool and data used. In this context, the types of sales tools that may be used include borrowing ability valuation, demand valuation, and demand valuation subcomponents. Other information collected may include: detail data elements gathered during the loan ability assessment or the need assessment; a customer source; the source of funds used at the time the account was opened and the charge abandonment information including type, reason for charge abandonment, date, personal ID or report on abandonment made, etc.

As described above, the workstation of the present invention utilizes the central database of the present invention to provide information for online viewing and reporting of the generation by the customer selecting or matching accounts with given criteria and generating multiple lists matching the selected data elements. If it follows this, additional data can be obtained on multiple workstations by linking the account opening system to a central database. In particular, the following data elements used in the selection among other additional data are available on the workstation of the present invention and appear in the list of selected accounts or customers: assessing the borrowing capacity; requiring valuation; detail data elements gathered during the loan ability assessment or the need assessment; service registration for customer signatures during account opening processes (direct access, bill delivery, ATM, etc.); a customer source defined from the pick-up table at the account opening; and a source of funds defined at the account opening in accordance with the picklist.

It will be apparent that the invention is not limited to the specific constructions described above and illustrated in the drawings, but that many modifications and variations are possible without departing from the spirit of the invention. The scope of the invention is only limited by the appended claims.

Claims (18)

1. An integrated sales processing support system comprising:

a central database;

means for inputting data from a plurality of sources to the central database;

means for retrieving the database in response to the composed query and identifying records matching the query;

at least one micro-marketing center having a plurality of user workstations;

means for building said composed queries of said database in response to standard user selections from a user workstation graphical user interface;

a plurality of geographically separated departmental systems, each departmental system comprising at least one departmental workstation;

a central customer information system geographically separated from but linked to electrically communicate with a workstation at the departmental system.

2. The system of claim 1, wherein said system includes an account opening system including means for creating personal profiles including means for collecting salient data and means for allowing data collected at any step of said process to flow to all other points where it is needed so that data is not entered more than once.

3. The system of claim 1, further comprising a means for tracking customer arrivals at departmental offices; and wherein said system further comprises a means for tracking and reporting information related to the arrival of new and existing customers through the sales process, the information comprising the following: incoming type, wait time, sales transaction time, average transaction time, use of sales instruments, product type, price per product (dollar), customer name and address, product type, purpose of visit, and sales representative ID.

4. The system of claim 1, further comprising a means for notifying the micro marketing center of promotional concepts; a means at the micro-marketing center for collecting a plurality of clues based on the promotional concept; means for providing the cue to the departmental system the evening of the previous day; and a means for automatically loading the cue into the system to provide the cue to the departmental system the evening of the previous day.

5. The system of claim 1, further comprising a graphical user interface that allows the micro-marketing center to generate documents containing mailing addresses and to transmit the documents to geographically separate departmental systems.

6. An electronic sales and services support system for a financial institution, comprising:

a central database containing information about the family, customer and financial institution accounts;

a micro-marketing center having at least one user workstation for communicating with said central database, said user workstation having an input device for inputting selection criteria to specify a selected set of customers targeted for a sales campaign; and

a central customer information system having a plurality of departmental workstations in electrical communication with said micro-marketing center and said central database, each of said departmental workstations having a display device for selectively displaying customer documents including customer relationships with financial institutions;

means for notifying a micro-marketing center of promotional concepts;

means, disposed at said micro-marketing center, for generating a plurality of clues based on said promotional concept;

means for providing the lead to the departmental workstation the evening prior to;

means for automatically loading the lead into a system to provide the lead to a departmental workstation the evening before.

7. The electronic sales and services support system according to claim 6, wherein said central database comprises:

a central database;

means for inputting data from a plurality of sources to the central database; and

means for standardizing and familiarizing data entered in a central database into multiple organizational levels including family, customer, and account levels.

8. The electronic sales and services support system according to claim 7, further comprising a means for retrieving said database in response to a composed query and identifying records matching said query; and

means for establishing the composed query at the micro-marketing center in response to a user criteria selection from a user workstation graphical user interface.

9. The system of claim 6, wherein said system further comprises an account opening system comprising a means for creating personal profiles, the means comprising a means for collecting salient data and a means for allowing data collected at any step of said process to flow to all other points where the data is needed so that the data need not be entered more than once.

10. The system of claim 6, wherein said system further comprises a means for tracking customer arrivals at a department office, and wherein said system further comprises a means for tracking and reporting information related to new and existing customer arrivals through a sales process to said department, said information comprising the following: type of arrival, wait time, time of sale transaction, average transaction time, use of sales tool, product type, price per product (dollar), customer name and address, product type, purpose of visit, and sales representative ID.

11. An integrated sales processing support system comprising:

a central database;

means for inputting data from a plurality of sources to the central database;

means for normalizing input data in the central database to a plurality of organizational levels;

a plurality of user workstations geographically remote from the central database, each of said user workstations comprising a database and a display device, said workstations comprising a search engine for generating a graphical user interface to allow a user to select search criteria blocks to graphically build a graphically composed search query, said graphical user interface comprising up-down windows, images, and drag-and-drop operations;

a plurality of departmental workstations connected to each user workstation using communication means, and a means for transmitting data from said user workstations to the plurality of departmental workstations;

a central customer information system geographically separated from the departmental workstation but linked to electrically communicate with the workstation;

means for converting a graphical search query into a text query, the text query including necessary code and a required grammar to ensure that the text query can be run;

means for allowing data communication between the user workstation and the central database;

means for retrieving said database in response to a composed query accepted from one of a plurality of user workstations and identifying records matching said query; and

means for downloading data to the user workstation relating to records matching the query.

12. The system of claim 11, wherein said central customer information system comprises a plurality of customer documents, each customer document including demographic information and customer financial information, said customer financial information including credit information and financial objectives; means for performing a necessary analysis on the basis of information contained in the central customer information system, recommending accounts on the basis of the necessary analysis and presenting information relating to the selected account components to the user; and means for allowing communication between said central customer information system and said central database.

13. The system of claim 11, wherein said central customer information system is geographically remotely located from said central database.

14. The system of claim 11, wherein said system further comprises a means for tracking customer arrivals at a department office, and wherein said system further comprises a means for tracking and reporting information regarding new and existing customer arrivals through a sales process to said department, said information comprising the following: arrival type, wait time, sales transaction time, average transaction time, use of sales instruments, product type, price per product type (dollar), customer name and address, product type, purpose of visit, and sales representative ID.

15. A process for identifying sales targets, distributing sales leads, and enhancing marketing sales tools for use in conjunction with a system comprising a central database, a means for inputting data from a plurality of sources into the central database, a means for retrieving the database in response to a composed query and identifying records matching the query; at least one micro-marketing center having a plurality of user workstations in electrical communication with the central database; a plurality of geographically separated departmental systems, each departmental system comprising at least one departmental workstation; and a central customer information system geographically separated from but linked to electrically communicate with a workstation at the departmental system, the process comprising the steps of:

inputting data from a plurality of sources to the central database; standardizing and housekeeping the input data into a plurality of organizational levels within the central database;

notifying the micro-marketing center of promotional concepts;

generating a plurality of clues based on said promotional concept by inputting criteria into a user interface of said user workstation, for defining tables of customers targeted during the sales event, building a composed query in response to selected criteria and using said composed query to retrieve a central database, identifying records in said central database that match said selected criteria, and generating tables of customers targeted during the sales event;

electrically assigning the customer meter to the department workstation.

16. The process of claim 15 further comprising the step of displaying a document relating to customer information from said customer table on said departmental workstation during a sales transaction with said customer during a sales activity.

17. The process of claim 15 further comprising the step of using a graphical user interface that allows the micro-marketing center to generate documents containing mailing addresses and to transmit the documents to geographically separate departmental systems.

18. The process of claim 15, further comprising the step of tracking customer arrivals at a department office and tracking and reporting information about new and existing customers undergoing said sales process at said department office, said information comprising the following information: incoming type, wait time, sales transaction time, average transaction time, use of sales tools, product type, price per product type (dollar), name and address of the customer, product type, purpose of visit, and sales representative ID.