Callback Assist InterOp with Avaya Aura Contact Center. Application Note

Transcription

1 Callback Assist InterOp with Avaya Aura Contact Center 7.x Abstract This application note applies to Avaya Aura Contact Center 7.x. It describes how Avaya customers can configure & use Callback Assist (or higher) in an Avaya Aura Contact Center deployment. This document will detail the supported version, the configuration & supported functionality for the interop. (1) Avaya Aura Contact Center implies Full/Complete (Voice and Multimedia) functionality when used throughout the document. 1 of 20

2 Table of Contents Foreword: Important Instructions for All Readers Introduction Callback Assist Application Gathering information for callback request Placing a callback Callback Assist Installation & Configuration AACC Configuration Sample Script CDN changes Callback Assist Interop Call Flow Diagrams Call Flow Details Agent Experience Reporting of the callback calls Limitations High Availability Interop with ACCS Callback capacity Glossary References and Documentation of 20

3 Foreword: Important Instructions for All Readers This document contains important instructions for customers who are utilizing an Avaya Aura Contact Center solution with Callback Assist application. 3 of 20

4 1. Introduction Although most contact center administrators acknowledge that the customer call should be handled promptly, it is not always possible to have agents available. It would not be cost effective to staff the contact center based on the peak call rates and even if this was possible there are various factors like the duration of the call, events related to the product being serviced by the contact center, etc. that create times when the caller has to wait in queue for his / her call to be answered by an agent. On such occasions, applications, like call back assist, can be useful both to the caller and contact center. To the caller, it can present an option to schedule a call back at some later time when an agent is available. For the contact center, it can be useful because it helps reduce the number of calls waiting in a queue Callback Assist Application When a caller calls a contact center, and if the average wait time for an agent to answer the call is going to be more than certain/acceptable time limit then there is an option for the caller to leave his / her details and request a callback. With SIP AACC 7.0, contact center application interoperates with Avaya CBA application. For an incoming CDN call, if the Estimate Wait Time is beyond a certain threshold, the call is routed to a CBA application using the Route Call command in TFE script. This results in the call being handed off to CBA application. CBA application then plays an IVR to the customer asking him/her, what it should do with the call. With the currently supported CBA version, the options are: 1. Maintain customer s position in the queue, i.e. requests a callback when its customer s turn. This option maintains customer s position in the queue by immediately placing a call to AACC once customer hangs up the call. 2. Request a callback at a scheduled time. In this case, CBA application requests the customer to enter the preferred time and the number on which he wishes to receive a callback. From CBA s point of view the following are the steps involved: Collecting information for the callback request Placing a callback. This involves a. placing a call to the contact center b. placing the call to the customer c. transferring the call 4 of 20

5 Gathering information for a callback request CBA can operate in following two ways: 1) The customer call is front-ended by CBA application: When a call comes in, CBA checks the Estimate Wait Time (EWT) for that call to be answered. If the time is above a certain threshold, then the customer is played an IVR with an option to leave his details for a callback. 2) The customer call is front-ended by contact center: When the call comes in to contact center, the contact center script queries the EWT for the call and plays a prompt to the customer. If the customer chooses to schedule a callback, then the call is transferred/routed to CBA application. AACC s interop with CBA is designed using approach two mentioned above Placing a callback Regards placing a callback, CBA can operate in one of the following two ways: 1) Customer first approach: With this approach, CBA first initiates a call to the customer at the scheduled time. If the customer answers the call, it will then place a call to the contact center. When an agent answers the call, CBA application completes the transfer leaving customer and the agent on the call. 2) Agent first approach: With this approach, CBA first initiates a call to the contact center. When an agent answers the call, CBA application places the call to the customer. When the customer answers the call, CBA application completes the transfer leaving customer and the agent on the call. For AACC interop, CBA uses the agent first approach. To place a callback, CBA application initiates a phantom call to AACC. As far as AACC is concerned, this appears like a new CDN call. There will be a few markers on the call that will make AACC aware that this is a call from CBA application. The SIP INVITE will be sent with a custom P-Requires-Progress header with the value Callback Assist. The presence of this header with the said value makes AACC handle the call differently. Generally, when the call is anchored on Avaya Media Server, the call is considered fully connected, and the treatment begins to play. For the calls that have been initiated by the CBA application, the treatment starts, however, the call is not considered fully connected. The call will be placed to specific CDNs. CBA application placing a call to specific CDNs (termed as shadow CDNs detailed in the later sections of this document) is not mandatory but is a recommended approach. Using specific CDNs will help with reporting of such calls. Also, calls to these CDNs can receive prioritized queueing. 5 of 20

6 When an agent answers this phantom call, AACC sends a trigger to CBA application saying the call is now fully connected and has an agent on the other side of the call. SIP messaging call flow is detailed in the later section of this document. CBA application plays an IVR to the agent informing him that it will now attempt calling the customer and initiates a call to the customer. When the call is answered by the customer, CBA application transfers the call leaving customer and the agent on the call. 6 of 20

7 2. Callback Assist Installation & Configuration For CBA server requirements, installation, licensing, administration and configuring it for interop with AACC please refer to CBA documentation. These documents can be downloaded from support.avaya.com. 7 of 20

8 3. AACC Configuration There are no configuration settings required in AACC to enable the interoperability with the CBA application. OD application (TFE script) for voice call handling, however, will have to be modified to incorporate a check for estimate wait time and handing off the call to the CBA application. Also for better reporting and enabling prioritized treatment to calls that are initiated by CBA, it is recommended to create shadow CDNs Sample Script Following is a sample snippet of OD application. The script will perform the following tasks: Welcome the caller. Inform the caller regards the current estimate wait time for the skillset. Allow the caller to choose to wait in the queue or opt for a callback. If the caller selects to wait in the queue, then the call will be queued, and treatment in the queue will be played. If the caller selects to schedule a callback, then the call is routed to the CBA application. 8 of 20

9 3.2. CDN changes It is recommended that every CDN that provides the callback functionality should be shadowed. Consider an example where the customer-facing CDNs are 1001 & Sales CDN Create a Sales shadow CDN 1002 Support CDN Create a Support shadow CDN 2002 This approach helps with the reporting of the CBA initiated calls. It also enables calls initiated by the CBA application to receive prioritized queueing which is required for the following reasons: 9 of 20

10 There is no point in playing treatments to the calls that have been initiated by the CBA application irrespective of whether the call is initiated by the CBA application as a scheduled callback or in order to maintain customer s position in the queue. Another reason is that for a call that has been placed by the CBA application as a scheduled callback, in order that the call is presented to the customer at a near precise time, it is essential that there should be predictability in how long it will take for the CBA initiated call to be presented to an agent. 10 of 20

11 4. Callback Assist Interop Following is a summary of the interop in a nutshell: Supported CBA application version: CBA deployment configuration: CBA behind the contact center Call back strategy: Agent First approach Interop is supported only with AACC. From AACC s point of view, for an end to end customer call scenario where the customer has opted for a callback, there are two calls involved: Call 1: Customer call that is routed off to the CBA application. Call 2: CBA application initiated a call to the contact center. From CBA s point of view, there is the third call as well. Call 3: CBA application initiated a call to the customer. 11 of 20

12 4.1. Call Flow Diagrams Following two diagrams shows the call flow for the first call: 1 Call 1 4 CBA ASM Call routed to CBA 2 3 AACC Call routed off to the CBA application: CBA ASM Call routed off to CBA AACC 12 of 20

13 Following two diagrams shows the call flow for the second and the third call: 4 Call 3: Customer call initiated by CBA 3 CBA ASM 1 2 Call 2: CDN Call initiated by CBA application AACC Call transferred off by the CBA application: Call transferred off by CBA CBA ASM AACC 13 of 20

14 4.2. Call Flow Details The first call mentioned above is like any other customer call. The call is connected when the call is anchored on AMS. For the 2 nd call, however, the incoming SIP INVITE will contain a custom P-Requires-Progress header with the value Callback Assist. For this call that is initiated by the CBA application, CBA needs to know when the call is answered by an actual agent. If the call were to be fully connected when it is anchored on AMS, there would not be any further SIP messaging to inform the CBA application that an agent has answered the call. This requirement resulted in a change in the call flow. In the new call flow, when a SIP INVITE with the above-mentioned custom header comes into AACC for the call that is initiated by the CBA application, AACC responds with a 183 Session In Progress message instead of 200 OK when the call is anchored on AMS. This means that the call is not fully connected at this stage, however, there will be a two-way speech path which means that any treatments played by AMS can be heard by the CBA application and any IVR played by the CBA application will be heard by AMS. Start line of the SIP INVITE will contain the customer s number. This is the calling line id. Thus AACC will populate the CLID correctly as the customer s number. When the call is answered by the agent, AACC will send a 200 OK to the CBA application. With this now the CBA application knows that there is a live agent on the other side of the call. CBA application plays an IVR to the agent informing him that it will now attempt to call the customer. CBA application then initiates a new call to the customer. When the customer answers the call, CBA application will initiate a transfer which will result in AACC receiving an INVITE with Replaces, i.e. replace the SIP dialog between AAEP & AACC with the new SIP dialog the one between customer & AACC. When the transfer request is fully processed, the parties in the call will be the customer and the agent. This frees up CBA application resources to process another scheduled callback. 14 of 20

15 Following is a call flow diagram for CBA initiated call: Note: This call flow is similar to Toll-Free Queuing call flow. The similarity is that in both cases 200 OK acts as a trigger for the next action. Here for CBA application to initiate a call to the customer and in case of Toll-Free Queuing, 200 OK is sent to CM so that CM can then send an ISDN Connect message to the telecom service provider so that the call billing can start. The difference, however, is that in the above case the call is initiated by CBA application whereas in case of Toll-Free Queueing the call is initiated by CM. There is, however, no interaction of these features with each other and AACC can be configured to work with both these features simultaneously Agent Experience In the section above, we have detailed how AACC comes to know that the call that has come in has been initiated by the CBA application. However, how does an agent know that the call is a CBA initiated the call and not a call directly from a customer especially the fact the CLID will 15 of 20

16 state the customer s number? As mentioned previously, the recommendation is that the calls initiated by the CBA application should come into AACC for shadow CDNs. One can take this a step further by creating corresponding shadow skillsets, i.e. sales_callback, support_callback which shows up on agent desktop providing a visual indication to the agent. Please note it is not mandatory to create shadow skillsets. Irrespective of the visual indication, the agent will get an audio indication which is the IVR played by the CBA application when the agent answers the call. Please note that the Agent Greeting if configured will not be played to the call initiated by the CBA application. The greeting is played for the other calls not initiated by the CBA application. There is no additional setting required for this Reporting of the callback calls There are no new reports created in AACC for this feature. If there is a need to generate a report: For the calls that were handed over to the CBA application, one can generate a report of calls that were routed off to the CBA application number. For the calls that were initiated by the CBA application, one can generate a report of calls that came into the CBA specific CDNs (shadow CDNs). 16 of 20

17 5. Limitations 5.1. High Availability There will not be HA for the CBA calls that are not yet answered by an agent. This is because the SIP stack call leg snapshot is taken when the SIP call leg is established, i.e. for the SIP call leg from the CBA application when the call is answered by an agent. Hence for the calls initiated by the CBA application but not answered by the agent yet, the call leg is not transitioned to an established state. If a switchover was to happen at this time, the new active AACC would have no idea of such calls from the CBA application. This however should not be a problem because the call leg specific SIP timer will timeout and the CBA application will treat that as an error case. The call will be retried by the CBA application Interop with ACCS CBA interop is designed to work with AACC only. Interop with ACCS is not supported Callback capacity This is determined by the CBA application capacity. Currently, the maximum number of simultaneous callbacks that the CBA application can handle is of 20

18 6. Glossary Following are the frequently used acronyms in this document: Acronym / Term Description AACC Avaya Aura Contact Center ACCS Avaya Contact Center Select CBA Callback Assist AAEP Avaya Aura Experience Portal AMS Avaya Media Server ASM / SM Avaya Session Manager ACM / CM Avaya Communication Manager Customer A person who calls the contact center Agent Contact Center Agent EWT Estimate Wait Time 18 of 20

19 7. References and Documentation The following links contain all of the required standard documentation on the platforms described in this applications note. It is assumed that the reader(s) of this document are fully knowledgeable in the products described and their integration with each other. Avaya Aura Contact Center Documentation Suite: 19 of 20

20 2018 Avaya Inc. All Rights Reserved. Avaya and the Avaya Logo are trademarks of Avaya Inc. All trademarks identified by and are registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners. The information provided in these Application Notes is subject to change without notice. The configurations, technical data, and recommendations provided in these s are believed to be accurate and dependable, but are presented without express or implied warranty. Users are responsible for their application of any products specified in these s. 20 of 20