Adaptive strategy-based system6061506Abstract A user definable closed computerized smart system to emulate the day-to-day continuous operation of business environments with minimal human intervention. A simple and efficient mechanism for defining and updating recurring business cyclical activities is provided. A system is provided for tracking all predefined pending activities and events, storing and retrieving appropriate information in a relational knowledge base. A delay-pending feature is taught that modifies pending activities and events, relative chronologically to other business activities and events. An expert feature for effectuating certain predictable logical and intuitive behavior based upon rules stored in a knowledge base is also provided. An update fields methodology is also provided for maintaining and changing data in individual knowledge base records on the basis of dynamically changing circumstances. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
Names Database
NUM- PAR-
BER ENT PAR.sub.-- NUM
RELATION
STATUS EMPLOYEE
______________________________________
10 0 2500 golf buddy
hot prospect
ABC
2500 1 established
DEF
customer
______________________________________
The first entry shown in the Names table contains a "0" in field PARENT corresponding to a false condition; record 10 is not a parent as contemplated by the present invention. Since this record contains a number in field PAR.sub.-- NUM, however, according to the present invention, it is a child record for the Names record indicated, i.e., for Names record 2500. For child record 10, field RELATION communicates the nature of the relationship between the parent and child records. The second entry in this Names table, contains a "1" in field PARENT corresponding to a true condition; record 2500 is a parent as contemplated by the present invention. There are, of course, several ways in which this relational information may be used. For instance, employee ABC may prevail upon employee DEF to encourage established customer Barbara Kvorkean to share her high regard for the company's products with her golf buddy, prospect Jill Sandusky. As another example, employees DEF and ABC might co-sponsor post-golf entertainment with Barbara Kvorkean and Jill Sandusky to cross-fertilize their respective interests. As anothe example, employee DEF may be secondarily assigned to prospective customer Jill Sandusky to function as a bridge between Barbara Kvorkean and employee ABC. It is within the contemplation of the present invention that a Names record may be both a parent and a child. For example, consider another illustration in which a Names record is both a parent and a child.
______________________________________
Names Database
NUM- PAR-
BER ENT PAR.sub.-- NUM
RELATION
STATUS EMPLOYEE
______________________________________
10 0 2500 golf buddy
hot prospect
ABC
1853 new ABC
customer
2500 1 1853 St. Peters
established
DEF
Church customer
______________________________________
Now, record 2500 in the Names table contains a "1" in field PARENT and also contains a numeric value in field PAR.sub.-- NUM, indicating that this record is both a parent and child. As should be evident to those skilled in the art, the number 1853 stored in field PAR.sub.-- NUM of Names record 2500 specifies that Names record 1853 is the corresponding parent. Field RELATION conveys the nature of the parent-child relationship: that the entities represented by records 1853 and 2500 attend the same church. As should be evident to those skilled in the art, the issue to be addressed by users of a smart system, is how to exploit this real world relational information to achieve a sale or the particular business goal being sought. The present invention contemplates a user-defined knowledge base which provides information as a Gestalt, wherein there is provided timely information about virtually every aspect of a business and organizational environment which may be accessed by employees and the like, according to predefined access and security rules, to accomplish the objectives and goals of the enterprise and the like. While the preferred embodiment contains one PARENT.sub.-- NUM field and one RELATION field, it should be clearly understood that it is within the contemplation of the present invention that there may be a plurality of these fields if prerequisite to accurately defining organizational and other parent-child relationships. It is also within the contemplation of the present invention that parent-child relationships may be defined not only among Names records and the like, but also may be defined between Names records and Employee records. Thus, information that relates propects and employees by common interests, religious leanings, neighborhood, etc., is now readily available throughout a business enterprise and the like to promote achieving goals and objectives. The present invention may, of course, include ancillary lookup tables for such fields as RELATION and STATUS to make data entry convenient for users, to minimize data errors, and to provide limited, predefined choices so that summary statistics and the like may be generated as required. As will be appreciated by those skilled in the art, to enable a diversity of users of a smart system to completely identify entities in the Names table, the preferred embodiment provides 48 additional customizable fields. More particularly, there are 28 customizable 40-byte character fields (DATAC1, DATAC2, . . . DATAC8, DATAC10, . . . DATAC29), 8 numeric fields (DATAN1, DATAN2, . . . DATAN8), for storing up to 10 digits with 2 decimal places, and 4 logical fields (DATAL1, DATAL2, . . . DATAL4) for storing either a 1 for a "true" condition or a 0 for a "false" condition. In a manner well known in the art, the present invention provides the capability to create look-up tables for a plurality of fields so that data entry burdens may be minimized and so that consistent values are assigned to key fields and other standardized names and the like. In FIG. 9, each Employee record is shown consisting of 20 fields. Character field EMP.sub.-- ID identifies an employee by his or her initials, which correspond to the first name, middle initials and last name stored in character fields EMP.sub.-- FNAME, EMP.sub.-- MI and EMP.sub.-- LNAME, respectively. The employee's title and gender are stored in fields EMP.sub.-- TITLE and EMP.sub.-- GENDER, respectively. Character fields EMP.sub.-- MGR and EMP.sub.-- DIV define an employee's position in the business or organization via his or her manager and division or the like. Field ASSISTANT provides for supplemental secretarial or administrative support for the employee. Character fields EMP.sub.-- PHONE and EMP.sub.-- EXT store the employee's telephone number and extension, if any; fields EMP.sub.-- FAX and MOBFONE store the facsimile number and Mobile phone numbers, respectively. Character field CLOSING contains the proper closing in letters sent to Names entities by the employee. As will become clear to those skilled in the art, while it is a feature and advantage of the present invention that employees have access to a comprehensive and cumulative knowledge for a predefined business environment and the like, this access may be controlled by invoking appropriate security-related fields. Thus, character field PASSWORD is provided for specifying a password and numeric field SEC.sub.-- LEVEL is provided a suitable security level for the employee. Furthermore, logical fields DEL.sub.-- RTS, EDIT.sub.-- RTS, ADD.sub.-- RTS and BROW.sub.-- RTS indicate whether the employee defined in the instant Employee record has the rights to delete, edit, add and/or browse knowledge base records. It should be evident that by limiting a smart system to password access and by assigning an appropriate security level, the browsing rights of employees and other users may be conveniently controlled. Furthermore, the rights to edit, add or delete smart system records may be similarly controlled by a system administrator and the like. In FIG. 10, each Actions record is shown consisting of 23 fields. Numeric field ACT.sub.-- NUM contains a 3-digit number which identifies an action which is described in 30- byte character field ACT.sub.-- DESC. Field ACT.sub.-- FMT contains an 8-character indication of the "Format" of the action. As contemplated by the present invention, the Format of an action determines its associated output format. Predefined system Formats include Reminder, Phone, Suspend, Fax, Letter, Brochure, Failure, Delete, Visit and Null. An action having a Suspend Format, for example, is programmed to process the instant action and simultaneously to delete all other pending actions for a given Names record when the record is processed. A Fax Format, of course, preferably sends appropriate textual information pertaining to an action by facsimile transmission to an internal fax modem. As will be readily understood by those skilled in the art, the text for a Fax or a Letter Format would be conventionally prepared in the standard word processor used by employees, and then be available for routine incorporation into the appropriate output form, wherein the smart system merges all appropriate data from the Names, Employee and Actions databases. For example, in a Letter Format, employee information related to the action being performed upon a named entity would be merged to appear in the letter's signature block. Of course, the smart system automatically generates a suitable letter for the action being processed, corresponding to the employee who performed this action. Actions like letters and reports may have Printable Formats, while other actions may be designated as having Non-Printable Formats, e.g., Phone actions. Under the preferred embodiment, a Null Format corresponds to an action for which nothing immediately happens, e.g., nothing is immediately printed; such a Null action is recorded in History database 70 and then a plurality of next actions is set up in Pending database 65. As will be evident to those skilled in the art, the present invention enables Formats to be added, edited and deleted in a conventional manner by editing tables and the like. For convenient specification of the appropriate Format for an action, Format table 90 is preferably provided. FIG. 11 depicts the layout for records contained in the Format table. As clearly shown therein, as taught by the present invention, Formats focus upon outputs delivered to users. In particular, table Format contains 1-byte logical fields Letterhead, Envelope, Printable and Printlabel, corresponding to the necessity for including a letterhead, envelope or label, respectively, for a printable output. Hence, according to the preferred embodiment of the present invention, at printing time, as will be hereinafter described in detail, the print function opens Process database 75 and loads pertinent data therein for the selected format. As will become apparent to those skilled in the art, only actions which have Printable Formats (logical field Printable being "true") are displayed for output. Similarly, an Action record designating a Letter output (logical field Letterhead being "true") may also require an envelope Format (logical field Envelope being "true") or a label Format (logical field Printlabel being "true"). Of course, since the present invention teaches a user-defined smart system, users may create any reasonable Format for actions. For instance, if users (defined in the Employee database) regularly send Christmas cards to customers or potential customers (defined in the Names database), then a suitable Format would be Xmas. As will become clear to those skilled in the art, to generate Christmas cards to all employees' related records stored in the Names database, an action having a Format of Xmas would be added to each Names record as an appropriately scheduled action. Then, provided that certain selection criteria were met at processing time, each such action would be processed and set up for printing Christmas cards. If a label were to be printed in conjunction with each Christmas card, a user would indicate that Xmas is a printable format which requires that a label be generated at print time. Thus, the Format record for this new output format would be:
______________________________________
Field Value Meaning
______________________________________
Format XMAS Christmas cards
Letterhead
0 False; no letterhead
Envelope 0 False; no envelope
Printable 1 True; generate output
Printlabel
1 True; generate labels
______________________________________
Referring again to the Actions table database depicted in FIG. 8, there is also seen numeric field ACT.sub.-- TYPE which contains a 2-digit number identifying action type intended to permit generation of summary information. For example, action types might include Call, Meet, Sale, Consult and Wait. For convenient specification of the appropriate type for an action, ActTypes table 85 is preferably provided FIG. 12 depicts that each record contained in the ActTypes table has an 8-character description for each action type. Logical field ACT.sub.-- INIT indicates whether an action corresponds to an entry point to a knowledge base strategy. If an action corresponds to such an entry point, then there may be a sequence of related actions which predictably follow the initial action. Such anticipated next actions may be stored in a sequence of data fields in the Actions database record, effectively chained to the initial action. Thus, under the preferred embodiment, as depicted in FIG. 10, there are three next fields, i.e., NEXT.sub.-- 1, NEXT.sub.-- 2 and NEXT.sub.-- 3, which are time-sequenced relative to the initial action identified in field ACT.sub.-- NUM and described in field ACT.sub.-- DESC of the current Actions record. In particular, the next action contained in field NEXT.sub.-- 1 is scheduled to be the immediate next action after the elapsed time specified in field DAYS.sub.-- 1; the action after this immediate next action stored in field NEXT.sub.-- 2 is scheduled to occur within the elapsed time specified in field DAYS.sub.-- 2; similarly, the action after this next action stored in field NEXT.sub.-- 3 is scheduled to occur within the elapsed time specified in field DAYS.sub.-- 3. Hence, one pending action may establish multiple subsequent actions: once the instant pending action is completed, it is deleted from the Pending database, moved to the History database, and automatically establishes up to three (next) actions in the Pending database. It should be clearly understood, of course, that embodiments of the present invention may comprise any number of such next-fields depending from the nature of the particular business environment and the like being emulated. It should also be understood that it is within the teachings of the present invention that the structure of these next-fields and related elapsed time fields may be configured according to well known database principles, wherein, for example, there may be a variable number of these next couplet fields--next action and corresponding elapsed time for such next action to occur--hierarchically related to the parent Actions record. Still referring to FIG. 10, there is shown another sequence of fields which store the actions, if any, which are replaced by the instant action. More particularly, in the preferred embodiment, fields REPL.sub.-- 1, REPL.sub.-- 2 and REPL.sub.-- 3 store the action numbers for pending actions which are superseded by the action in the instant Actions record. Thus, each of fields REPL.sub.-- 1, REPL.sub.-- 2 and REPL.sub.-- 3 may store the number of a pending action which should be deleted from the Pending database because of the completion of the instant action. If, for example, an instant pending action is suspended, i.e., has a Suspend Format, then all actions contained in its REPL.sub.-- 1, 2 and 3 should likewise be deleted in the Pending database. Under the teachings of the present invention, a user-defined strategy is captured in a computerized smart system wherein a single pending action may set up multiple subsequent actions. Similarly, such a single pending action may delete multiple pending actions. While the preferred embodiment is configured with three next-action fields (NEXT.sub.-- 1, NEXT.sub.-- 2 and NEXT.sub.-- 3) and three replace-action fields (REPL.sub.-- 1, REPL.sub.-- 2 and REPL.sub.-- 3), it should be clearly understood that it is within the teachings of the present invention that a plurality of these and related fields may be implemented. Also shown in FIG. 10 is another sequence of fields which store possible actions which obtain or are options from the instant action. Such options-from fields, i.e., fields FROM.sub.-- 1, FROM.sub.-- 2 and FROM.sub.-- 3, store the action numbers for pending actions which are followed by the action in the instant Actions record. Thus, the present invention teaches a knowledge base which comprehensively communicates the path taken by a pending action identified in the current record, taken by or on behalf of a particular employee and performed on a named entity stored in the Names database. Other fields contained in the Actions database as shown in FIG. 8 include COST which stores the cost associated with the action, MTD which stores the number of incidences of the action in the current month and YTD which stores the year-to-date incidences of the action. Field TODD is a logical field indicating whether the action should be printed on the employee's To Do List. Field TRIMTEXT is a logical field indicating whether the action should be printed with insignificant trailing blanks and the like "trimmed" or truncated; as should be appreciated by those skilled in the art, such trimming is advantageous when the content of fields result from merged database fields. Field NOTELEN specifies the numerical value for employee generated notes to be included when printing reminders or actions (with associated notes) included on To Do Lists, etc. As will be appreciated by those skilled in the art, effective use of telephone activities is an important facet of operating a successful business. Accordingly, the present invention provides a telephone processing aspect intended to automatically assure optimum telephone behavior by smart system users. As will be understood by those skilled in the art, the automatic processing aspect of the present invention focuses upon an appropriate date through which calls should be processed. Under automatic processing contemplated by the present invention, all pending actions including telephone actions would be processed through a specified date, e.g., current date; all such processed pending actions are removed from the Pending database and stored in the History database. Some of the telephone actions scheduled to be made on or before the specified date, however, may be deleted from the Pending database before the calls are actually made. To avoid phone calls being deleted prematurely from the database of pending actions, the present invention provides a telephone processing aspect that assures that pending calls are not deleted until actually performed. The preferred embodiment isolates all such scheduled pending calls by isolating all pending actions having a Format preferrably beginning with the character string "PHONE." Such an action having a PHONE Format has a corresponding record established in the History database, has a next action established in the Pending database--as defined in the Actions database--but this phone action is not deleted from the Pending database. As will be understood by those skilled in the art, this telephone methodology allows an entity having an existing Phone Type action to remain in the Pending database until an employee actually makes the call. Then, and only then, is the Phone action deleted from the Pending database. Notwithstanding the use of computer-generated voice messages and the like, it should be evident that Phone Type actions are usually actions performed by humans. Thus, the present invention teaches a methodology capable of deleting pending actions that have been performed or that are due to be performed and also capable of holding in abeyance actions that were due to be performed but were not completed. The relationship between records stored in either the Pending or History databases, or both, indicates whether actions have been completed, whether telephone actions have been scheduled for completion but are still pending, etc. To illustrate the unique operational aspects and concomitant benefits of a strategy based system contemplated by the present invention, a common sales scenario will again be considered. In so doing, focus will be made upon a fundamental activity and its correspondence to an actual real world event. It is assumed that a salesperson is due to place a telephone call to a prospective customer who has inquired about a product that the salesperson sells. It is further assumed that the salesperson's immediate objective is to achieve a face to face meeting with this prospective customer (the prospect). To represent this sales scenario in which a salesperson is scheduled to make a telephone call seeking a meeting with a prospect, computerized smart system 2 comprising the preferred embodiment would interrelate the databases depicted in FIG. 2. The salesperson is identified to this system by a record in Employee database table 60. Similarly, the prospect is identified by a record in Names database table 55. FIG. 13 depicts the interrelationships between common fields contained in a knowledge base contemplated by the preferred embodiment of the present invention. The Names record for the prospect, shown as John Jones, contains a field indicating the employee, shown as salesperson ABC, with primary responsibility for making a sale happen. The scheduled action of salesperson ABC to "Call to meet" prospect Jones is stored in an Actions database; such a telephone call is represented in the Actions table as having a Phone Format, having a Call Type, and having an associated cost of $0.50. As will become clear to those skilled in the art, output for an action having a Phone Format will be sent directly to a telephone line or to an on-screen module and the like to be displayed, instead of being sent to a printer to generate hard-copy and the like. Still referring to FIG. 13, the Pending database shows that salesperson ABC has a pending action number 1 to be performed on the entity contained in record number 1 of the Names database. It should be evident to those skilled in the art, that the references contained in a Pending database record are easily ascertained by retrieving the matching record in the related database table. Thus, a particular entity is ascertained from the Names database, an employee having primary responsibility for the entity is ascertained from a related record in the Employee database, and related action descriptions and attributes are ascertained from the likewise related Actions database. According to the teachings of the present invention, it is the pending action for ABC that determines that ABC is to make a call. In setting up this action, a smart system merely uses the field containing employee identification in the Names database as a default. As hereinbefore described, to completely describe an action, fields should be defined by the user. Such action definition should preferably include: action name; action format; action type; associated cost; action number; next action(s), i.e., subsequent series of action(s); elapsed time until the next action(s) (minutes or hours or days) are scheduled to occur; related action(s), if any, which are replaced by the action; whether the action is an "initial" action; what prerequisite action(s) must have occurred for this action to be processed; where the action is an "option" from (if any); length of notes to be posted; "update fields"; text amplifying the action. For example, the action name may be "Call to arrange a meeting" which, of course, effectively describes the purpose of the action. As hereinbefore described, the Format for this action may be identified as "Phone"; the Type may be identified as "Call"; the cost may be established as $0.50 corresponding to time, line charges, etc.; the action number is set by the smart system and is sequentially assigned, e.g., the first action added would have action number 1, the second would be action number 2, etc. The remaining action-defining fields will be described hereinafter. Once the first action (Action Number 1) is defined in a smart system, this action will permanently be referenced for convenience as "PHONE.1" in the strategy taught by the present invention. Thus, according to the present invention, an action is preferably named by its Format followed by a sequential action number, namely: Format Name.Sequential Action Number Now that an action has been "created" in a smart system, the action should be presented to an appropriate salesperson, i.e., an entity that exists in the real world scenario. This is accomplished by associating a pending action with the name of the prospect to be called and the identifier for the employee who will perform the action on the prospect. Using relational database techniques known in the art, as depicted in FIG. 13, an action is linked to a named entity via fields contained in related tables comprising the hereinbefore described knowledge base. It is an important aspect of the present invention that all of these constituent tables are appropriately interrelated so as to render any and all needed information instantaneously available from the knowledge base to ascertain strategies for effecting activities and events in the real world scenario being emulated. In the instant example, so far, there are only two players: (1) salesperson ABC and (2) prospective customer Jones who salesperson ABC is scheduled to call. As should be evident to those skilled in the art, an automated system contemplated by the present invention should preferably provide comprehensive and cumulative knowledge of the interrelationship of all of its predefined entities and employees in the context of the particular business scenario in order to continuously and accurately emulate real world events. According to the teachings of the present invention, an action is what the salesperson must perform to the named prospect (or, in general, what must happen to the named entity). Thus, an action should preferably be in one of two states: completed or pending. Until completed, of course, an action is pending. Under the present invention, as shown in FIGS. 2 and 13, pending actions like "Call to meet" are stored in Pending database 65. Similarly, completed actions are stored in History database 70, by being moved from the Pending to the History database. All named entities are defined and stored in Names database 55. As hereinbefore described, the relationship between actions and named entities in the preferred embodiment throughout smart system 2 using knowledge base 5, comprising Names table 55, Employee table 60, Actions table 50, Pending table 65 and History table 70, is illustrated in FIG. 13. As is clearly shown, Names record #1 has a pending action attached to it in Pending table 65. The pending action is Action Number 1. Thus, by referring to Actions table 50, it is seen that Action Number 1 corresponds to "Call to meet" (various other descriptors are also available to the system). It is also seen that Pending table 65 stores the identity of the salesperson who is due to perform this action and when the action is due to be carried out. It is further seen that named entity number 1 is due to receive the action, i.e., the call, from salesperson ABC. Those skilled in the art will appreciate the improvements and enhancements taught by smart system 2 contemplated by the present invention. Multiple employees may readily be scheduled for actions pending to be performed upon the same named entities, i.e., upon the same record in Names database table 55. It is a feature and advantage of the present invention that all employees as users of a smart system may have access to information contained in a plurality of records stored in Pending database table 65 and History database table 70, corresponding to those records which are relevant to particular customers and the like. That is, unlike computerized expert systems and the like heretofore known in the art, all users of such a smart system may have access to all actions and events that are scheduled to occur and that have already occurred, for particular customers and the like. Continuing with the salesperson-prospect scenario, assume that the day of the scheduled telephone call arrives. According to the methodology taught by the present invention, salesperson ABC would identify himself to smart system 2. The system would then display all relevant information about the entity, i.e., prospect, scheduled to be acted upon, i.e., to receive a phone call and the nature of the call. That is, as will be appreciated by those skilled in the art, there may be several types of phone calls made by employees. While, in this instance the nature of the call is to attempt to arrange a meeting ("Phone to meet"), there may be another call scheduled later in the sales cycle to follow up a proposal ("Phone to follow-up on proposal"). The particular scheduled action is displayed to the user. As should be clearly understood by those skilled in the art, this behavior corresponds to a human action. Of course, while for each business scenario and the like, human intervention is intertwined with inherent objectives and goals, there can be computer-generated actions which may be effectuated independently of such human intervention. An example of a computer generated action is preparing a form letter to document a past event or to confirm a predictable current or future event. In the instant real world scenario, once salesperson ABC actually calls prospect Jones, there are a finite number of situations which may occur next. For example, the prospect may either: (1) say "Yes" to a meeting; or (2) say "No" to a meeting showing a lack of interest in the product being offered for sale; or (3) say "No" to a meeting and request that information be sent; or (4) be unavailable or unable to receive the call, wherein a message was left with staff or on an answer machine or on voice mail; or (5) say "Wait" because prospect Jones is too busy at this time to meet with salesperson ABC, but Jones requests another call in a specified period of time, e.g., "x" months. To completely emulate an actual business scenario enabling a proper strategy to be developed, these enumerated options should preferably be expanded to depict all of the options that might be available to a user. For simplicity, however, assume that these five options are the only possibilities. While each of these possibilities constitute actions which should preferably be contained in the Actions database, each of these actions also correspond to subsequent actions depending from the predecessor action. Accordingly, under the present invention, these possible subsequent actions are designated as being "options from" predecessor action number 1. Thus, it is a feature and advantage of the present invention that a user would only be presented with these options when calling a prospect within the scope of an action number 1. That is, another phone action, e.g., making a call to confirm a meeting, would have a different series of possible subsequent actions and hence would have different options from such initial action. Now referring to FIG. 23, an employee, having previously identified the possible subsequent actions from a "Call to meet" action (Phone.1) has added these actions to the Actions database. In particular, the "Yes" action, i.e., Yes to a meeting with a salesperson, may be a Letter Format (Letter.2), wherein a letter confirms the date and the time of the meeting. This Yes action would, in turn, have a next action X (Reminder.X) which should preferably be a reminder of the meeting. That is, a Reminder action would attempt to minimize the chance of a salesperson inadvertently missing the scheduled meeting. Under the preferred embodiment, a reminder action by default indicates that a meeting is scheduled to occur in zero days, thereby prompting a user to specify the planned number of days until the meeting will be held. It is a feature and advantage of the present invention that any next action scheduled for zero days hence prompts the user to edit the number of days until the specified next action is due to occur. The "No" action, i.e., No to a meeting indicating lack of interest or lack of time availability, would probably be a Suspend Format (Suspend.3). Under the present invention, a Suspend Format erases all pending actions for the named entity. The "Send information" action would typically be a Letter Format corresponding to a cover letter to the information package being forward to the prospect (Letter.4). As shown, the next scheduled action would be to repeat the "Call to meet" action (Phone.1) to attempt to have a follow up meeting: the next action would be action Number 1 to occur in a prescribed number of days, e.g., in seven days (since another call is necessary to set up the meeting). Still referring to FIG. 23, the "Left message" action (Null.5) would be a Null Format, i.e., no immediate action, assuming that the default Formats supplied with the preferred embodiment are used. As a next action, however, it might be advisable to schedule another attempt to reach a prospect by phone, i.e., to set next action as action Number 1 in two days or some other time frame. Similarly, the "Wait" action would be appropriate for a situation in which a salesperson places the entity in abeyance; this would be appropriate if a salesperson's "leads" suggest that the prospect should be called again in a suitable time frame, e.g., a month, two months, two weeks, etc. In the first of these waiting possibilities (action letter.6), a form letter would be forwarded to the prospect and the user schedules a (follow up) call back to be made in one month. Assume that it is the practice of the particular sales business to maintain regular contact with a prospect after the first call is made and before the next call is made. Accordingly, a total of 3 letters might be sent to the prospect prior to the follow up call being made. This is shown in FIG. 23 as the sequence of Letter.6 followed by Letter.9 14 days later, followed by Letter.10 10 days later. Hence, under these circumstances, Letter.6 would thank the prospect for visiting with the salesperson during the call; Letter.9 would just touch base with the prospect; and Letter.10 would alert the prospect to expect an imminent call. Alternatively, Letter.7 would be a form letter similar to Letter.6 but would advise the prospect that a follow up call is scheduled for two months later; Letter. 11 would just touch base with the prospect 35 days later; and Letter.10 would alert the prospect to expect an imminent call 17 days later. Alternatively, Letter.8 would be a form letter similar to Letter.6 and Letter.7 but would advise the prospect that a follow up call is scheduled for two weeks later, Letter.10 would alert the prospect to expect an imminent call 10 days later. This, then, for instance, would schedule Phone.1 to occur in 7 days. It is thus within the teachings of the present invention to bias users to fully define the inner workings of a business environment so that a smart system may accurately accomplish the intended emulation. In this particular telephone cycle, there are several alternative action sequences that follow from an attempted call to a prospective customer to set up a meeting. The sequence of possible actions springing from action Phone.1, namely, Letter.2, Suspend.3, Letter.4, Null.5, Letter.6, Letter.7, Letter.8, Letter.9, Letter.10 and Letter.11, are understood by the preferred embodiment and enable requisite processing to occur either automatically or with minimal human intervention. Thus, to the extent that such a computerized system contemplated by the present invention has been educated that the best way to keep in contact with a seemingly interested prospect is to send three letters to the prospect during the month, then the preferred embodiment would automatically schedule three such letters as three successive next actions. The first letter would thank the prospect for time expended during the initial phone conversation. Perhaps, two weeks later, another letter would be sent to simply touch base. The third letter would then be sent perhaps ten days thereafter to inform the prospect to expect an impending call to schedule a meeting. The latest letter would have "Call to meet" as its next action in a user specified number of days, e.g., 7 days, thereby completing the cycle. As will be appreciated by those skilled in the aft, the present invention provides an automatic and a manual processing capability. Assume that there are two pending printable actions, with one action having set up the other, e.g., as a next action. Under the present invention, automatic processing methodology traverses the entire Pending database to select the actions scheduled for completion through the specified date. Inherent in automatic processing contemplated by the present invention, as should be appreciated by those skilled in the art, is the concomitant establishing of pending actions from telltale fields in other actions. As has been herein described in detail, such fields as NEXT.sub.-- 1, NEXT.sub.-- 2 and NEXT.sub.-- 3, such fields as FROM.sub.-- 1, FROM.sub.-- 2 and FROM.sub.-- 3 and such fields as REPL.sub.-- 1, REPL.sub.-- 2 and REPL.sub.-- 3 in the preferred embodiment convey the interdependencies between pending and future actions. Thus, if a letter action is set up by another action, e.g., a meeting, then prior to actually printing the letter, specific text must be merged into a prescribed form. This is accomplished using the Process database which coordinates, for a specified date (via field PROC.sub.-- DATE), a particular action and its associated Format (via fields ACT.sub.-- NUM and ACT.sub.-- FMT) with the employee performing the action (via field EMP.sub.-- ID) and, of course, the description of the textual content of the letter (via field TODO). This processing contemplated under the present invention is depicted in the flowchart in FIGS. 22A-F. First referring to FIG. 22A, in the step represented by numeral 1000, the date through which processing should be performed is obtained from a suitable location in memory. The Pending database is then opened in step 1005. In step 1010, all records are copied to a temporary file, having records with a scheduled activity date less than or equal to the date specified in step 1000 and also records with a scheduled activity date greater than the specified date. As will be appreciated by those skilled in the art, it is advantageous to make a temporary copy of the Pending database so that ongoing activity over a local area network and the like will be uninterrupted, i.e., automatic processing may proceed without requiring exclusive use of the Pending database. Using a temporary database also provides efficiency (by eliminating loops) when processing an action having a next action with an elapsed time of zero days. In the next step, represented by numeral 1015, records with a scheduled activity date greater than the specified date are deleted from this temporary file. Once the pending records to be processed have been isolated in the temporary file, which, as will be appreciated by those skilled in the art, is preferably defined with the same record layout and attributes as the Pending database record, the temporary file is opened and positioned at the first record therein, in steps 1020 and 1030, respectively. Then, as depicted in step 1030, the steps depicted in FIGS. 22B-F are performed so long as a end-of-file condition is not reached in the temporary file. Referring now to FIG. 22B, a temporary file pending record is obtained in step 1040 and its field contents loaded into memory (e.g., ACT.sub.-- NUM=A, NUMBER=B, EMP.sub.-- ID=C, etc.) in step 1045. Next, in steps 1050 and 1055, the History database is opened, and a blank record is appended thereto, respectively. In accordance with the present invention, any time that a database table is opened, it is assigned a unique work area in memory so that a plurality of databases may be opened and processed simultaneously. Thus, if it is assumed that the temporary file corresponding to the Pending database table is contained in a first work area, then another temporary file corresponding to the History database table is contained in a second work area. In step 1060, all of temporarily saved pending activity information contained in memory is written to this appended record (e.g., variables A, B, C, . . . ). It should be understood that the memory variable storing employee information is obtained from the Pending database, enabling the existence of a plurality of pending actions to be performed by a plurality of employees against a single entity. This constitutes a significant departure from the prior art wherein employee is generally obtained from the related entity contained in a Names database and the like, thereby limiting to only one the number of pending actions to be performed against an entity. The scheduled date for the current activity is obtained in step 1065 and then (step 1070) the Actions database is opened. Similar to the Pending and History tables, a temporary actions table is stored in memory in a third work area. Referring now to FIG. 22C, an Actions record is sought having the action number stored in memory (shown as value A) in step 1080. For the Actions record found in step 1080, all data fields are stored in memory (set "x") in step 1085. Then, in steps 1090 and 1095, the set of the next actions fields and the replacement actions fields are retrieved from memory, and after the Pending database is opened (1100), the actions to be replaced are sought in steps 1105-1150. More particularly, all pending actions found in step 1105 are deleted from the work area corresponding to the Pending database in step 1110; all of the candidate pending records are traversed in steps 1115 and 1120. It should be clear that the memory variables retrieved in step 1090 identify the set of next actions and the elapsed time in which this (next) action is scheduled to occur. It should also be clear that the memory variables retrieved in step 1095 indicate the pending actions that should be replaced by action A. Now referring to FIG. 22D, there is shown the automatic processing logic for pending actions satisfying the date criterion and having a Suspend Format; pending records with a Suspend Format are effectively canceled in steps 1135-1150, while pending records with a Format other than Suspend proceed directly to step 1130 (FIG. 22E). For each such pending record found with a Suspend Format in step 1140, the record is deleted in step 1145. Referring now to FIG. 22E, steps 1130-1280 are shown for adding next actions to the Pending database for the particular action being processed. Depicted in FIG. 22E are three identical paths, steps 1135-1180, steps 1190-1230 and steps 1240-1280, corresponding to the automatic processing for each of the three next action couplets (action number and elapsed time in which the action is scheduled to occur) contained in the preferred embodiment. Thus, step 1135 ascertains whether there is a first next action. If there is a first next action, then it is processed in steps 1140-1180, wherein the Pending database is opened (1140) and a blank record is appended thereto (1145). In the following step represented by numeral 1150, the Actions database table is opened and a matching record with value L stored in memory is sought (1155). The values stored in this Actions record, in a manner similar to hereinbefore described, are copied to memory variables (1160) and then written to the Pending database table (1170) with its date field appropriately incremented (1175). All of these memory variables are then cleared (1180) and processing continues in step 1190 for the second next action. The processing for this next action takes place in steps 1190-1230 similarly to the processing in steps 1135-1180 for the first next action. Similarly, all of the memory variables corresponding to the second next action are then cleared (1230) and processing continues in step 1290 for the third next action. The processing for this next action takes place in steps 1240-1280 similarly to the processing in steps 1190-1230 for the second next action. FIG. 22F depicts the automatic processing related to employees and is designed to permit printing across multiple branch locations which may be interconnected via a wide area network and the like. In steps 1295 and 1300, respectively, the Process and Employee database tables are opened, copied to different work areas in memory, and a blank record appended in memory to the Process table. Under the preferred embodiment of the present invention, the Process table is copied to a third work area and the Employee table is copied to a fourth work area. In step 1305, the employee value from set x (step 1085) is located in this Employee table and the division information is stored in a memory variable (1310) which is then written to the appended record (1315) along with the relevant information stored in memory (1320), e.g., action number, employee id, snf ther process date (1325). Processing then shifts to the novel Update Fields aspect of the present invention in 1330, as herein described in detail, after which all memory variables are cleared (1335). Manual processing of a completed single action under the present invention comprises removing the action from the Pending database and placing the record in the History database, and then setting up a plurality of follow-up actions in the Pending database. As should be understood by those skilled in the art, under the automatic processing aspect of the present invention, such a plurality of follow-up actions would be automatically set up for the completed action during its smart follow-up methodology. Thus, for manual processing of a completed action, the completed action is first selected from the plurality of pending actions and set up in the Process database with appropriate values for fields ACT.sub.-- NUM, ACT.sub.-- FMT, EMP.sub.-- ID, ZIP, EMP.sub.-- DIV, TODO and PROC.sub.-- DATE. The completed action is, of course, moved from the Pending to the History database, and appropriate follow up actions are then set up in the Pending database. Any necessary changes to fields in the Names database are, as has been hereinbefore described, loaded into appropriate fields (FLDNAME, CDATA, NDATA, DDATA, LDATA, DTYPE and ADDTO) of a plurality of records contained in the Update database, for automatic implementation via the Update Fields aspect of the present invention. It is also within the teachings of the present invention to alteratively accomplish its manual processing aspect by first manually selecting or adding a particular action and setting an intended processing date, and then permitting the appropriate action to be effectuated on the specified date via the automatic processing aspect. That is, after a particular action is either selected from or added to the Pending database and this action's processing date specified, the action is actually processed some time in the future via the automatic processing methodology. As has been hereinbefore described, pending actions which are stored in the Pending database are linked to persons and the like stored in the Names database through the Names record number. That is, any pending action that contains value "141" in field NUMBER of the Pending database corresponds to an action for record number 141 in the Names database. In prior art systems, however, pending actions have typically been designated by who would perform an action on a particular named entity in an equivalent of a "names" database. Thus, such a prior art computer system would schedule a specific pending action to be performed by employee ABC simply because names record number 141 would store ABC in field EMPLOYEE upon names record number 141 limited to one record in the equivalent of a Names database. Obviously, this has been a serious limitation upon the functionality of computerized scheduling systems and the like because the approach is to schedule only a single action to be performed by a single employee upon a particular named entity in the business environment being modeled. But, as is clear to those skilled in the art, frequently several employees interact with one particular entity characterizing a business environment and the like. As will be appreciated by those skilled in the art, such a plurality of pending actions scheduled to be performed by a plurality of employees for a single entity significantly improves the art and, indeed, enables business environments and the like to be accurately and effectively emulated, not merely simplistically modeled. Hence, the present invention addresses such real world circumstances by combining pertinent information stored in the hereinbefore described Actions database (see FIG. 10) with pertinent information stored in the hereinbefore described Employee database (see FIG. 9) and then by storing such information about pending actions in a Pending database. Now referring to FIG. 14, there is seen a layout of such a Pending database record. Field PEND.sub.-- DATE stores the date that a particular action is scheduled to occur in the business scenario being emulated. Fields ACT.sub.-- NUM and ACT.sub.-- DESC store the unique number and associated description of the pending action to be performed. As shown in FIG. 14, storing employees' initials in Pending field EMPLOYEE relates the pending action to the employee who is scheduled to perform the activity. Field NUMBER relates the pending action to the entity in the Names database upon whom this action will be performed. As will become clear to those skilled in the art, field PROC.sub.-- DATE stores the date that the action is actually performed. As will be hereinafter described in detail, logical field PHONE indicates whether the instant action has a Phone Format and logical field FONE.sub.-- DONE indicates whether this telephone call has been completed. These Pending fields, of course, enable all pending actions to contain information pertaining to which employee is to perform a pending action, when the action is scheduled to be accomplished, and to whom or to what such action relates. As an example, suppose that salesperson ABC sells high volume photocopier equipment and that salesperson DEF sells low volume copier equipment. While performing her duties, salesperson DEF engages in a telephone conversation with a prospect who informs her that his company is seeking a high volume copier. Since DEF has been assigned primary responsibility for this customer account, she makes an entry in the Pending database for salesperson ABC to make contact with this prospect An appropriate pending action for salesperson ABC might be a reminder to make a follow-up telephone call. The primary responsibility for this prospective customer may also change from salesperson DEF to salesperson ABC. DEF made telephone contact with this prospect because she had a pending action of "Call to meet" for that particular day. As a preferred strategy, salesperson DEF could trigger an option to transfer the prospect to salesperson ABC based on the knowledge acquired during her telephone conversation with the prospect. Under the teachings of the present invention, an Option From function would be invoked causing a transition from DEF's "Call to meet" action to ABC's corresponding "Call to meet" action, but in a short period of time thereafter, e.g., make telephone contact in 1 day. Thus, in the Pending database, the next action for salesperson ABC is the directive that this particular customer account should be called to promote sale of a high volume copier. According to the preferred embodiment, whenever such a transfer from one salesperson to another occurs, i.e., whenever the contents of field ACTION.sub.-- DESC contains the action "Transfer to another salesperson," there should be set up a concomitant action to immediately send a confirming letter or perhaps facsimile transmission thanking the prospect for conversing with salesperson DEF and indicating that salesperson ABC will be calling imminently. Of course, other actions may be established for this scenario, and any number of sets of actions may be established based upon business decision-making rules. Under the teachings of the present invention, whenever an action is specified in the Pending database, the user is asked whether the instant action is to be performed by another named person contained in the Employee database. If the user responds affirmatively, then the names of all employees stored in the Employee table as part of the Names database are displayed for selection of the salesperson to whom the transfer is being made. Once this selection is made, the present invention further inquires into the scope of the modification or transformation. As should be evident to those skilled in the art, it is necessary to ascertain whether the new employee is updated only in the Pending database or whether there should also be updates related to the action being processed, e.g., assignment of responsibility of further contact with a prospect from employee DEF to employee ABC. For the instant illustrative scenario, employee ABC is applied only for the "Call to meet" pending action because salesperson DEF actually performs the follow-up action of writing the confirming letter to the prospect. As will be understood by those skilled in the art, an action like "Assign to another salesperson" is performed by salesperson DEF and would be stored in the History table under employee DEF. According to the present invention, once a pending action is completed, the action is deleted from the Pending database and stored in a related History database. FIG. 15 depicts a layout of a History database record. The relationship between corresponding (former) records stored in the Pending database and records stored in the History database should be evident to those skilled in the art. Field HIST.sub.-- DATE stores the date that an action was completed. Fields ACT.sub.-- NUM and ACT.sub.-- DESC store the number and associated description of the action performed. Field EMPLOYEE stores identification of the employee who performed the completed; as hereinbefore stated, the preferred embodiment uses employees' initials to identify employees in a smart system taught by the present invention. Field NUMBER relates the completed action to the entity in the Names database upon whom this action was performed. Thus, under the present invention, before the telephone call to prospective customer 141, the Pending table might contain the following values for this scenario:
__________________________________________________________________________
PEND.sub.-- DATE
ACT.sub.-- NUM
ACT.sub.-- DESC
NUMBER
PHONE
PHONE.sub.-- DONE
EMPLOYEE
PROC.sub.-- DATE
__________________________________________________________________________
1/5/95 10 Call to meet
141 T F DEF
__________________________________________________________________________
For a date of Jan. 5, 1995 stored in field PEND.sub.-- DATE of the Pending database, field ACT.sub.-- NUM contains action number "10" with corresponding description "Call to meet" stored in field ACT.sub.-- DESC, for Names database record number "141" stored in field NUMBER. This entry, prior to the telephone contact being made, shows that field EMPLOYEE contains the name of employee DEF who is scheduled to make a telephone call, represented by the value "T" stored in field PHONE and that this has not yet been performed, represented by the value "F" (false) stored in field PHONE.sub.-- DONE. Since the action has not yet been performed there is no entry in field PROC.sub.-- DATE. Immediately after the telephone call to this prospective customer, the Pending table might contain the following values for this scenario:
__________________________________________________________________________
PEND.sub.-- DATE
ACT.sub.-- NUM
ACT.sub.-- DESC
NUMBER
PHONE
PHONE.sub.-- DONE
EMPLOYEE
PROC.sub.-- DATE
__________________________________________________________________________
1/6/95 10 Call to meet
141 T F ABC
1/5/95 11 Assign to
141 F F ABC
another
salesperson
1/5/95 12 Thank you
141 F F DEF
fax
1/5/95 10 Call to meet
141 T T DEF 1/5/95
__________________________________________________________________________
After the telephone call has been made by employee DEF, the processing date is recorded as "Jan. 5, 1995" in field PROC.sub.-- DATE and the value "T" (true) is stored in field PHONE.sub.-- DONE. The Pending table completely captures the sales situation regarding prospect 141: employee DEF has completed a "Call to meet" and the smart system has set up another "Call to meet" but to be made perhaps the next day by another employee, ABC. Contemporaneously, an action to assign this prospect to employee ABC instead of emplyee DEF has also been set up. According to the protocol of the business being emulated, prior to newly assigned employee ABC making this "Call to meet," a facsimile will be sent to prospect 141 by employee DEF, thanking the prospect for the time spent engaged in a telephone conversation with employee DEF. As has been hereinbefore described in detail, during automatic processing or manual processing of a smart system, once completed, a pending action is deleted from the Pending database and a corresponding record is created in the History database. Thus, assuming that all of employee DEF's actions relative to prospect 141 have been completed, for this prospect, there is only one pending action to be performed by employee ABC:
__________________________________________________________________________
PEND.sub.-- DATE
ACT.sub.-- NUM
ACT.sub.-- DESC
NUMBER
PHONE
PHONE.sub.-- DONE
EMPLOYEE
PROC.sub.-- DATE
__________________________________________________________________________
1/6/95 10 Call to meet
141 T F ABC
__________________________________________________________________________
Since the contents of field PHONE.sub.-- DONE is false and there is no date stored in field PROC.sub.-- DATE, the phone action is still pending. After being processed by a smart system, these completed pending actions have been deleted from the Pending database and corresponding records have been created in the History database:
______________________________________
HIST.sub.-- DATE
ACT.sub.-- NUM
ACT.sub.-- DESC
NUMBER EMPLOYEE
______________________________________
1/5/95 11 Assign to 141 DEF
another
salesperson
1/5/95 12 Thank you 141 DEF
fax
1/5/95 10 Call to meet
141 DEF
______________________________________
As should be clear to those skilled in the art, a true value stored in logical field PHONE indicates to the smart system that the action corresponding to Phone Format. To satisfy real world requirements, a smart system constructed according to the preferred embodiment treats a Phone Format differently from other Formats: an action having a Phone Format is preferably sent to a Call Processing screen for specifying the date through which telephone calls will be made to Names entities. After a phone call is completed, under the present invention, a follow-up action must be chosen in order to remove this completed phone action (Pending action record) from the telephone processing screen. The user may then proceed to the next scheduled phone call. Once a pending call is completed, the smart system changes the value stored in logical field FONE.sub.-- DONE from "false" to "true." Thus, a smart system contemplated by the present invention completely portrays the dynamics of a predefined business environment and the like, and continuously emulates its operation. As illustrated in this example involving a single prospect and two employees, for a hypothetical pending time frame of Jan. 5-6, 1995, the Pending and History databases, coordinated with the related Names, Employee and Actions tables, emulate the sales scenario with minimal salesperson or management intervention. As has been hereinbefore described the Actions database stores the action numbers and corresponding descriptions for all actions that characterize a particular commercial business environment and the like. Referring now to FIG. 13, the interrelationships between Names table 55, Pending table 65, Actions table 50, Employee table 60 and History table 70 are depicted for this illustrative example. The unique record number of a person stored in the Names table comprises the linkage to the Pending and History tables. The action number stored in the Pending table is linked to the unique action number stored in the Actions table along with the description and other relevant information for this particular action. Thus, for a "Call to meet" action, it is shown to be a telephone call with a cost of $0.5. The unique employee number stored in the Employee table comprises the linkage to the Pending and History tables for a particular salesperson and the like. Another important and innovative aspect of the present invention is the Update Fields feature. When an action is processed either by a user or automatically during "Smart Follow Up" as herein described (see FIGS. 22A-F), the present invention teaches a capability to change the contents of one or more fields in the Names database. As will be appreciated by those skilled in the art as a significant departure from the prior art, a purpose of this Update Fields feature is to automate record editing. As an example, suppose that a sales manager regarded any person who had met one of his sales people as a prospect. Suppose further that this manager wants to keep a tally of the | ||||||