Patent Description:
<CIT> discloses a contact center system for switching a communication event from one communication medium to another in a contact center, the system includes: a processor; and memory, wherein the memory has stored therein instructions that, when executed by the processor, cause the processor to: receive a first interaction request via a first media channel from an endpoint device; identify a second media channel different from the first media channel; transmit a signal for reserving a resource associated with the second media channel; and transmit a unique identifier associated with the reservation request to the endpoint device for establishing a second interaction request via the second media channel. <CIT> discloses a system which includes: a computerized appliance having a processor; and software executing on the computerized appliance from a non-transitory physical medium, the software providing: establishment of a communication session over a network between two or more end communications appliances; detection and recording of at least media channel capabilities on individual end communications appliances connected in the session; service of media channel toggle options to end communications appliances; detection of media channel toggle option selections made by users operating the end communications appliances; and implementation of the media channel toggle option or options selected for individual communications sessions.

The invention sets out a method for facilitating a change from a first communication channel (<NUM>) to a second communication channel (<NUM>) for an interaction within a contact center system for a first party after the interaction has been initiated and the first party is in queue for the first communication channel according to claim <NUM>. The embodiments described below are for illustration purposes.

A system and method are presented for omni-channel notification and selection. A first party selects a first channel from a plurality of channels based on an estimated wait time for interaction with another party in a contact center or enterprise setting. The plurality of channels may comprise any means of interaction, such as chat, phone call, SMS, video, etc. While waiting in queue for the preferred first channel, the first party is presented with estimated wait times, which are dynamically updated, for other channels. Based on the first party's preferences and the presented estimated wait times for the other channels, the first party may elect to change interaction channels from the first channel to a second channel. The first party may then be moved to a different queue corresponding to the second interaction channel.

In one embodiment, a method is presented for facilitating a change from a first communication channel to a second communication channel for an interaction within a contact center system for a first party after the interaction has been initiated and the first party is in queue for the first communication channel, comprising: providing, through a user interface associated with a mobile application interoperably connected to the contact center system, the first party with estimated queue wait times for a plurality of communication channels associated with the contact center system; initiating an interaction through receiving a selection from the first party for the first communication channel from the plurality of communication channels; processing the first selection of the first communication channel by a SIP server and a voice platform, wherein the voice platform provides a standards-based VoiceXML platform that provides a speech application, and routing the interaction into a queue associated with the first communication channel; informing, by the speech application, the first party of estimated queue wait times associated with each of the plurality of communication channels; providing, by the voice platform, the first party with the capability to switch channels through selection of a prompt associated with each of the plurality of communication channels; receiving a selection from the first party of the second communication channel; and transferring, via a switch channel API, the interaction from the queue associated with the communication channel to a queue associated with the second communication channel.

In another embodiment, a method is presented for facilitating a change from a first communication channel to a second communication channel for an interaction within a contact center system for a first party after the interaction has been initiated and the first party is in queue for the first communication channel, comprising: providing, through a user interface associated with a web browser interoperably connected to the contact center system, the first party with estimated queue wait times for a plurality of communication channels associated with the contact center system; initiating an interaction through receiving a selection from the first party for, the first communication channel from the plurality of communication channels; processing the first selection of the first communication channel by a SIP server and a voice platform, wherein the voice platform provides a standards-based VoiceXML platform that provides a speech application, and routing the interaction into a queue associated with the first communication channel; informing, by the speech application, the first party of estimated queue wait times associated with each of the plurality of communication channels; providing, by the voice platform, the first party with the capability to switch channels through selection of a prompt associated with each of the plurality of communication channels; receiving a selection from the first party of the second communication channel; and transferring, via a switch channel API, the interaction from the queue associated with the communication channel to a queue associated with the second communication channel.

In another embodiment, a method is presented for facilitating a change from a first communication channel to a second communication channel for an interaction within a contact center system for a first party after the interaction has been initiated and the first party is in queue for the first communication channel, comprising: providing, through a user interface, the first party with estimated queue wait times for a plurality of communication channels associated with the contact center system; initiating an interaction through receiving a selection from the first party of the first communication channel from the plurality of communication channels; processing the first selection by a service associated with the first communication channel, and routing the interaction into a queue associated with the first communication channel; informing, through the user interface, the first party of estimated queue wait times associated with each of the plurality of communication channels; providing, through the user interface, the first party with the capability to switch channels through selection of a prompt associated with each of the plurality of communication channels; receiving a selection from the first party of the second communication channel; transferring, via a switch channel API, the interaction from the queue associated with the first communication channel to a queue associated with the second communication channel.

For the purposes of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. Any alterations and further modifications in the described embodiments, and any further applications of the principles of the invention as described herein are contemplated as would normally occur to one skilled in the art to which the invention relates.

Contact centers have multiple channels through which interactions may occur. When a customer interacts with an agent, for example, the customer may initially select their preferred channel of communication, such as video, SMS, email, voice, chat, social channels, mobile applications, etc. The selection is often made without having enough information to select which channel will be the most efficient for the customer's interaction. The customer might have been provided with an estimated wait time for a channel at the outset of the interaction. For example, the customer might be browsing their banking application on their mobile device. The customer might see that there is currently a three-minute wait to speak with an agent if they initiate an interaction via phone call, but there is no information about the other channels, such as chat, SMS, or video available to them for connection with an agent. The customer cannot see if a chat might be a faster way to reach an agent or an email might receive a faster response than waiting for the next available agent via phone.

In another embodiment, information about the estimated wait time of a plurality of different channels is not provided dynamically to encourage a customer to switch between channels based on wait time, particularly after the customer may have initiated an interaction with a first channel. Existing solutions are limited in that they may only provide information regarding estimated wait time for the first channel once the customer has chosen it and entered the queue for that channel. Further, information is limited in that it does not provide any prior information or notification about the estimated wait time of different channels of the available plurality of channels for the contact center environment before the customer selects a specific channel in an omni-channel solution. Information is also limited in that it does not provide information or notification of estimated wait times for different channels after the customer selects a specific channel and enters the queue for that channel. A customer thus does not have an opportunity to switch queues if a more efficient option becomes available while they are waiting in queue for the selected channel. Facilitating the ability to switch channels once in queue allows busy channels within the contact center to be unloaded thus facilitating workload distribution and decreasing overall customer wait time while increasing agent productivity across the contact center.

In an embodiment, customers (or users) may be automatically informed or notified about estimated wait times for a plurality of channels via a mobile application or a web browser. The mobile application may be downloaded to the customer's mobile device (e.g., smartphone or tablet). The web browser user interface (UI) may be accessed through the user's mobile device or computing device. Information about the estimated wait times for the plurality of channels may be dynamically accessed and updated even if the customer is already in queue for a particular channel. For example, the customer may be running their web browser on their smartphone or on their computing device while waiting on hold with a voice call. The customer may find that chat has a shorter wait time and elects to transition over to the chat channel from the voice channel. Once the customer has initiated the transition, the customer may receive a notification (such as a screen pop or SMS) with a link to initiate a chat session using their web browser in the mobile device. While transitioning out of voice and into chat, with a web browser, the chat session may be initiated in a separate browser window. In the event that the customer is performing the switch entirely within their mobile application, the chat session may resume inside the mobile application itself with the initial voice call being disconnected.

<FIG> is a diagram illustrating an embodiment of the architecture of the system, indicated generally at <NUM>. Components of the system may include: a Customer Connect Engine <NUM> comprising a Wait Time Calculator API <NUM>, a Call-back Scheduling API <NUM>, and a Switch Channel API <NUM>; a User Interface <NUM>; and Interaction Channels <NUM>. The Customer Connect Engine <NUM> comprises a server component which allows the user to choose different Interaction Channels <NUM> and schedule a callback based on the dynamically updated estimated wait time. The Customer Connect Engine <NUM> receives input from a user, such as the customer, via a User Interface <NUM>. Upon receiving a request for channel selection and/or call-back scheduling from a user via the User Interface <NUM>, the Customer Connect Engine <NUM> forwards the request to one of the corresponding APIs, of which it is comprised at the backend of the application. The APIs comprise a Wait Time Calculator API <NUM>, a Call-back Scheduling API <NUM>, and a Switch Channel API <NUM>. The User Interface <NUM> may be present in a web browser on a computing device or a mobile device. The User Interface <NUM> may also be present in a mobile application on a user's mobile device (such as a tablet or a smart phone). Using the input from the user, the Customer Connect Engine <NUM> performs specific functions of routing an interaction from the customer towards the Interaction Channel <NUM> of their choice. The Customer Connect Engine <NUM> may also calculate the estimated waiting time of each of the plurality of Interaction Channels <NUM>. Calculations may be performed when the application is idle or be triggered when an interaction from the customer enters the queue. When a triggering event occurs, calculations are continuously updated in real-time or at specific time-periods, such as refreshed every minute, for example.

The User Interface <NUM> may be accessed by a user through a mobile device using the mobile application or via a web browser on a computing device having access to the world wide web. The User Interface <NUM> may be updated with estimated waiting times dynamically from the Customer Connect Engine <NUM>. The Customer Connect Engine <NUM> also provides capabilities for the customer to schedule a call-back from the Interaction Channel <NUM> of their choice.

The Wait Time Calculator API <NUM> retrieves appropriate queue waiting lists from each of the plurality of different Interaction Channels <NUM> utilizing a stat server. This information is provided to the User Interface <NUM>. Once the estimated waiting time is received, the User Interface <NUM> is refreshed automatically in real-time.

The Call-back Scheduling API <NUM> schedules call-backs for a customer when the customer elects to schedule a call-back from the Interaction Channel <NUM> of their choice. The customer can specify the order of their channel priority from the plurality of channels available and provide the API with the time of their choice through the User Interface <NUM>. Once this information is received by the Call-back Scheduling API <NUM>, the API will automatically search for the interaction channel with the least waiting time. A call-back may be triggered directly to the customer based on the submitted preferences.

The Switch Channel API <NUM> enables the customer to switch from one waiting queue of a channel to the waiting queue of another channel. For example, if the customer is already in queue for a phone call, and the customer discovers the waiting time of the chat channel is lower than that for the phone call, the customer can utilize a "channel switch" button from the User Interface <NUM> to tell the Switch Channel API <NUM> to change Interaction Channels <NUM>.

The User Interface <NUM> accesses the contact center through a plurality of Interaction Channels <NUM>. The Interaction Channels <NUM> comprise chat, voice, SMS, video, call-back scheduling, social channels, etc., to name a few non-limiting examples.

<FIG> is a diagram illustrating an embodiment of omni-channel architecture, indicated generally at <NUM>. Components of the system may include a: User Interface <NUM>, a Mobile Services platform <NUM>, a WebRTC Gateway <NUM>, a SIP Server <NUM>, a Chat Server <NUM>, a Universal Routing Server <NUM>, an Interaction Server <NUM>, a Universal Contact Server <NUM>, a Voice Platform <NUM>, a Stat Server <NUM>, and an Agent Workstation <NUM>. In an embodiment, the User Interface <NUM> allows a user to interact with the system application, which in turn interacts with the Mobile Services Platform <NUM>, the SIP Server <NUM>, and the WebRTC Gateway <NUM>. The system application may interact with the Mobile Services Platform <NUM> via a Web-API. A Web-API makes use of HTTP or HTTPS protocol. The Mobile Services Platform <NUM> may function as a gateway for multiple other digital communication channels like chat, SMS, email, etc, linking a mobile application with a contact center. Session Initiation Protocol (SIP) may be used by the application to communicate with the SIP Server <NUM>. An HTTP or HTTPS protocol might be used to communicate with the WebRTC Gateway <NUM>. The WebRTC Gateway <NUM> may connect WebRTC technology (which supports browser-to-browser applications for interactions without the need of internal or external plug-ins) and an established VoIP technology (such as SIP). The WebRTC Gateway is able to communicate with the SIP Server <NUM> via SIP and with the Voice Platform <NUM> also via SIP. The SIP Server <NUM> comprises an application which accepts SIP requests and responds. The SIP Server <NUM> provides an interface between telephony hardware and software components in the system. It may translate and tracks events and requests that come from the UI <NUM>. The SIP Server <NUM> may comprise a TCP/IP-based server that can also act as a messaging interface between SIP Server clients. The SIP Server <NUM> is connected to the WebRTC Gateway <NUM>, the system application, and the Agent Workstation <NUM> via SIP. The Mobile Services Platform <NUM> may be connected with the Chat Server <NUM> via Web-API. The Chat Server <NUM> initiates and maintains a chat session in coordination with the other components in the system. The Chat Server <NUM> comprises an API which distributes received messages (or events) to connected clients, such as the Interaction Server <NUM> and the Universal Contact Server <NUM>. The Interaction Server <NUM> comprises an API which is connected by events to the Universal Routing Server <NUM>, the Chat Server <NUM>, the Universal Contact Server <NUM>, and the Agent Workstation <NUM>. The Interaction Server <NUM> comprises the central interchange for interaction flow and mediates among media servers, routing components, knowledge management, and the interacting endpoints. The Universal Contact Server <NUM> comprises a server which stores the contents of interactions and information about the contacts who are party to the interactions. The information might include identifying information (e.g., name and address) and the history of all interactions that have involved the contact. The Universal Contact Server <NUM> is connected by events with the Chat Server <NUM>, the Interaction Server <NUM>, and the Stat Server <NUM>. The Universal Routing Server <NUM>, is connected via a T-Library Protocol ('T-Lib') with the SIP Server <NUM> and the Stat Server <NUM>, while it is connected via events with the Interaction Server <NUM>. The Universal Routing Server <NUM> enables distribution of interactions throughout the system based on routing strategies and business processes which route to the most appropriate agent/resource based on a plurality of factors (type of inquiry, value of customer, media channel, etc.) The Stat Server <NUM> tracks information about customer interaction networks and converts the data accumulated into statistically useful information. These calculations may be passed to other software applications that request the data (such as the Universal Routing Server <NUM>) and is connected with the Universal Routing Server <NUM> and the Voice Platform <NUM> via a T-Lib Protocol. The Stat Server <NUM> is connected to the Universal Contact Server <NUM> via events. The Voice Platform <NUM> provides a standards-based VoiceXML platform that provides advanced speech applications such as IVR and is connected via SIP to the WebRTC Gateway <NUM> and to the Stat Server <NUM>. The Agent Workstation is connected to the SIP Server <NUM> via SIP and to the Interaction Server via events <NUM>. An Agent Workstation <NUM> might comprise a computer for each agent, a telephone set/headset connected to a telecom switch and is linked to a computer network for the contact center.

<FIG> is a diagram illustrating an embodiment of a mobile application user interface, indicated generally at <NUM>. For example, the customer may need to reach out to their bank's customer service center and are currently in the bank's application within their smartphone. The plurality of channels available for contacting the bank are displayed in the user interface along with estimated wait times. Here, the chat channel is showing a <NUM> minute estimated wait time, the phone channel has a <NUM> minute estimated wait time, the video channel has an <NUM> minute estimated wait time, and the SMS channel has a <NUM> minute estimated wait time. The customer can select which channel best suits their needs from the plurality of options displayed, which in this example, might be the fastest means of communicating with the contact center. The customer would select the phone channel as it has the shortest estimated wait time. The stat server has custom statistical data about the least estimated waiting time specific to the agent grouping associated with an interaction channel based on skillset and the channel and this information is dynamically updated.

<FIG> is a sequence diagram illustrating an embodiment of preferred channel selection, indicated generally at <NUM>. The flow of the customer's preferred channel selection is displayed in <FIG>. A customer may have set preferences that they automatically want to reach out to a contact center based on whichever interaction channel has the least wait time. In this instance, <FIG> is illustrating the flow for an embodiment of when a customer has chosen chat as the preferred channel for communication. In this example, the customer is using a mobile application on their mobile device to connect with the contact center and the customer is not electing to change channels. Chat has been identified as having the least estimated waiting time and the customer has selected the chat channel for the interaction. When the customer selects the chat channel from the mobile application UI on their device, the mobile application 400a sends a WebAPI Request <NUM> to the Mobile Services Platform 400b. The Mobile Services Platform sends a login request <NUM> to the Chat Server 400c, which returns the event status <NUM> to the Mobile Services Platform 400b. A join request <NUM> is sent to the Chat Server 400c. The Chat Server 400c sends a creation request <NUM> to the Universal Contact server 400d, which responds with an Interaction ID (IXN ID) <NUM>. The Chat Server 400c then sends an IXN ID submission <NUM> to the Interaction Server 400e, which acknowledges the event <NUM>. The Interaction Server 400e sends an event routing request <NUM> to the Universal Routing Server 400f. The Universal Routing Server 400f sends an OpenStat request <NUM> the Stat Server <NUM>. The Stat Server <NUM> opens the stat <NUM> and sends acknowledgement to the Universal Routing Server 400f. The Universal Routing Server 400f then requests from the Interaction Server 400e that the interaction be routed <NUM>. An event invite <NUM> is sent from the Interaction Server 400e to the Agent <NUM>. The agent accepts the invite <NUM> and is connected with the customer via chat in the mobile application 400a.

<FIG> is a diagram illustrating an embodiment of a user initiating a change in channels once an interaction has been initiated but the users (an agent and a customer, for example) have not been connected, indicated generally at <NUM>. The customer has indicated their preferred channel for interaction and has been routed to the queue for that channel. For example, when a customer is waiting in a queue, the customer connect engine provides proactive notification via the user interface to the user about estimated queue wait time for different channels. Functionality is also provided within the UI to allow the user to switch between channels should they decide to abandon the current channel for a different channel out of the plurality of channels offered by this particular contact center environment.

In <FIG>, the Customer <NUM> has chosen the voice channel as their preferred channel, which has a least estimated waiting time of <NUM> minutes through the mobile application user interface <NUM>. In an embodiment, the selection could also be made through a web-browser interface on a computing device or a user's mobile device. The request is processed by the SIP Server <NUM> and the Voice Platform <NUM>. In an embodiment, the Voice Platform <NUM> may play an IVR prompt to the Customer <NUM> informing them of estimated waiting times of other channels. For example, "your call will be answered in <NUM> minutes. Press <NUM> to continue or press <NUM> to switch to chat channel, which has a wait time of <NUM> minutes". The IVR might offer any number of channels the customer could switch to along with estimated wait times of each. Meanwhile, the Wait Time Calculator API <NUM> in the Customer Connect Engine <NUM> displays the waiting time of all the channels in the mobile application interface <NUM> and continues to dynamically update these. The Customer <NUM> decides to proceed with the chat channel and selects to switch from the voice channel to the chat channel. This request is processed by the Switch Channel API <NUM>. The Switch Channel API <NUM> transfers the interaction from voice to chat. When a user transitions from channel to channel (using voice transitioning to chat as in the current example), the customer is shown a confirmation screen pop to switch from voice to chat in their UI. Once the customer confirms, the chat session is initiated. If the customer is still in queue for the voice channel, an automated message may be played and the call properly disconnected with the customer being removed from the voice channel queue. The Mobile Services Platform <NUM> and the Chat server <NUM> then proceed to handle the interaction.

<FIG> is a sequence diagram illustrating an embodiment of interaction flow during channel change, indicated generally at <NUM>. Based on the least estimated waiting time, the customer can switch between a plurality of interaction channels any number of times. Since the queue waiting time for each channel is dynamically updated in the background, the Push-In notification through the user interface makes it visible for the customer to make appropriate decisions on changing the mode of interaction. <FIG> illustrates an example of the flow of control from the mobile application until the customer is connected to the contact center using any chat channel after it has been identified that the waiting time for the voice channel is considerably higher now that the customer has entered the voice channel queue.

In this example, the Mobile application has identified the voice channel as having the least estimated wait time. The customer has specified to the Mobile Application that they prefer the voice channel. The Mobile Application 600a sends a SIP invite <NUM> to the SIP Server 600b. The SIP Server 600b sends an invite <NUM> to the Universal Routing Server 600c. The Universal Routing Server 600c sends an OpenStat request <NUM> to the Stat Server 600d. The Stat Server may find that no agent is available and provides a stat open acknowledgement <NUM> to the Universal Routing server 600c which then provides the estimated waiting time <NUM> to the SIP Server 600b. The customer is waiting in the voice channel queue for the agent, but then receives notification from the Mobile App 600a that other channels might be available with shorter waiting times. For example, the chat channel may now have the least estimated waiting time compared to the voice channel waiting time. The notification may be provided as a screen pop in the UI to the customer where the customer can select a new channel from those offered by the contact center. The customer elects to switch to the chat channel from the voice channel while still waiting in the voice channel queue. The Mobile Application 600a sends a WebAPI request <NUM> to the Mobile Services Platform 600e. The Mobile Services Platform 600e sends a login request <NUM> to the Chat Server 600f. The Chat Server 600f returns an event status <NUM> to the Mobile Services Platform 600e, which then returns a join request <NUM> to the Chat Server 600f. The Chat Server 600f sends a create request <NUM> to the Universal Contact Server <NUM>. The Universal Contact Server <NUM> responds with the IXN ID <NUM> to the Chat Server 600f. The Chat Server 600f sends a submission request <NUM> to the Interaction Server <NUM>, which acknowledges the event <NUM> to the Chat Server 660f. The Interaction Server <NUM> sends an event routing request <NUM> to the Universal Routing Server 600c. The Universal Routing Server 600c then sends an OpenStat request <NUM> to the Stat Server 600d. The Stat Server 600d acknowledges the stat has been opened <NUM>. The Universal Routing Server 600c then sends a route request <NUM> to the Interaction Server <NUM>. An event invite <NUM> is sent to the Agent 600i by the Interaction Server <NUM>. The Agent 600i accepts the chat <NUM> and the connection is made to the customer with the mobile application 600a.

Claim 1:
A method for facilitating a change from a first communication channel (<NUM>) to a second communication channel (<NUM>) for an interaction within a contact center system for a first party after the interaction has been initiated and the first party is in queue for the first communication channel (<NUM>), comprising:
a. providing, through a user interface (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) interoperably connected to the contact center system through a mobile application, the first party with estimated queue wait times for a plurality of communication channels (<NUM>) associated with the contact center system;
b. initiating an interaction through receiving a selection from the first party of the first communication channel (<NUM>) from the plurality of communication channels (<NUM>);
c. processing the first selection by a service associated with the first communication channel (<NUM>), and routing the interaction into a queue associated with the first communication channel (<NUM>);
d. informing, through the user interface (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) while the first party is waiting in the queue for the first communication channel (<NUM>), the first party of estimated queue wait times associated with each of the plurality of communication channels (<NUM>);
e. providing, through the user interface (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) while the first party is waiting in the queue for the first communication channel (<NUM>), the first party with the capability to switch channels through selection of a prompt associated with each of the plurality of communication channels (<NUM>);
f. receiving a selection from the first party of the second communication channel (<NUM>);
g. transferring, via a switch channel API, the interaction from the queue associated with the first communication channel (<NUM>) to a queue associated with the second communication channel (<NUM>).