Method and apparatus for optimizing response time to events in queue

Abstract

A system for optimizing response time to events or representations thereof waiting in a queue has a first server having access to the queue; a software application running on the first server; and a second server accessible from the first server, the second server containing rules governing the optimization. In a preferred embodiment, the software application at least periodically accesses the queue and parses certain ones of events or tokens in the queue and compares the parsed results against rules accessed from the second server in order to determine a measure of disposal time for each parsed event wherein if the determined measure is sufficiently low for one or more of the parsed events, those one or more events are modified to a reflect a higher priority state than originally assigned enabling faster treatment of those events resulting in relief from those events to the queue system load.

Description

CROSS-REFERENCE TO RELATED DOCUMENTS

The present includes a machine-readable medium that is enhanced in this embodiment with an estimated disposal time (ETD) scanning application 1403, which is adapted to access queue 1401 and determine if there are any low priority events that could be resolved very quickly within the system.

Application 1403 works in conjunction with WFMP software to further optimize management of content within queue 1401. WFMP, for example, accesses queue content to determine if a resource re-allocation is appropriate to better and more expeditiously handle events in queue while EDT scanning expedites processing of lower priority events that can be handled swiftly without significantly taxing existing resources from responding to higher priority events.

Application 1403 has a direct connection to a rules base 1404 that is also connected to LAN 1206. Rules base 1404 is adapted, in this embodiment, to serve rules created for tokenizing different types of media events according to what event-content and state matter that may need to be considered when trying to determine whether or not the event can be handled swiftly within the system. Rules to this regard will vary according to media type of event and will govern what specific information blocks from the actual event will be available in token form, in addition to the state information normally included in a token that represents an actual event. For example, each token event has minimally presence and property-state information associated with it including a media type, an origination ID and destination request ID, and state information regarding the purpose of the event. Token events will have differing presence and state information associated with them according to media type, priority assigned, and so on.

EDT application 1403 may rely on some of the normal data that is already present in token events like media type and purpose of event information. Additionally, application 1403 is adapted to parse certain data that may be added to the normal token information when the actual event is first tokenized. It is logical to assume then that the process of token generation as practiced in this example by processor 1410, and by queuing system 1407 using generator 1403, is augmented by rules stored in rules base 1404, which is accessible to both processor 1410 and to system 1407 over LAN 1206. In another embodiment, direct network connections may be provided between the participating components to alleviate some LAN traffic.

To illustrate better the types of content that may be embedded into a token and utilized by application 1403, assume that a media type e-mail, for example, has normal tokenized blocks, sender, recipient, time stamp, and subject line. Assume that the subject line reads, “request for information about computer product A”. Typically, the e-mail may receive a relatively lower priority than, for example, a purchase order ready for processing. If that e-mail resides in queue 1401 along with a substantial number of e-mails that are for purchase orders, then those of a higher priority may continually bump that particular e-mail. Application 1403 accesses queue 1401 and parses the token information of the e-mail and consults with rules base 1404. In the process, application 1403 determines that the e-mail requesting information can be automatically handled in seconds by sending a quick response with an electronic brochure attached. Application 1403 can reassign the priority to high and can re-write any handling protocol for that e-mail effectively screening it for alternate automated processing and taking it out of the main queuing system.

Application 1403, in a preferred embodiment, accesses queue 1401 periodically and processes a plurality of new incoming events simultaneously in batch operations. Parsing the token information for each event enables the application to sort according to which events are lower priority events of what media types and or original destination queue assignments. From these events, further parsing determines which of those events can be alternately processed or otherwise handled efficiently without causing latency to higher priority events. If, citing our previous e-mail example, there is no subject line, or a subject line that reads “request for information”, which is not product specific, then application 1403 will require further information to be included in the token version of the event in order to consider it for evaluation. Therefore, when the e-mail is tokenized, generator 1403 determines that some of the body of the e-mail message should be included in the token version to compensate for the lack of a subject line or of a specific subject line that reveals a purpose for the event. In this way, application 1403 parses the included message content to determine the purpose for the event.

In a preferred embodiment, EDT application 1403 uses INP protocol to communicate with queue 1401, which is also INPP enabled. If normal priority assignments are made during tokenizing, queue 1401 is, in one embodiment, configured according to a priority threshold to report using instant messaging to application 1403 when there are a significant number of lower priority events in queue that should be accessed for processing according to EDT rules. In this case much sorting through events is eliminated.

Rules base 1404 is flexible in a preferred embodiment so as to provide different sets of rules for tokenizing different media types. Rules base 1404 also contains rules that govern EDT thresholds that can very dynamically according to currently allocated resources. For example, if a number of telephone calls having a low priority can be processed by playing an automated statement containing a specific information requested, and the collective estimated time and resource to handle those calls falls below a time and resource threshold value imposed on an IVR system then all of those calls can be promoted out of the main queue and can be immediately processed without conflicting with IVR interactions of a higher priority.

The end result is that more interactions get processed in a shorter amount of time. Potential clients that originally expect to have a longer wait in queue are treated with a higher priority if their EDT values are acceptable to the system resulting in more satisfaction with service and potential sales increases in new business. In the event of diverting some of the events to automated systems, agents have more time to focus on the events that require their attention and do not have to manually redirect so many events.

In an alternate embodiment, queue 1401 is not a virtual queue, but a real master queue as previously described. A real master queue, if a DNT queue, can include most if not all DNT events supported by the system. In this case, queuing system 1407 may comprise specific agent queues, queues shared by agent groups, and specific system queues. No tokenizing or virtual queuing is required in order to practice the present invention. In the event that queue 1401 is a real queue, application 1403 accesses queue 1401 as before and sorts events by media type and priority and parses only those of a lower priority to determine if those events can be handled swiftly according to EDT rules. Those events that meet the criteria are promoted to the agent/system specific queues ahead of some of the higher priority messages in a load-balanced fashion to minimize delay in handling of the higher priority events.

Parsing of events in a real master queue 1401 is still governed by rules served by rules base 1404. Those rules and methods of parsing depend largely on media type represented in queue 1401. For example, if queue 1401 is a COST queue, then it holds telephone calls, fax requests, voice mail messages, and other COST-dependant events. In this case, application 1403 can parse DNIS, ANIS, caller ID, destination ID, call priority assignment, and call purpose data if previously solicited from the caller by IVR interaction. In a COST queuing embodiment certain data like solicited information can be attached to the call as parse able digital data. Also in this case COST queue 1406 may not be required and queue 1401 would be, instead part of a telephony switching and routing system like switch 1405 and processor 1410. Application 1403 does not determine priority but can reassign priority if EDT values warrant such a reassignment.

Types of criterion that might be developed and considered when estimating a disposal time for an event include relatively simple state representations such as, for e-mails or text messages, a shorter text body contributes to a probability of faster processing than a long text body (message size). Also whether or not the e-mail or text message includes an attached document can be considered. Message subject lines, IVR selections made, and interactive options selected can also be used to estimate disposal time if those subject lines and selected options equate to known business processes conducted within center 1401.

Predictive analysis based on historical account can be used in some cases to predict EDT. For example, for an IP chat request, a historical EDT average value of that request originator's past chat sessions can be used to predict a probable disposal time. If a particular client exhibits a lower EDT average for chat sessions then he or she can be routed with a higher priority.

It is noted herein that some event types will have no specific priority assignments. In this case, it is possible that application 1403 assigns an original priority state based on EDT. However, in a preferred embodiment, the goal is to alleviate the queue of persistent low-priority messages that typically wait longer than other more-important messages. Accumulation of such lower priority messages can clog the queue and may begin to slow processing of the higher priority events. The method of the present invention may be practiced, as well, on individual real queues in parallel without the presence of a master queue. There are many possibilities.

FIG. 15 is a process flow diagram illustrating steps for practice of the present invention utilizing a virtual queue. At step 1500 incoming events are received in queue. Step 1500 is an ongoing step and applies to all supported media events received within the communications center. At step 1501 received events are tokenized and virtually queued in a master virtual queuing system analogous to queue 1401 described with reference to FIG. 14 above. At step 1501 a rules base (illustrated in association with step 1501) analogous to rules base 1404 described further above is consulted for the rules of tokenizing each type of event. Rules for each media type represented may very widely. IMPP protocols may be used when creating a token event such that the reportable particulars used for EDT processing are contained in an IM that can be accessed or sent to the EDT application for processing. Likewise, other standard machine languages can be used and attached to or integrated with event tokens. Furthermore, automated queue reporting can be set up so that when a number of tokens fitting EDT criteria for processing accumulate in queue, the queue can report the status to the EDT application to initiate batch processing.

In this case, it is assumed that the EDT application will periodically access the queue to determine if there are any tokens meeting processing criteria. Therefore at step 1502 a pre-scanner application accesses the virtual queue for processing. At step 1503 the pre-scanner sorts the tokenized events having a suitable low priority and then scan them for content related to EDT possibilities.

At step 1504 for each token event the EDT application attempts to determine if the event content meets queue priority promotion criteria for quick resolution without taxing current resources. At this step the rules base illustrated herein in association with steps 1501 and 1504 is consulted. Each media type may have a separate set of rules for handling according to stated purpose, which may have been added to the event token during the token phase at step 1501. Step 1504 can be initiated upon isolating a batch of event tokens with some tokens failing to meet criterion and some tokens meeting the criterion.

For those tokens meeting the EDT criterion, the EDT application extracts them from the virtual queue at step 1505 and re-assigns their priority to a higher priority at step 1506 at which point the events may be re-deposited in the virtual queue and processed according to their new priority states. In some embodiments, the EDT application also overrides the handling instructions for those events according to preferred methods known in the system. By extraction, it is meant that the EDT application accesses and takes write control over each event and not necessarily removing the event from queue positioning. The token events that fail to meet criterion at step 1504 are passed over and retain their original disposition instructions and priority states.

In a preferred embodiment of the present invention, the EDT application tags those events that have already been sorted and processed so that upon a next access, the same events are not re-processed. Step 1502, 1503, and 1504 is an ongoing loop wherein only those events that succeed in meeting EDT criterion are modified for quick resolution.

In one embodiment, the EDT application causes instant routing of any events that succeed in meeting EDT criterion for quick resolution. For example, a plurality of e-mail messages that can be easily handled automatically and otherwise would sit in queue at a low priority can be diverted from human response procedure and instead be automatically processed. In this case, the EDT application sends an overriding request to the routing system in charge of those e-mails, the request containing new instructions for routing them to the appropriate automated e-mail response system. At the same time, the tokens representing those e-mails are deleted from the virtual queue. The messaging from the EDT application-host server to the routing system can be of the form of an instant message requesting the alternate processing for the identified events waiting.

WFMP software described with reference to FIG. 12 above uses EDT results as well in planning resource availability. For example, if the EDT application determines that a number of events of a particular media type can be handled very quickly by a specific automated system for example, WFMP software can be notified to cause allocation of the desired system resource to handle those particular events effectively diverting them out of the live-agent system.

One with skill in the art will recognize that the process steps illustrated herein may vary somewhat in order and description depending on particular application with out departing from the spirit and scope of the present invention. For example, instead of batch processing as described with reference to steps 1502 through 1504, the process may be practiced per event. In this case EDT software would have constant access to the virtual queue and evaluate events as they arrive and are pre-assigned to destinations.

FIG. 16 is a process flow diagram illustrating steps for practice of the present invention utilizing a real master queue. At step 1600 incoming events arrive within the communication center and are queued in a master queue. It is assumed in this embodiment that the master queue is a real queue and that events will be promoted out of the master queue into final destination queues according to priority and availability. At step 1601 the events in the master queue are sorted according to media type and prioritized for normal handling according to routing rules that apply.

At step 1602 the pre-scanner application accesses the master queue. As was described above with reference to step 1502, this step is periodic in a preferred embodiment. At step 1603 the pre-scanner evaluates events for media type and content including priority assignment In one embodiment only low priority events below a certain pre-set priority threshold are evaluated eliminating the need for the pre-scanner to access every event in queue. In this embodiment, the master queue can report to the EDT application when there are a number of events for evaluation.

From those events under evaluation, at step 1604 it is determined which of those events meet or fail the EDT criterion for quick resolution probability. It is noted herein that some events will lend to a certainty result for quick resolution while others will lend only to a probability result for quick resolution. At step 1604 a rules base (drawn in association with the step) is consulted for each event evaluated. For those events that only a probability factor is produced it is possible that they will, in fact not be able to be quickly resolved. The system makes an intelligent guess based on information contained in or associated with the event. For example, if the event is an IP telephone call from a certain repeat customer and in the past such calls were handled relatively quickly, then a probability value for a quick resolution would be generated.

At step 1605, those items that do not meet the EDT criteria for quick resolution are simply removed from consideration and preferably tagged as having been processed so that they are not re-evaluated. Those events that do meet the criterion for quick resolution, in one embodiment are physically extracted from the master or general queue at step 1606 and then deposited at step 1607 into the destination-appropriate final queues for event handling. In this case, EDT actually distributes the events to the final destination queues based on results of evaluation and immediate availability information regarding the final destination queues.

In another embodiment events are not physically extracted from the master queue, but are re-assigned to the priority status that effects their promotion and subsequent distribution into the appropriate final destination queues for handling. As previously described, based on evaluation results per event, the EDT application can re-write the handling protocol for an event and change the original destination queue assignment to a new assignment. An example would be to divert an instant message session request from one live-agent group operating a shared queue to an automated system queue where the instant message will be answered by an automated response message effectively diverting or re-directing the event from one destination to another (internal re-routing).

In the event that a general master queue embodiment is practiced it is likely that there will be separate master queues, one for COST events and one for DNT events. In this case, the EDT application server would access both queues and process events there from simultaneously in a multitaskable fashion. It is important to note herein that EDT software may, instead of periodic access ability, have constant access connection to the master queue and may process events as they arrive instead of in batch without departing from the spirit and scope of the present invention. Moreover, if priority assignment is practiced, the queue may be configured to report which events queued were assigned a priority level under a pre-set threshold for evaluation to EDT software. Such reporting may be configured to occur when the queue has enough events therein to surpass a certain pre-set threshold of a number of events having low priority. There are many possibilities.

FIG. 17 is a block diagram illustrating the pre-scan software application of FIG. 14 according to embodiments of the present invention. Application 1403 is described herein as an EDT application and in some instances as a pre-scanner application because of its main function of pre-scanning real or token events for indication of quick resolution possibilities. Application 1403 has a plurality of modules that enable various scanning operations on token or real event data as well as a number of system interfaces.

A virtual/master queue interface 1700 is provided to application 1403 and adapted to enable application 1403 to access a main virtual or real data queue for the purpose of processing events there from. Interface 1700 can be a software interface or a hard-wired server port or other network connection interface as required according to specific hardware architecture used.

An agent/system queue interface 1702 is provided to application 1403 and is adapted to enable access to real queues, final destination queues, system queues, and any other queues held separately from master or main queues. Port 1702 is optional in that in one application events selected for promotion according to EDT criterion are re-assigned higher priority levels to induce quicker response, but are physically left in main or general queues, virtual or real until such priority reassignments cause event promotion (real) to final destination queues or final routing and handling according to token progression (virtual) using normal system paths.

An interface to a rules base 1701 is provided to application 1403 and is adapted to enable consultation with system and enterprise directed rules which govern decisions made during evaluation of events or event tokens and, which may also be consulted during the token generation process in a virtual queue embodiment. Rules contained in such a rules base as described above include those that might relate to probability of quick resolution: according to certain discernable states. For example, a short text message with no attachment will receive a higher score than a long text message including one or more attachments. An IP voice call placed from a later time zone may receive a higher score than one originating locally. Detection of the presence and availability of special resources like foreign language resources just coming on-line as identified through IMPP by WFMP software might precede an evaluation of like foreign language-seeking events. In this case, the evaluated events receive a higher score than English language requests because of the available resource for quick resolution.

There are many possibilities for rules creation, modification, management, and implementation. Some basic rules may cover simple content states such as included subject line (e-mails), stated purpose (IVR solicitation telephone), and so on. Implementation of these rules may be as simple a s “immediately divert all ‘found’ e-mails waiting of priority lower than “6” containing subject line “request for information” from live agent handling to automated system response. More complex rules are probability-based and may include accesses to other database information such as historical performance records. One example implementation might be “re-assign priority from ‘5’ or lower to ‘9’ for all chat requests with a “historical EDT average” of lower than 6 minutes. In this particular case, there may be some re-assigned chat requests that will actually take more than 6 minutes to resolve. However the new time of resolution will be figured in to their historical EDT average figure to be considered the next time they log-in to a chat room.

A module for event-type identification and sorting 1703 is provided to application 1403 for the purpose of identifying various different media types of events and sorting them accordingly using a parsing engine 1704. Engine 1704 is adapted to read from header information in a token or real event. Module 1703 interfaces with a master or virtual main queue through interface 1700. A module for event-type state evaluation 1705 is provided to application 1403 and adapted to determine type of event or token event and current priority state assigned using a parsing engine 1706. Engine 1706 is adapted to read system-assigned state data including routing information, origination information, and final destination information. Module 1705 interfaces with the main virtual or master queue through interface 1700.

An event content evaluation module 1707 is provided to application 1403 and is adapted to read message, using a parsing engine 1708 content including subject lines, selected body text, interaction result data, and any other parse able content data included in a token event or embedded in a real event. Module 1707 interfaces with a main or master queue in concert with the earlier described modules through interface 1700 and also interfaces to a rules base through interface 1701 to access rules regarding priority state and found content. It is noted herein that modules 1703, 1705, and 1707 may be provided as a single integrated module using a same parsing engine without departing from the spirit and scope of the present invention. The inventor seeks to logically separate function only for illustrative purpose.

A priority configuration and event promotion module 1709 is provided to application 1403 and is adapted by way of a calculator 1710 to compute EDT probability factors or scores for token events or real events and to effect priority reassignments and to initiate queue promotions (where required). Module 1709 has interface to a rules base through interface 1701 and an optional interface to real agent and/or system queues through interface 1702 in the event of direct queue promotion activity that bypasses normal queue progression paths. Module 1709 considers information results provided by modules 1705, and 1707 to perform per-event calculations to receive implementation results leading to any direct actions that might be taken. Depending on rules, token or real events may fail evaluation during evaluation by any one of the described modules. Likewise, an event or token event may succeed evaluation before reaching the point of evaluation by module 1707 effectively bypassing event content evaluation. In one embodiment, module 1707 is always invoked if prior evaluation fails to retrieve enough information to reach a decision. In this case content is parsed to gain the additional information that may reveal a likely probability for short resolution.

It will be apparent to one with skill in the art that the method and apparatus of the present invention can be distributed to more than one machine having connection to the routing network without departing from the spirit and scope of the present invention. For example, modules 1703 and 1705 may be provided as client reporting modules and integrated with queue software and hardware. In this case, modules 1707 and 1709 might form a parent application residing on a separate server connected to the routing network. Likewise, there may be more interfaces to external information sources than those illustrated herein. For example, an interface to a customer information system (CIS) server and/or to a historical database might be incorporated herein to enable application 1403 to consider other information used to make decisions. This can be especially important when one factor is a historical EDT average accessed and retrieved for priority reassignment considerations.

The computing method of the present invention is in a preferred embodiment performed by algorithm including score calculation. There is more than one computation method that might be used. For some situations, a simple comparison of state information to applicable rule for match will be sufficient for priority-reassignment. In more complex considerations, a series of scores for different blocks of parsed information can be calculated for each event and weighted against a rules set to produce a final result that will determine if the event or token event will be priority-modified and, perhaps to what specific level of priority or promotion from a plurality of existing levels the event or event token will receive.

In still another embodiment of the present invention, there is no original priority assignment to queued messages. In this case EDT evaluations are performed on all queued messages no matter what the queue status is and those that can be handled quickly are promoted first to alleviate overall queue latency by processing those events that can be handled easily and quickly without taxing normal agent response resources.

The method and apparatus of the present invention has been demonstrated herein to have patentable weight in a variety of different embodiments and therefore should be afforded the broadest possible scope under examination. Only the claim language provided below limits the spirit and scope of the present invention.

Claims

1. A system for increasing transaction queue efficiency comprising:

a computerized server having software stored on and executing from a machine-readable medium, the software comprising:

a first portion of instructions for implementing a queue for governing order of processing transactions;

a second portion of instructions for reordering and/or removing one or more of the transactions from the queue;

an electronic router coupled to the computerized server for routing at least one of the transactions to a final destination;

wherein the second portion of instructions is for periodically accesses accessing stored information concerning individual ones of the transactions, using rules separately stored determines from the information, determining an estimated disposal time (EDT) for the transactions considered, and for particular ones of the transactions having a determined the estimated disposal time lower than a pre-stored time, either moves those moving the particular ones of the transactions ahead of other ones of the transactions in the queue or removes those removing particular ones of the transactions from the queue,

wherein the estimated disposal time is an estimate based on historical averaging of previous measurements for an originator of a transaction of a same type.

2. The system of claim 1 wherein the computerized server is a work force management and planning server enhanced with the addition of the software application.

3. The system of claim 1 wherein the queue is a virtual message queue for a communication center.

4. The system of claim 1 wherein the queue is a telephony queue.

5. The system of claim 1 wherein the software application includes at least one parsing engine instructions for parsing transaction information.

6. The system of claim 1 wherein the software application includes an interface to a historical data repository.

7. The system of claim 5 wherein the information parsed includes one or more of event type, event status in queue, event routing information, and event origination information.

8. The system of claim 1 wherein the disposal time determined is an estimate based on known procedure for handling the event transactions.

9. The system of claim 1 wherein the disposal time determined is an estimate based on historical averaging of previous measurements for the same originator of an event of a same type.

10. The system of claim 1 wherein some events of the transactions are immediately promoted from the queue to an appropriate final destination queue.

11. The system of claim 1 wherein events certain ones of the transactions that are modified to reflect a higher priority state are immediately routed to their final destinations.

12. A method for increasing transaction queue efficiency comprising the steps of:

(a) implementing, by a processor, a queue for governing order of processing transactions on a computerized server having software stored on and executing from a machine-readable medium;

(b) periodically accessing, by the processor, stored information concerning individual ones of the transactions;

(c) using rules separately stored from the information, determining, by the processor, an estimated disposal time (EDT) for the individual ones of the transactions considered and, wherein the estimated disposal time is an estimate based on historical averaging of previous measurements for an originator of a transaction of a same type;

(d) for one or more transactions of the individual ones of the transactions having a determined the estimated disposal time lower than a pre-stored time, either moving those, by the processor, the one or more transactions ahead of other ones of the transactions in the queue or removing those the one or more transactions from the queue; and

(e) routing, by an electronic router coupled to the processor, at least one of the transactions to a final destination.

13. The method of claim 12 wherein the computerized server is a work force management and planning server enhanced with the addition of the software application.

14. The method of claim 12 wherein the queue is a virtual message queue for a communication center.

15. The method of claim 12 wherein the queue is a telephony queue.

16. The method of claim 12 wherein the software application includes at least one parsing engine for parsing transaction information.

17. The method of claim 12 wherein the software application includes an interface to a historical data repository.

18. The method of claim 12 wherein the information parsed includes one or more of event type, event status in queue, event routing information, and event origination information.

19. The method of claim 12 wherein the disposal time determined is an estimate based on known procedure for handling the event transactions.

20. The method of claim 12 wherein the disposal time determined is an estimate based on historical averaging of previous measurements for the same originator of an event of a same type.

21. The method of claim 12 wherein some events of the transactions are immediately promoted from the queue to an appropriate final destination queue.

22. The system method of claim 12 wherein events certain ones of the transactions that are modified to reflect a higher priority state are immediately routed to their final destinations.