Method and system for scheduling a customer service callback

A method and system for scheduling a callback time for customer service. The system calculates estimated handling resources for a customer interaction system (14) and forecasts a customer service transaction workload for the estimated handling resources of the customer interaction system (14). The system then determines the scheduled callback time based upon the estimated handling resources and the forecasted customer service transaction workload.

CLAIM OF PRIORITY

This application is a U.S. National Stage Filing under 35 U.S.C. 371 from International Patent Application No. PCT/US2003/032043 filed on Oct. 8, 2003, and published in English as WO 2005/045723 A1 on May 29, 2005, which applications are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates generally to the field of customer service callbacks and, in one exemplary embodiment, to offering a callback time based upon estimated handling resources and forecasted customer service transaction workloads.

BACKGROUND OF THE INVENTION

A number of businesses offer their customers customer support via the telephone. Often, the customer service agents are busy so the business places the customer's telephone on hold and places the customer's request for service in a queue from where such requests are retrieved as customer service agents become available. Once retrieved, the customer's phone is taken off hold and the customer is able to talk to an agent. In some instances, the customer is even informed of how long she can expect to wait on hold. Oftentimes this wait time is based on past data corresponding to average wait times associated with the customer's position in the queue. In other instances, the customer is informed of the estimated wait, the request for service is placed in a queue, but the customer is offered a callback rather than being placed on hold. If the customer accepts the offer to be called back, both the system and the customer hang up but the system continues to keep track of the customer's position in the queue. When the customer's request eventually comes to the front of the queue, the system initiates a phone call back to the customer. A problem with this scheme is the estimated wait is tightly coupled to the condition of the queue at the time of the initial call. Further, callback attempts are unlikely to occur at a time dose to the time implied by the estimated wait. Due to variations in resources, staffing, and transaction types, it is typically the case that, when the customer's service request actually arrives at the front of the queue, the actual wait time has substantially deviated from the estimate given to the customer. Lastly, the customer is only given the choice of accepting or rejecting the callback offer. The customer has no control over the schedule of when a callback will be attempted

SUMMARY OF THE INVENTION

According to one aspect of the present invention, there is a provided method of scheduling a callback time for customer service. The method includes calculating estimated handling resources for a customer interaction system, forecasting a customer service transaction workload for the estimated handling resources of the customer interaction system, and determining the scheduled callback time based upon the estimated handling resources and the forecasted customer service transaction workload.

DETAILED DESCRIPTION

In general, embodiments described below feature a customer interaction system that can offer and schedule a callback time based upon calculating estimated handling resources for a customer interaction system and forecasting a customer service transaction workload for the estimated handling resources of the customer interaction system. The customer interaction system then determines the scheduled callback time based upon the estimated handling resources and the forecasted customer service transaction workload.

FIG. 1is a block diagram illustrating a system10to offer and schedule a callback time for customer service, according to an exemplary embodiment of the present invention. The system10includes a customer machine12and a customer interaction system14that communicate via communications network16. The communications network16may be embodied as the Internet, a LAN (local area network), a WAN (wide area network), PSTN (public switch telephone network), frame relay, ATM (asynchronous transfer mode), satellite communications, Wireless communications, combinations thereof, or any other network equipment or protocol that enables electronic communication between the above described network entities. The customer machine12enables the customer to access customer support services that are provided by the customer interaction system14.

The customer interaction system14includes an enterprise contact machine18, at least one media switch20, and a resource group22. The customer interaction system14may, for example, provide customer service support for customers in a given marketplace. For example, a customer may purchase a digital camera and experience technical difficulties that require customer support. The customer then may choose to contact customer support through the customer interaction system14via the communications network16. A customer communication is received at a media switch20and processed by the enterprise contact machine18. In one embodiment, the customer waits in a queue for a connection to the resource group22. In another embodiment, the customer chooses to accept a callback time for a connection to resource group22offered by the customer interaction system14.

FIG. 2is a block diagram illustrating software and hardware components of the customer interaction system14and the customer machine12, according to an exemplary embodiment of the present invention.

In addition to other software and hardware components that are not illustrated, the customer machine12includes a customer communication system24. In one embodiment, the customer machine12may be a communication device such as, but not limited to, a computer system, a landline telephone (PSTN), a satellite phone, a fax machine, or any of a variety of wired or wireless communication devices. The customer communication system24enables a user to access the customer interaction system14by, merely for example, an instant messaging or online chat interface, such as MSN Messenger developed by Microsoft™ corporation of Redmond, Wash. In yet another embodiment, the customer communication system24enables a user to display web pages that are loaded from server computers. The client communication system24may be embodied as a browser such as, the Microsoft Internet explorer browser developed by Microsoft™ Corporation or Navigator™ browser developed by Netscape of Mountain View, Calif. The customer communication system24embodied as a browser or instant messenger executes under an operating system such as, Microsoft™ Windows developed by Microsoft™ Corporation or Mac OS X developed by Apple Computers of Cupertino, Calif.

The enterprise contact machine18includes one or more of a number of servers, namely communication and processing servers in exemplary form of a web server28that can engage in instant messaging and deliver web pages (e.g., mark up language documents), a workforce management (WFM) server32that may track current handling resources, calculate estimated handling resources for future service, and forecast customer service transaction workloads for those handling resources, an enterprise contact server34that can schedule and initiate a callback, and a database engine server36, which maintains and facilitates access to a database38. In one embodiment, the web server28can be connected directly to the communications network16, while in another embodiment, the servers are connected indirectly to the communications network16via media switches40-1through40-n (e.g., automatic call distributors).

The customer interaction system14includes at least one media switch40-1communicatively coupled to the communications network16, the enterprise contact servers34, the workforce management servers32, and the resource group42. Media switches40-1through40-n can support any one or all of the following protocols: PSTN voice, Voice over Internet Protocol (VoIP), or instant messaging (IM) protocol. Resource group42includes at least one resource44-1. Resources44-1through44-n can include, but are not limited to, any one or a combination of a human resource, a speech recognition system, or an interactive voice response (IVR) system. Additionally, the media switches40-1though40-n can be located within various geographic regions such that there may be a local or non-local toll charge with respect to the resource group42or the customer machine12. For example, media switch40-1may be local to the resource group42but not local to the customer machine12, while switch40n may be local to the customer machine12but not local to the resource group42.

FIG. 3is a block diagram illustrating an exemplary embodiment of a tracking module46and a forecasting module48operating on the workforce management server32of the enterprise contact machine18. The tracking module46executes under kernel operating software to scan the database38coupled to the database engine server36for resource information.

The forecasting module48executes under kernel operating software to provide forecast information such as, forecasted number of contacts, forecasted average handle time, and forecasted abandoned calls. Additionally, the forecasting module48may obtain data from any one or all of the media switches40-1through40-n including but not limited to the number of calls in a queue, the average handle time, the average time to advance a call, the number of resources logged on, and the number of resources available.

FIG. 4is a block diagram illustrating an exemplary embodiment of a scheduling module50, operating on the enterprise contact server34of the enterprise contact machine18. The scheduling module50executes under kernel operating software to schedule and store a callback time for customer service. The callback module52executes under kernel operating software to initiate a callback through a media switch when the scheduled callback time arrives.

In another embodiment, media switch and/or resource group information can be uploaded to the database38through any one of, the enterprise contact server34, the workforce management server32, or the web server28via the database engine server36. Once uploaded, the tracking module46, the forecasting module48, the scheduling module50, or the callback module52may access the data from database38.

FIG. 5is a database diagram illustrating tables within the exemplary database38, which is maintained by and accessed via the database engine server36. The database38may, in one exemplary embodiment, be implemented as a relational database, and includes a number of tables having entries, or records, that are linked by indices and keys. In an alternative embodiment, the database38may be implemented as a collection of objects in an object-oriented database.

The database38includes a historical database table53that may be linked to an event schedule table54, resource forecast table58and call/resource tracking table60. The event schedule table54may also be linked to a caller information table56and the resource forecast table58. The resource forecast table58could also be linked to the call resource tracking table60. The database38, via database engine server36, may be read from or written to by any other servers in the enterprise contact machine18.

FIG. 6provides a diagrammatic representation of database38, including selected fields from the historical data table53, the event schedule table54, the caller information table56, the resource forecast table58, and the call/resource tracking table60, according to one exemplary embodiment of the present invention.

The historical data table53includes records that contain historical wait times65, historical transaction times66, and historical resource schedules67. The event schedule table54includes records that contain a callback time70, a selected media switch71, and an event status data72. In one embodiment, the event status data72indicates whether a scheduled callback attempt was successful or not.

The caller information table56includes caller records critical to scheduling and initiating a callback. These records include caller data77, a caller address78, and a communication protocol79. The caller data77may include information such as, for example, name, user name, and location. The caller address record78may include, for example, a telephone number, a user name for an instant messaging service, and/or an email address. The communication protocol79indicates what type of communication protocol will be used for the callback. Such protocols can include, for example, the Voice over IP (VoIP) protocol, an instant messaging protocol, fax, or PSTN.

The resource forecast table58includes records that indicate forecasts of a customer service transaction workload for actual and estimated handling resources associated with the customer interaction system14. These records include a forecast time interval84, forecasted contacts85, a forecasted time to advance86, forecasted calls abandoned82, resources scheduled87, resources required88, and an open for event record89.

The forecast time interval84, according to one embodiment of the present invention, is a predetermined future window of time used by the workforce management server32to calculate the estimated handling resources and to forecast the customer service transaction workload for the estimated handling resources of the customer interaction system14. A forecasted contacts record85is the projected number of customer communications for the given forecast time interval. The records for the number of resources scheduled87and the number of resources required88are also dependent upon the forecast time interval84. The open for event record89indicates whether or not an event, such as a callback, can be scheduled within the forecast time interval.

The call/resource tracking table60includes records that include call and resource data regarding the customer interaction system14. These records include calls in queue94, scheduled callbacks95, average handle time per call96, average time to advance97, resources available98, and the estimated wait time99.

FIG. 7is a flowchart illustrating a method100, according to an exemplary embodiment of the present invention, whereby a customer interaction system14, in response to an incoming customer service request, offers a customer, on a customer machine12, an option to schedule a callback for customer service from the customer interaction system14. In varying embodiments, the customer service request comes from a telephone or wireless device, a web page service request form, or an instant messaging application whereby a callback schedule agent can respond with callback time options. In another embodiment, the customer initiates a request for a callback from the customer interaction system14.

At box102, the customer initiates a contact with the customer interaction system14. The customer interaction system14receives the customer call at a switch configured to receive the customer's chosen communications protocol.

The enterprise contact server34, at box106, is then queried for the expected wait time that has been calculated and stored in the database38. The enterprise contact server34uses records from the historical data table53, event schedule table54and resource tracking table60to calculate the expected wait time, as discussed with reference toFIG. 8. An estimate of how long a customer will have to wait before being connected to an agent is used to decide whether or not to offer the customer the option to be called back by the system at some future time. At box108, if the estimated wait time is less than a configurable threshold time, then the callback option will not be offered and the decision will be stored at box110. The configurable threshold time may vary from time interval to time interval and may be configured by an enterprise contact system administrator.

According to one exemplary embodiment of the present invention, the wait time may be estimated by the enterprise contact server32, which computes the average time it has taken calls to advance one place in the queue during the recent past. In other words, the server32may compute an average of the historical transaction times for a predetermined forecast time interval. When a new call arrives, an estimate of the wait can be obtained by multiplying this average time to advance by the number of calls currently in the queue to yield a forecasted time to advance. This wait time provides an estimate of the expected wait under the assumption that the handling resources are constant over the recent past and the near future. An improved estimate may be obtained by taking into account the variability of the available handling resources. In one embodiment, the workforce management server32accesses the historical transaction times66and the historical handling resources67from the database38to perform a regression calculation of the average time to advance during the recent past against the handling resources available at the time the previous advance occurred. The result is data, such as a forecasted average time to advance86as a function of currently scheduled handing resources87, that can be used to provide an estimated wait time99. When a new call arrives, an estimate of the wait for a queue of size n can be computed as follows. Note, the number calls in queue can be found in the database38. Let t0be the current time. Let a0be average time to advance based on an estimate of the available resources at time t0.Let t1=t0+a0. Let a1be the average time to advance based on an estimate of the available resources at time t1. Let t2=t1+a1. In general, let aj−1be the average time to advance based on an estimate of the available resources at time tj−1. Let tj=tj−1+aj−1. Then tn+1−t0estimates the wait time for a queue of size n. This wait time is an estimate of the expected wait for the case when handling resources vary in time.

In another embodiment, the estimated wait time may be a confidence wait time. To compute the confidence wait time, a probability distribution p(t;n) is determined for the wait time, given a queue of size n. A confidence level, c, is set (where 0<c<1). The c×100% confidence wait time is then defined as the time, T, such that Prob{t<T}=c for the distribution, p(t;n). A simple way to approximate the probability distribution, p(t;n), is to assume that the time for each advance in the queue is exponentially distributed with a mean that is the average time to advance over the recent past. Then p(t;n) can be expressed as a scaled gamma distribution with parameter n+1. That is:
p(t;n)=tne−t/a/an+1Γ(n+1)

where “a” is the average time to advance.

The confidence wait time conveniently reflects the increasing uncertainty and the change in the shape of the distribution of the wait time as the as size of the queue increases. An expected wait time does not. For example, if the callback system is configured to offer a callback when the 95% confidence wait time is greater than 15 minutes (the configured threshold value), that means that a customer will be offered a callback when the probability they will have to wait more than 15 minutes is greater then 5% and that statement is true no matter what the size of the queue. On the other hand, if the customer is offered a callback when an expected wait time is greater than 15 minutes, the probability that the customer would have to wait more than 15 minutes depends on the size of the queue.

If the estimated wait time is greater than a configurable threshold time, the customer interaction system14, at box112, calculates callback time options, as illustrated inFIG. 8, and offers these options to the customer. At box114, if the customer declines to accept any of the callback options, the customer interaction system14prompts the customer to suggest an alternate callback time. For example, if the customer contact is via a telephone, the customer may select an alternate callback time via an interactive voice response (IVR) system. If the customer declines to suggest or select an alternate callback time, at box116, the customer interaction system14stores the decision at box118and ends the session. If the customer inputs an alternate callback time, the customer interaction system14, based upon the alternate callback time, calculates callback time options based upon estimated handling resources, transaction forecasts, and customer interaction system objectives and generates a set of new callback times to offer, at box112. However, if at box114, the callback option is accepted, the customer interaction system14, at box120, collects the customer's callback contact information, schedules a callback, and stores the callback information in the database38. In various embodiments, callback information can be collected according to the communications protocol used. For example, an IM chat session could use an agent to collect customer contact information over an IM dialog box, a telephone contact could use an ANI (automatic number identification service) coupled to the enterprise contact server34, or for a web contact, by an HTML POST to web service that can communicate with the enterprise contact server34via the web server28.

FIG. 8is a flowchart illustrating a method130, according to an exemplary embodiment of the present invention, whereby the tracking module46and forecasting module48of workforce management server32estimate resources and transactions for future time intervals. The enterprise contact server34uses these estimates to calculate the callback time options to offer the customer. At box132, the workforce management server32, responsive to the enterprise contact server34determining that a callback should be offered, calculates estimated handling resources for the customer interaction system14. In one embodiment, the customer interaction system14has previously scheduled resources, as indicated in the resource forecast table58, so that, at any future time, some subset of resources is available to handle callbacks exclusively. In this case, forecasting module can provide, for future time intervals such as the time intervals at or near the callback time, the mean number of resources so scheduled or staffed as an estimate of the handling resources for that given time interval. In one embodiment, the time interval is configurable and the mean number of resources scheduled is calculated by the forecasting module48from the historical resource schedule data from history table61. Subject to this scheduling constraint, improved estimates can be obtained when the tracking module46tracks the actual mean number of resources that have been available to handle callbacks over a number of time intervals in the recent past. The deviations calculated by the tracking module48between the actual (e.g., observed) mean number of available resources and the scheduled mean number of available resources over time intervals in the recent past then can be used to correct the estimate based on scheduling alone. The correction can be determined by any number of regression techniques applied to the past deviations. Among these, the most basic is a simple linear regression of actual mean against scheduled mean available resources. In this case, the “line of regression” provides an estimate of the mean number of available resources during some future time interval, which estimate is a (non-homogeneous) linear function of the mean number of scheduled resources for that period.

Alternatively, a weighted linear regression in which the weights decrease with the age of the deviations (e.g., exponentially with the age) can be used to produce the correction. In this case, the correction provided by the line of regression reflects the deviations of the recent past more strongly than those of the less recent past. Additionally, but still subject to the scheduling constraint of exclusive callback resources, corrections can also be informed by tracking deviations into the remote past, an a priori stochastic model, or both. In these cases, a parameterized conditional probability distribution expressing actual (e.g., observed) mean number given scheduled mean number of available resources is assumed. The historical data such as, historical resource schedules and historical transaction times, and/or a priori considerations are used to enforce constraints upon the parameters of this distribution. The remaining degrees of freedom among the parameters are then free to vary in time. Therefore, recent past deviations can be used to constrain those remaining degrees of freedom and thereby implicitly estimate all the distribution's parameter values in effect during any time interval. The estimated mean number of available resources available during some future time interval can be obtained as the maximum likelihood estimate of mean number of available resources for the conditional distribution with the estimated parameters, given the scheduled number of available resources.

In another embodiment, the resources that are, exclusively handling callbacks are grouped subject to constraints that different sets of resource groups are available for different types of callbacks. In this case, any estimate of future handling resources (e.g., a mean number of available resources) for a type of callback may take into account that any available resource may be shared among different types of callback. In one embodiment, the scheduling module50apportions equal fractions of a resource to handle each type of callback for which the resource is available. However, since different types of callbacks will arise at different rates and consume different amount of an resource's available time, it is appropriate to correct each fraction to be the ratio of callback work of the given type to the sum of all the callback work for all the types of callback the resource may handle during any time period when the resource is available. In this way, the estimate of future handling resources for a particular type of callback becomes dependent upon a forecast of callback incidence and type. In other embodiments, the estimate can be corrected and refined by use of regression against the recent past deviations, obtained from the tracking module46, subject to constraints imposed by historical resource data or a priori considerations. In yet another embodiment, there is no requirement that resources handle callbacks exclusively, but only that a predetermined percentage of a resource's labor is apportioned exclusively for callback work. These percentages are used to deflate the estimates for average number of resources available as compared to what the estimates would be were resources working on callback exclusively. This can be done for the case of resource groups and call types, and such estimates also can be corrected and refined by regression. In an exemplary embodiment, a system administrator enters this percentage allocation into the customer interaction system14.

At box136, the workforce management server32forecasts transactions that will be associated with the estimated handling resources. The forecast module48configures, for each time interval, default values, stored in the resource forecast table58, for describing the forecasted contacts and the forecasted handling time for each resource handling each contact. In another embodiment, these forecast values are the result of a regression and/or trend analysis of historical data and may be informed by a business model of future transactions that anticipates changes in the incidence or handle time not reflected in the historical data. The values offered by the forecast module48are typically interpreted as estimates of the (time-varying) parameters of (exponential) probability distributions that capture the stochastic nature of the forecast transactions. In this way, both expected values and confidence limits for forecasted contacts and forecasted handling time can be obtained. The estimates of the parameters can be corrected by the tracking module46tracking the actual values of contacts and handling times over the recent past; these actual values may be used to compute maximum likelihood estimates of the distributions' parameters for this recent past. A regression of the observed parameter estimates against the forecast parameter estimates over time intervals of the recent past can be used to correct the forecast for a future time interval. This forecast, calculated by the forecast module48, can be used to determine when there is a positive net staffing, whereby the number of resources staffed exceeds the required number of resources staffed for a given predefined time interval.

In another embodiment, the contacts are typed, and for each type of contact the forecast module48provides a forecast of the incidence of contacts and the handle time for any time interval. Now the values for each type of contact are subject to the same sort of refinement and correction as referenced above in the previous embodiment. These refinements and corrections may be applied either independently for each contact type or simultaneously for all contact types.

At box138, the enterprise contact server34determines a callback time to offer a customer based upon the estimated handling resources and the forecast transaction workload supplied by the forecast module48. The enterprise contact server34must determine suitable times for a callback from some time interval, for example, [t1, t2], where t1is greater than the current time plus an estimated wait time. In one embodiment, the interval, [t1, t2], is provided by the customer, and the callback system seeks a time based on the availability of resources that are working on callbacks. The callback system knows when callbacks have been already scheduled, so it can estimate the handling resources already committed at any time in [t1, t2]. The workforce management server32can estimate the available handling resources. The difference is the handling resources that are free to be scheduled for new callbacks.

In general, this difference varies over [t1, t2]. Any time, in [t1, t2], when this difference is greater than the resources required to handle the current call is a candidate for the callback time. For exemplary purposes, these callback times are called candidate times. For any time, in [t1, t2], let the resource excess be the available handling resources minus the handling resources needed for previously scheduled callbacks minus the resources required to handle the current call. In these terms, a time in [t1, t2] is a candidate time whenever the resource excess is positive or, in other words, there is positive net staffing. If there are such candidate times, the system may select a small number of them, suggest them to the customer, and ask the customer to choose one. (The maximum number of callback times suggested may be determined by a configurable bound.) Alternatively, a callback time may be selected based on a time within [t1, t2] where the net staffing is at a maximum for the given period. Typically, there will be many times in [t1, t2] when it is appropriate to schedule a callback. For this reason, it is possible to choose which times are suggested to the customer by different criteria that achieve different system objectives, such as next available time, best staffing time, or least cost.

For a system objective of next available time, according to an exemplary embodiment, a configured time delay, d, is employed, as well as the configured bound, n, on the number of suggested times. If there is no candidate time in [t1, t2], the customer is prompted for a new time interval or the offer to callback withdrawn. Otherwise, the earliest candidate time, T1, in [t1, t2] is suggested. A second candidate time, T2, is suggested where T2is the earliest candidate time such that T1+d<T2<=t2. A third candidate time, T3, is suggested where T3is the earliest candidate time such that T2+d<T3<=t2, and so on, until the number of suggested times equals the configured bound, n, or there are no such candidate times.

For a system objective of best staffing time, according to another embodiment, a configured time delay, d, is employed, as well as the configured bound, n, on the number of suggested times. Suggest a time in [t1, t2] when the excess is a maximum. Suggest k other times such that the pair-wise difference between the times is at least d, each time is in [t1, t2], k is the largest integer less than or equal to n−1 for which there are such times, and such that the least excess among the k times is greatest.

For an exemplary embodiment of a system objective of least cost, a configured time delay, d, is employed, a configured bound, n, on the number of suggested times is given, and a cost associated with making a callback from a particular media switch to the callback addresss (e.g., phone number) is known. In this case, select an optimal media switch, specifically a media switch with least cost. Either the next available or best staffing suggested times are found then for the handling resources associated with that switch.

At box139, the enterprise contact server34and media switches40-1through40-n offers the customer the callback option. For example, if the customer contact is via the web, a dialog window may be configured to display the callback times and prompt the customer to select one or by interactive voice response if contact is by telephone. In another embodiment, the customer contact is via an instant messaging (IM) application and the callback time or times are offered in a dialog box associated with the IM application by a callback schedule agent.

FIG. 9is a flowchart illustrating a method140, according to an exemplary embodiment of the present invention, wherein the scheduling module50of the enterprise contact server34triggers the callback module52to initiate the callback at the approximate scheduled callback time. At box142, once the scheduled callback time arrives, the callback module52retrieves, from the database38, caller data77, caller address78(e.g., phone number) and caller communication protocol79(e.g., telephone, IM chat, etc.). The callback module52then determines, at box144, an appropriate switch for callback based upon the communication protocol and system objectives, as discussed with reference toFIG. 8.

At box146, the media switch selected for callback is stored in the event schedule table54and the customer information table56of the database38. At box148, the media switch places the callback. In one embodiment, the enterprise contact server34may reserve resources for the callback prior placing the call on the media switch. If the customer fails to respond to the callback, at box150, the scheduling module50may be configured to reschedule a callback at box152. For example, if there is no answer, the customer interaction system14may be configured to automatically reschedule a callback at intervals for a fixed number of times as configured by a callback system administrator. In another embodiment, the rescheduling occurs at a time when resources are also predicted to be available. At box154, the decision to reschedule the callback is stored in the database38under event status72. If the customer interaction system14does reschedule a callback, at box152, the process returns to waiting for the scheduled callback time to arrive at box142. If the customer interaction system14is configured not to reschedule a callback, the session ends. However, if the customer does respond to the callback, at box150, the callback module52verifies the customer by asking for an affirmative response to previously acquired caller data or assigned ID (identifier). The response may vary according to protocol used. For example, a telephone callback may use an IVR system to detect a voice response to a question regarding a name, or for an IM callback, the response will be typed into the IM interface. Once verified, the callback module52places the customer into the customer service queue at a callback priority ranking and connects the customer to a resource or a previously reserved resource when the top of the queue is reached, at box156. In an exemplary embodiment, the priority ranking may put the customer at the front of the queue or, conditionally, place the customer in queue for a reserved callback resource. At box158, the result of the callback is stored in the database38under event status72.

FIG. 10illustrates a diagrammatic representation of a machine in the exemplary form of a computer system200wherein a set of instructions can be executed to cause the machine to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The exemplary computer system200includes a processor202(e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), a main memory204and a static memory206, which communicate with each other via a bus208. The computer system200may further include a video display unit210(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system200also includes an alphanumeric input device212(e.g., a keyboard), a cursor control device214(e.g., a mouse), a disk drive unit216, a signal generation device218(e.g., a speaker) and a network interface device220.

The disk drive unit216includes a machine-readable medium222on which is stored one or more sets of instructions (e.g., software224) embodying any one or more of the methodologies or functions described herein. The software224may also reside, completely or at least partially, within the main memory204and/or within the processor202during execution thereof by the computer system200, the main memory204and the processor202also constituting machine-readable media.

The software224may further be transmitted or received over a network226via the network interface device220.

Thus, a method and system to schedule a callback time for customer service have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specifications and drawings are to be regarded in an illustrative rather than a restrictive sense.