Related Application
This application is related to co-pending U.S. patent application Ser. No. 08/252,921, filed on Jun. 1, 1994, Attorney Docket No. DAVOX-119XX, entitled A Method for Allocating Agents with Predetermined Attributes To A Telephone Call Campaign, assigned to the assignee of the present invention and fully incorporated herein by reference.
Field of the Invention
This invention relates to telephony management systems, and more particularly, to a universal telephony application client that is dynamically configurable from a profile for a given telephone call campaign.
Background of the Invention
As is known in the art, many businesses use telephony system including automated call distribution systems and predictive dialers to process incoming calls and outgoing call records. Telephone system resources such as telephone lines and agents must be managed in real time to process call records for outgoing calls, and to process incoming calls. Such telephone system resource management has been performed by individual agents or agent supervisors. However, in telephony systems, such resources are handled automatically by the telephony system to allocate the resources and handle events to allow calls to be processed.
As is also known, one method of managing such resources is by creating a process on the telephony call distribution platform to handle a single outgoing call record or incoming call. The process or thread only handles a single call record. The process obtains system resources such as trunk lines and agents, and follows the processing of the call record or incoming call until completion. The process terminates when the telephone call or processing of the telephone call is complete. Many processes or threads can run at the same time, each handling a single call record or incoming call.
There are many parameters which are required to process outgoing or incoming calls for each specific call campaign or series of planned telephone calls. Call campaigns all have different requirements, and specifically designed processes are needed to handle the different requirements unique to each call campaign. Also, the processing of incoming calls and events is different from outgoing call campaigns and requires processes that are capable of handling the different requirements. Therefore, specific incoming and outgoing call processes must be individually created for each call campaign and designed to meet the specific requirements of that call campaign. Such prior art processes are often hard coded or programmed, which requires a considerable amount of time to program and compile to create the campaign specific process. Most importantly, such processes cannot be modified in real-time, to conform to the requirements of a call campaign then being executed.
Accordingly, what is needed is a universal telephony application process which is general enough for most call campaigns, but can be specifically and dynamically modified for the requirements of each individual call campaign.
Summary of the Invention
In accordance with the present invention, a method for creating a universal telephony application client (TAC) or process that can be utilized as is or configured for a specific call campaign is provided. Upon beginning a campaign, the universal TAC is initialized from a campaign configuration database specific to a call campaign. The universal TAC then processes the call records according to the parameters provided in the campaign configuration profile.
The campaign configuration is modifiable before a call campaign, or at the commencement of a call campaign, or at any time during a call campaign. All TACs created subsequent to modifying the campaign configuration profile will include the new parameters.
A universal TAC may be started by one of the campaign managers to process a call record for an outbound dialing application or to process an incoming call, or it may be started by a system wide event server in order to perform some programmed response to the occurrence of an event. Universal TACs may also be started by other entities to accomplish a variety of other chores such as for controlling the operation of other system servers .
Description of the Drawings
These and other features and advantages of the present invention will be better understood by reading the following detailed description, taken together with the drawings wherein:
FIG. 1 is a block diagram of a telephony system capable of mixing inbound call processing with outbound dialing automation and for providing the telephony application client of the present invention;
FIG. 2 is a more detailed block diagram of the Telephony Application Client according to the present invention; and
FIG. 3 is a flow chart illustrating the method for creating and initializing a universal TAC according to the present invention.
Detailed Description of the Preferred Embodiment
The universal telephony application client (TAC) or process in accordance with the present invention is utilized by a telephony platform system as described by co-pending U.S. patent application, Attorney Docket No. DAVOX-119XX, assigned to the assignee of the present invention, and incorporated herein by reference. The universal telephony application client or process is utilized to control the handling of call records (outgoing calls), incoming calls and other events that occur in the system.
Referring now to FIG. 1, a telephony platform system 10 is provided. A telephone resource server 70 interfaces with digital communication server 14 which handles telephone lines coming from central office 18, and also interfaces with a plurality of agent workstations 16a-16n. Telephone resource server 70 comprises many subsystem, including outbound campaign manager 62, inbound campaign manager 64, trunk resource manager 66, agent resource manager 74, and system server 71. Telephony application client (TACs) 72 are utilized by the telephony system 10 to control utilization of system resources to process call records and incoming calls.
A user initiates a specific call campaign to process either incoming or outgoing calls. Each campaign has a profile or configuration database which sets up parameters to direct how the campaign shall proceed. One of the parameters is whether a specifically designed TAC may be used, or can a universal TAC be used. Upon commencing a campaign, the user may modify certain parameters, some of which may modify the TACs created for that campaign. These parameters will be stored in the TAC initialization profile as a database, step 210, FIG. 3. As shown in FIG. 2, the user 100, interfacing through a campaign manager application as a graphical user interface 46 running supervisor station 24 modifies database 52 to create a campaign specific configuration database or profile 102. This profile contains campaign specific information as shown in Table 1 below. Additionally, the campaign manager application 46 is also responsible for generating and maintaining a campaign resource database 104 which includes a unique record identifier number which allows the TAC 72 to retrieve a given record under control of the inbound or outbound campaign manager 62, 64.
The campaign resource database 104 is independent of record layout or format and thus, can interface with many types of record formats or databases available from a host computer. This database contains a mapping table which tells the TAC where a given record is, such as the customer telephone number to be dialed. Thus, the mapping table indicates the location of a record in a host computer regardless of the format of that record.
When user 100, through campaign manager 46 directs inbound or outbound campaign manager 62/64 to begin a campaign, inbound or outbound campaign manager 62/64 directs the TAC Daemon 106 to start a universal TAC 108. The universal TAC initializes itself by reading the campaign configuration database 102 containing information on how the campaign calls are to be handled, such as shown in table 1 and subsequently awaits any record identifiers of records to be processed.
As a call campaign commences to run, step 212, the outbound campaign manager requests TACs to be created to process call records, or if it is an inbound campaign, the inbound campaign manager requests TACs to be created to handle incoming calls, step 216. A TAC is started with a single input parameter. This parameter may be a record ID, an event ID, or some other unique ID with which the TAC may query a campaign resource database 104 to obtain further information about the call to be placed or the incoming call to handle.
A TAC thread 110a, 110n is created for each record to be processed. A TAC thread is one execution of the TAC for a given call record. Multiple TAC threads 110a, 110n will generally be executing simultaneously. Each TAC thread controls or performs the operation as directed by the inbound/outbound campaign manager such as dialing, etc.
At step 218, the universal TAC commences to operate as a process or thread on the telephone system platform to handle the requested event. One processor or thread is operative for each event (call) to be handled. In the preferred embodiment, the universal TAC is implemented as a Unix lightweight process which is well known in the art, and which minimizes system memory and process scheduling requirements. At step 220, the created universal TAC accesses the initialization profile based on the ID parameter, for customizing parameters. For example, such parameters could specify how many rings to allow before a call is considered a no-answer, how long to wait before redialing a busy number, and how many times to retry dialing a busy number. In the preferred embodiment, there are many possible parameters as shown in Table
Any of these parameters may also be modified while a campaign is running. If a parameter is modified, the new value is stored in the initialization profile, step 214.
At step 222, the customized universal TAC handles the call or event, including requesting resources from resource managers, such as trunk lines for calling from the trunk resource manager, and agents from the agent resource manger. Each TAC thread interfaces with the TAC master 112 to control operation of one or more system servers 114a-114n such as the trunk resource manager server 66, workstation application server 76, agent resource manager server 74 and telephony application server 78. As can be clearly seen from FIG. 2, each TAC thread such as TAC thread 110a may control multiple servers 114a-114n. The servers 114a-114n service the call record as directed by the TAC thread requesting service. The universal TAC process can also start user selected specific TACs to handle specific situations unique to a call campaign. The universal TAC will suspend while the specific TAC is running, and when the specific TAC terminates, the universal TAC continues processing. A TAC thread will handle a call record or call to completion, performing redials and wrap-up of completed calls as needed. Once the TAC completes its processing, the TAC thread notifies the process which started it and then terminates, step 224.
Such universal TACs are usable by many campaigns thus avoiding the problem of many different specific TACs required for each individual campaign.
Modifications and substitutions by one of ordinary skill in the art are considered to be within the scope of the present invention which is not to be limited except by the claims which follow.