WO2002031733A1

WO2002031733A1 - Systems and methods for the creation and management of solicitations

Info

Publication number: WO2002031733A1
Application number: PCT/US2001/031552
Authority: WO
Inventors: Samuel Harvey Baker, Iv; Bradford Ray Swiger
Original assignee: Capital One Financial Corporation
Priority date: 2000-10-13
Filing date: 2001-10-11
Publication date: 2002-04-18
Also published as: EP1334455A1; AU2002213074A1; EP1334455A4

Abstract

A solicitation management system is provided including a solicitation management processor. The solicitation management processor is configured to define a rules base for the solicitation that is directed to members of a pre-defined population, and to send the solicitation to the members. Also included in this system is an applications processor. The applications processor is configured to receive a response to the solicitation from a respondent comprising a member of the pre-defined population. The response is further configured to include an identification tag identifying the rules base associated with the solicitation. In addition, the applications processor identifies the rules base to the solicitation management processor by the identification tag and receives the rules associated with the rules base from the solicitation management processor. The solicitation management processor may be further configured to first determine a plurality of desired requirement for the solicitation, each corresponding to a rule within the rules base. The solicitation management processor may be further configured to identify previous solicitations that have at least one requirement matching a desired requirement, and to copy into the rules base any rules corresponding to a matching requirement. And finally, the solicitation management processor may be further configured to create new rules for desired requirements which were not identified in a previous solicitation.

Description

"SYSTEMS AND METHODS FOR THE CREATION AND MANAGEMENT OF SOLICITATIONS"

DESCRIPTION OF THE INVENTION

Technical Field

The present invention relates generally to systems and methods for creating and managing solicitations. More particularly, the present invention relates to systems and methods for creating and managing solicitations by using rules of previous solicitations that are common to those of the new solicitation.

Background of the Invention

Financial institutions, including those offering credit card accounts or financial loans, market their products and services in a number of different ways, such as through the use of solicitations. For example, an institution will identify a select group of recipients, and then send a solicitation to each recipient asking whether the recipient is interested in a particular product or service. As stated previously, with a financial institution, the product or service which is the focus of the solicitation is often a credit card account or a financial loan.

In designing a particular solicitation, the first step is to determine a specific market to which the solicitation is to be directed. By narrowing the scope of the market according to specific needs and desires of the recipients, a solicitation can be designed which will have a higher probability of effectiveness. For instance, a generic campaign geared to all members of the general public may appear bland and not catch the attention of the recipient. However, if information about the recipient can be obtained prior to sending the solicitation, then the solicitation can be tailored to make it more appealing to that recipient.

For example, a financial institution may determine that it wants to solicit a group of individuals who have never had credit before. If the solicitation effectively takes this factor into account, then the probability of receiving responses to this solicitation may be higher. As another example, a solicitation may be sent to members of a university alumni association. By including a credit card embossed with the school's mascot, the probability of receiving responses is likely to be higher than if a generic credit card was sent.

As seen in the aforementioned examples, solicitations geared toward the wants, needs, and desires of a particular recipient group will enhance the probability of receiving a response from the solicitation. More particularly, the , more detailed the solicitation, the higher the probability of receiving a response. However, while using a variety of different solicitations increases the likelihood of receiving a response, it also increases the complexity in preparing and managing the solicitations.

One solution to the solicitation management problem is to use an applications processor comprising a rules engine to create and process each solicitation. Each rule defines a particular feature of the product or service offered by the solicitation, and is used when creating the solicitation. The applications processor encodes each rule of each solicitation and automatically creates the solicitation. However, encoding every rule for every solicitation each time a solicitation is created is extremely time consuming and burdensome. Thus, there remains a need in the art for a management tool that allows a user to easily create and manage a large number of solicitations having a variety of features.

Summary of the Invention

Systems and methods consistent with the present invention allow users to efficiently create and manage a variety of different solicitations by using rules of previous solicitations that are common to those of the new solicitation being created.

In accordance with one aspect of the present invention, a system and method is provided for managing a solicitation directed to a member of a predefined population. The system and method determines a rules base for the solicitation, wherein the rules base defines particular features of said solicitation. The system then sends the solicitation to the member and receives a response to the solicitation from the member. Finally, the system analyzes the response in accordance with the rules base to determine whether to make an offer to the member.

Both the foregoing general description and the following detailed description are exemplary and are intended to provide further explanation of the invention as claimed.

Brief Description Of The Drawings

The accompanying drawings provide a further understanding of the invention and, together with the detailed description, explain the principles of the invention. In the drawings:

FIG. 1 is a functional block diagram of a solicitation management system consistent with the present invention;

FIG. 2 is a flow chart of a solicitation management method consistent with the present invention;

FIG. 3 is a flow chart of a method, used in the method of FIG. 2, for defining solicitation and the market to which it will be directed;

FIG. 4 is a flow chart of a method, used in the method of FIG. 3, for creating a solicitation;

FIG. 5 is a flow chart of a method, used in the method of FIG. 4, for creating new rules for a new solicitation; and

FIGs. 6 and 7 are screen shots of a graphical user interface of a solicitation management system consistent with the present invention.

Detailed Description Overview

Systems and methods consistent with the present invention create and manage solicitations, such as credit card solicitations sent by a financial institution. For each newly created solicitation, the system creates a new set of rules by automatically identifying and copying rules from previously prepared solicitations that have rules identical to those of the new solicitation. In this way, the system creates a rules base for the new solicitation. The rules base defines the format and content of the new solicitation and defines a process used when analyzing a response to that solicitation. Further, when creating the rules base, the system uses a graphical user interface (GUI) to identify the previously stored rules. The system also indexes the stored rules according to their function, allowing a user to easily locate and copy rules from past solicitations to be used in future solicitations. The system then uses the rules base to create the solicitation and to manage the sending and processing of responses to the solicitation as well. System Organization

Embodiments of the present invention will now be described with reference to the accompanying drawings, in which like numerals indicate like elements throughout the figures.

FIG. 1 shows a block diagram of a solicitation management system 100 consistent with the present invention. Solicitation management system 100 includes an applications processor 110, a solicitation management processor 120, and a rules database 130. Further, solicitation management system 100 may be implemented using any type of computer, such as a hand-held device, a minicomputer, a personal computer, a mainframe computer, or the like. System 100 may also use a distributed computer network, where tasks are performed at remote locations.

System 100 may send the solicitation and receive responses to the solicitation using either regular mail, e-mail, facsimile, the internet, or an interactive voice response system. An interactive voice response system (IVR) is an automated telephone answering system that responds with a voice menu and allows the user to make choices and enter information via the keypad. IVR systems are widely used in call centers and also as a replacement for human switchboard operators. Finally, the system 100 may send the solicitation using out bound telemarketing or media such as newspapers or television. The system 100 may also integrate database access and fax response.

The applications processor 110 is a rules engine that performs decisioning and limit logic to process solicitations. In particular, the applications processor 110 receives responses to the solicitation from recipients to which it was sent. Upon receiving a response, processor 110 identifies an identification tag, included in the response and which identifies a rules base associated with the particular solicitation. Through the use of the solicitation management processor 120, the applications processor 110 then uses the identification tag to locate the corresponding rules base stored in rules database 130 and then analyzes the response in accordance with the rules base. The applications processor 110 preferably receives rules associated with the rules base in the form of a plurality of tables.

The solicitation management processor 120 manages the code processed by the applications processor 110 by using rules of previously prepared solicitations. The solicitation management processor 120, uses a GUI to define the decisioning and limit logic that is contained and carried out in the applications processor 110. Through the use of the GUI, the solicitation management processor 120 defines a rules base that defines particular features of a corresponding solicitation. The GUI incorporates drag and drop features, icons, and pull-down menus, and preferably uses a mouse. The GUI may either be a Windows, Macintosh, or Motif GUI, and, in a client/server environment, preferably resides on the client terminal.

The drag and drop feature of the GUI allows the user to perform operations by moving the icon of an object with the mouse into another window or onto another icon. For example, the GUI can copy or move files when they are dragged from one folder to another. Similarly, the GUI can execute programs by dragging and dropping. To print a document, an icon of the document is dragged to overlay the icon for the printer. Drag and drop is essential for graphics applications where one needs to position text and images on the page or on top of each other. Although drag and drop options can be used for copying and moving files, these operations- can also be done in other ways, such as by using the pull-down menus.

The rules database 130 stores all data and programming modules of the solicitation management system 100. For example, rules database 130 stores the solicitations previously sent, along with the rules base associated with each solicitation. Each rules base contains an indexed set of rules, with each defining particular features of the corresponding solicitation. In addition, the rules database 130 contains the names, addresses, and other data submitted by recipients, as well as determinations of whether to offer an account to the recipient. System Operation

FIG. 2 is a flow chart of a solicitation management method 200 consistent with the present invention. FIGS. 3, 4, and 5 further describe particular steps of method 200.

Method 200 begins by defining solicitation and the market for the solicitation (steps 205 and 210). The market for the solicitation is basically a pre-defined population of recipients to which the product or service offered by the solicitation is to be marketed. Step 210 is described in greater detail below in reference to FIG. 3. After the system 100 creates the solicitation, the solicitation is then sent to each member of the pre-defined population (step 215). An ID tag of the rules base associated with the solicitation also accompanies the sent solicitation. As described in greater detail below, the ID tag is an index that identifies the solicitation and its corresponding rules base.

Individual recipients of the solicitation then determine whether to respond to the solicitation (step 220). Recipients of the solicitation who decide to respond will provide information requested by the solicitation, and then return that information in the form of a response (step 225). For example, the response may include whether the recipient desires the offered product or sen/ice, as well as the recipient's name and address, phone number, social security number, employer, annual income, and the like. The response also includes the ID tag indicating the rules base associated with the solicitation. After the response is received (step 230), the information of the response is then forwarded to the applications processor 110 (step 235).

The applications processor 110 then obtains the rules base associated with the solicitation from the solicitation management processor 120 (step 240). In particular, the applications processor 110 passes the ID tag indicating the rules base associated with the solicitation to the solicitation management processor 120. The solicitation management processor 120 then, queries the rules database 130 with the ID tag for the proper rules base corresponding to the received solicitation. After the proper rules base has been located, the solicitation management processor 120 sends the rules base, preferably in a table format, to the applications processor 110. With the data and the proper rules base now loaded, the applications processor 110 may analyze the data of the received response.

The applications processor 110 analyzes the response based on the particular rules contained in the rules base (step 245). When the solicitation offers a financial product or service, this analysis may determine the credit worthiness of the recipient or the type of service features to offer the recipient. Rules used in this analysis may include a rule defining that incorrect information in the response (e.g., an invalid Social Security Number), determined by comparing the information of the response with data from a commercially available database, indicates a high level of risk in offering the product or service. A rule may also instruct processor 110 to use the recipient's credit history to determine the credit limit on an offered credit card. Those skilled in the art will appreciate that many other rules may be used to analyze the response.

Finally, system 100 then determines whether to make an offer based upon the analysis outcome (step 250). This determination can be automatically performed or can be accomplished by user intervention. A hybrid process can also be implemented, such as by allowing the applications processor 110 to make the determination for a first outcome of the analysis and require user intervention for a second outcome. Once the analysis is complete, method 200 ends (step 255).

FIG. 3 is a flow chart of a method consistent with the present invention for implementing step 210 of FIG. 2. The method begins by defining the population of recipients to which the solicitation will be marketed. For example, system 100 may determine that the market group is sports fans who are interested in a high credit limit and who are not concerned with transferring a balance to a new credit card. The market group could also be higher credit risk individuals who wish to transfer balances from a higher interest rate account to a lower interest rate account.

Once the market population is defined, system 100 then defines a set of requirements for creating the solicitation (step 315). A requirement is a particular concept encoded into and realized by a rule. Thus, like a rule, a requirement defines a feature of the solicitation used to entice members of the defined population to respond to the solicitation. Given the sports fan example, a database of names and address could be purchased from a university alumni association or a sports magazine publisher. A requirement in this example could be to offer a particular team logo placed on the credit card. In addition, a requirement may define a certain credit bureau report to be used when determining whether to offer the particular product or service. Those skilled in the art will appreciate that many other requirement may be defined when creating the solicitation. Once the requirements are defined, the solicitation management processor 120 then creates the new solicitation based on the defined requirements (step 320). After completing step 320, processing returns to step 215 of FIG. 2 (step 325).

FIG. 4 is a flow diagram of the method performed by step 320 of FIG. 3. As shown in FIG. 4, the method determines first whether a previous solicitation exists with requirements that match the requirements of the new solicitation (steps 405 and 410). If a previous solicitation already exists with the same requirements as those of the new solicitation, then the new solicitation is associated with the ID tag of the rules base of the matching previous solicitation (step 415). From step 415, processing continues to step 430, where the subroutine returns to step 325 of FIG. 3.

If, however, step 410 determines that there is no previous solicitation with matching requirements, then a new rules base is created corresponding to the requirements defined for the new solicitation (step 420). In such a case, each requirement is encoded into a rule using the solicitation management processor 120. System 100 then assembles a rules base corresponding to the solicitation using the rules encoded from the requirements of the solicitation. The rules base is then stored in database 130 and an ID tag of the rules base is associated with the new solicitation (step 425). Processing then returns to step 325 of FIG. 3 (step 430).

FIG. 5 is a flow diagram of a method for implementing step 420 of FIG. 4. As shown in FIG. 5, the method begins by determining if any previous solicitations exist that have at least one requirement that matches at least one requirement of the new solicitation (steps 505 and 510). If none exist, then system 100 creates a new rules base with new rules corresponding to all the desired requirements (step 515) and processing returns to step 420 of FIG. 4 (step 530).

Figs. 6 and 7 show screen shots of GUIs, used for creating a new rules base, of the solicitation management system 100. FIG. 6 shows a window 605 that lists various rule types that can be included in a given rules base. For example, item 610 refers to a rule type called BUREAUSELECT. A user may highlight this rule type if the user desires a requirement that the product or service offered by the solicitation use a certain credit bureau. Upon highlighting this rule type, system 100 will then allow the user to further define the rule, as described in more detail below. Once the rule is fully defined, system 100 then encodes this requirement into a rule to be included in the rules base for the solicitation currently being created.

After the user selects a desired rule type, the user moves to the screen shown in FIG. 7. In FIG. 7, item 710 indicates the name of the rules base selected by the user, item 715 indicates the ID tag associated with the rules base, and window 720 lists the rule types selected for the new rules base. As shown in FIG. 7, item 725 refers to the rule type BUREAUSELECT selected in FIG. 6. Other GUI screens of system 100 allow the user to further define the selected rule types. For example, for the BUREAUSELECT rule type, a user may specify the particular credit reporting bureau or the type of data required from the credit reporting bureau. Once this information is provided, system 100 encodes the rule type into a rule.

Referring back to FIG. 5, if system 100 determines in step 510 that there is a previously prepared solicitation having a requirement matching one of those of the new solicitation, then each matched requirement is copied into the new rules base (step 520). Preferably, the system 100 identifies the rule to be copied, and then the user drags and drops the rule into the new rules base. For those requirements that were not found in any previous solicitation, system 100 then creates rules in the rule base for those requirements (step 525). To do so, the process for creating a rule described above with reference to step 515 and FIGs. 6 and 7 is used. From step 525, processing then returns to step 420 of FIG. 4 (step 530). Conclusion

Systems and methods consistent with the present invention provide a method and system for creating and managing solicitations. Such systems and methods consistent with the present invention can manage any type of solicitation. Further, the present invention can be implemented in a distributed network or reside on a stand-alone computer.

The foregoing description of preferred embodiments of the present invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, the described implementation includes software and hardware, but elements of the present invention may be implemented as a combination of hardware and software, in software alone, or in hardware alone. Further, the invention may be implemented with both object-oriented and non-object-oriented programming systems.

Although aspects of the present invention are described as being stored in memory, one skilled in the art will appreciate that these aspects can also be stored on other types of computer-readable media, such as secondary storage devices, like hard disks, floppy disks, CD-ROM, an Internet connection, or other forms of RAM or ROM.^" The scope of the invention is defined by the claims and their equivalents.

Claims

We claim:

1. A method for managing a solicitation directed to a member of a pre-defined population, the method comprising the steps of: determining a rules base for said solicitation, wherein said rules base defines particular features of said solicitation; sending said solicitation to said member; receiving a response to said solicitation from said member; and analyzing said response in accordance with said rules base to determine whether to make an offer to said member.

2. The method of claim 1 , wherein the defining step further includes the substeps of: determining a plurality of desired requirements for said solicitation, each desired requirement corresponding to a rule of said rules base; identifying a previous solicitation having a requirement matching at least one of said plurality of desired requirements; and copying, into said rules base, a rule corresponding to said matching requirement.

3. The method of claim 1 , wherein said sending step further includes the substep of: sending said solicitation using at least one of the following: e-mail, facsimile, a wide area network, and an Interactive Voice Response (IVR) system.

4. The method of claim 1 , wherein said receiving step further includes the substep of: receiving said response using at least one of the following transmission mediums: e-mail, facsimile, a wide area network, and an Interactive Voice Response (IVR) system.

5. The method of claim 1 , wherein said solicitation comprises an offer for a financial service.

6. The method of claim 5, wherein said financial service comprises a credit card account.

7. The method of claim 5, wherein said financial service comprises a financial loan.

8. The method of claim 1 , further comprising the step of: making an offer, based on said analysis of said response, to said respondent in accordance with the solicitation.

9. The method of claim 1 , wherein the analyzing step further includes the substep of: receiving rules associated with said rules base in the form of a plurality of tables.

10. The method of claim 1 , wherein an identification tag is received with the response, and the analyzing step further includes the substep of: identifying the rules base corresponding to said solicitation using the identification tag; and analyzing said response in accordance with said identified rules base to determine whether to make an offer to said member.

11. A method for creating a solicitation comprising the steps of: determining a desired requirement for the solicitation; identifying a previous solicitation having a requirement matching said desired requirement for said solicitation; defining a new rules base based on said desired requirement for said solicitation using the identified previous solicitation; and creating said solicitation using said new rules base.

12. The method of claim 11 , wherein said solicitation comprises an offer for a financial service.

13. The method of claim 12, wherein said financial service comprises a credit card account.

14. The method of claim 12, wherein said financial service comprises a financial loan.

15. A computer for managing solicitations, the computer comprising: a memory having program instructions; and a processor, responsive to the programming instructions, configured to: determine a desired requirement for the solicitation; identify a previous solicitation having a requirement matching said desired requirement for said solicitation; define a new rules base based on said desired requirements for said solicitation using the identified previous solicitation; and create said solicitation using said new rules base.

16. The computer of claim 15, wherein said solicitation comprises an offer for a financial service.

17. The method of claim 16, wherein said financial service comprises a credit card account.

18. The method of claim 16, wherein said financial service comprises a financial loan.

19. A computer for managing solicitations directed to members of a predefined population, the computer comprising: a memory having program instructions; and a processor, responsive to the programming instructions, configured to: determine a rules base corresponding to said solicitation, wherein said rules base defines particular features of said solicitation; send said solicitation to a member of said predefined population; receive a response to said solicitation from the member, wherein said response includes an identification tag identifying said rules base corresponding to the solicitation; identify the rule base corresponding to the solicitation based on the identification tag included in the response; and analyze said response in accordance with said identified rules base to determine whether to make an offer to said member.

20. The computer of claim 19, wherein the processor is further configured to: determine a plurality of desired requirements for said solicitation, each desired requirement corresponding to a rule within said rules base; identify a previous solicitation having a requirement matching at least one of said plurality of desired requirements; and copy, into said rules base, a rule corresponding to said matching requirement.

21. The computer of claim 19, wherein the processor is further configured to: send said solicitation using at least one of the following: e-mail, facsimile, a wide area network, and an Interactive Voice Response (IVR) system.

22. The computer of claim 19, wherein the processor is further configured to: receiving said response using at least one of the following transmission mediums: e-mail, facsimile, a wide area network, and an Interactive Voice Response (IVR) system.

23. The computer of claim 19, wherein said solicitation comprises an offer for a financial service.

24. The computer of claim 23, wherein said financial service comprises a credit card account.

25. The computer of claim 23, wherein said financial service comprises a financial loan.

26. The computer of claim 19, wherein the processor is further configured to: make an offer, based on said analysis of said response, to said respondent in accordance with the solicitation.

27. The computer of claim 19, wherein the processor is further configured to: receive rules associated with said rules base in the form of a plurality of tables.