The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the present invention, and together with the description, serve to explain the principles thereof. Like items in the drawings are referred to using the same numerical reference.
The technology of the present application is being described in relation to a call center connectable to a public switched telephone network. One of ordinary skill in the art on reading the disclosure will now recognize that the call center may be connected to other telephony systems, such as, for example, radio system, VoIP systems, or the like. Moreover, the technology of the present application is being explained with reference to exemplary embodiments. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. Moreover, unless explicitly stated all embodiments should be considered exemplary.
Referring first to
Typically, ACD 102, IVR 110, and CTI 114 are stand-alone, proprietary systems from different vendors. In practice, competitive pressures have led the vendors to encroach on each other's turf, so that an IVR system may have some CTI capabilities and vice versa, or an ACD may have built-in IVR capabilities.
The vendors of ACD 102, IVR 110, and CTI 114 systems have made substantial investments to support each other's API's. For example, CTI 114 must communicate with all the different types of ACDs 102 and phone systems to transfer calls from the hold queue to an available agent; and they must access all the different types of IVR 110 to retrieve data for screen-pops. In many instances the collected data cannot be transferred automatically to the CRM application 120, and the agent has to re-type it from the screen-pop, or (worse) has to ask the caller to repeat the information.
Referring now to
As seen in
Center 200 includes a switch 204 or media gateway, as can be found in the art, the SIP/HTTP container 202, which is implemented in a current embodiment as a BEA Weblogic SIP Server including a session initiation protocol (SIP) back-to-back-user-agent 206 (B2BUA as are generally known in the art), a voice platform 208, such as a voice platform available from SandCherry Incorporated, which executes, for example, VoiceXML for ACD 102 and IVR 110. Voice platform 208 may be referred to as SVP 208 Ideally, the agent hand piece is a VoIP enabled device 210, but not necessarily. The agent typically operates a conventional processor 212, such as a personal computer.
For simplicity, and without loss of generality, center 200 will be explained assuming all calls arriving at the center 200 from customer 122 are received by a switch, which supports the appropriate signaling and media transport protocols of the network outside the call center, and SIP signaling with RTP media transport inside the call center. One of skill in the art will understand other arrangements are possible.
When a call arrives at the call center, it is intercepted by switch 204, which issues an invite to container 202. B2BUA 206 running on container 202 accepts the invite and starts a new session (represented in part by call control (SIP) 116, which lasts for the duration of customer's call to the call center 200. Once the call has been accepted it is processed through its various stages by various functional units also running in the same converged container 202. Explaining generally the call flow in terms of ACD 102, IVR 110, CTI 114, CRM application 120, and Agent Transfer functions (not specifically shown on the figure). IVR 110, CTI 114, CRM application 120, and Agent Transfer modules can be thought of as execution assistants for the ACD 102, where the call returns to ACD 102 after each assistant has completed its ask. For example, ACD 102 may deliver an audio signal to IVR 110 for recognition. IVR would send a recognized audio signal back to ACD 102.
ACD 102: The ACD program module moves the call through its logical stages. It issues invites to other modules to perform particular tasks, after which the call returns to the ACD to be moved to the next task. For example, the first task is, typically, to gather information from the caller using IVR. The ACD logic running on container 202 issues a SIP invite to the SVP 208; the invite includes the URL of a VoiceXML script, to SVP 208. The SVP 208 accepts the invite and the ACD program module sets up a media path between the caller and SVP 208 that conducts a dialog with the customer by executing the VoiceXML script.
IVR 110: The IVR program module resides in the converged container 202. The SVP 208 executes the VoiceXML scripts generated by the IVR program module and posts results back to the IVR program. The results are stored in the converged container 202 for later use. If the caller was able to accomplish all his business using the IVR logic, he hangs up and the session is over. However, he may wish to speak to an agent, and he indicates this at some point during the IVR dialog. The IVR program wraps up its work, signals the end of the IVR session to SVP 208, and disconnects the media path to SVP 208. The IVR logic hands control back to the ACD program module, which queues up the call for the next available agent.
Call Queuing: The ACD program module examines its list of available agents. If there is one, the session then moves to the CTI logic to transfer the call and pertinent user data, otherwise, the ACD logic queues the call and waits for an agent to become available (or for the caller to hang up). While a call is waiting for an agent to become available, it is customary to play ‘comfort’ music or messages to the user. The ACD program module issues an invite to SVP 208. The invite contains the URL of a VXML script which either plays comfort music/messages to the customer, or provides additional self-service functionality while he is on hold.
CTI: When an agent comes available, the CTI program module handles the transfer of a call to an agent, while simultaneously initiating a new CRM session. The CTI program module uses the B2BUA to set up a connection from the customer to the agent's phone. At about the same time the CTI program module uses a pre-designated means to communicate to the CRM application that it should (a) start a new session, and (b) use data stored in the converged container to initialize the new CRM session. There are many viable choices available for how to start a new CRM session; for example the CTI logic can use SIP (or HTTP) messaging to send the URL of a page to an agent program running on the CRM's PC, which in turn starts a web browser session with that URL (many CRM applications use web browsers to present their GUIs).
Agent Transfer: While the agent is helping the customer he may determine that he needs to transfer the customer to another agent. For the purposes of our embodiment, the agent returns the call to the ACD program module with a request to re-queue the call for an appropriate agent or specialist. This request is sent over SIP or HTTP.
Today's call centers typically have remote agents that establish their own working schedule. Thus, the agent needs a mechanism to manage their availability to take call center calls. A conventional ACD 102 has a register of the available of agents to which it can route calls. The register is frequently updated—whenever an agent answers a call, he is no longer available until he completes that call and he has completed any “post-call” tasks. The CRM application's GUI or agent's telephone typically has a control which the agent uses to indicate to the ACD whether he is available or unavailable to take a call.
Center 200 uses the ACD 102 as well to provide agent availability. In particular, the ACD program module maintains a registry (database) of agents and pertinent data for each one, such as phone extension (or SIP address), desktop IP address, availability, and skill profile. The agent indicates his availability status through a control on his desktop (or a button on his phone), which uses HTTP (or SIP) messages to communicate to the ACD program module his availability. The ACD program module uses this to update the agent's registry entry. When the ACD program module wants to route a customer call to an agent, it searches the registry for an available agent (and may consider the available agents' skill profiles before selecting one to take the call). For sake of generality, since the ACD program module resides in a converged SIP/HTTP container, the communication of an agent's availability can be accomplished through SIP or HTTP messaging according to the actual of embodiment of the invention.
Finally, referring to
While the invention has been particularly shown and described with reference to an embodiment thereof, it will be understood by those skilled in the art that various other changes in the form and details may be made without departing from the spirit and scope of the invention.
The present application claims priority to U.S. Provisional Application Ser. No. 60/804,241 filed Jun. 8, 2006, titled CONVERGED CALL CENTER, the specification of which is incorporated herein by reference as if set out in full.
Number | Date | Country | |
---|---|---|---|
60804241 | Jun 2006 | US |