Please ensure Javascript is enabled for purposes of website accessibility
Cisco UCCE/PCCE and Mindful Integration Guide (With Datastore)
  • 30 Nov 2023
  • 23 Minutes to read
  • Dark
    Light
  • PDF

Cisco UCCE/PCCE and Mindful Integration Guide (With Datastore)

  • Dark
    Light
  • PDF

Article Summary

The Mindful Callback integration with the Cisco UCCE/PCCE platform utilizes reliable SIP-based communication without the need for custom development. The example integration presented in this guide allows the UCCE/PCCE platform to offer callbacks to customers and only send calls to Mindful Callback when an offer has been accepted. Making the offer in the Cisco environment is the recommended best practice for this integration. 

This integration also utilizes the Mindful Datastore application to provide a repository for user data (PVs and ECCs) that can accessed by ICM scripts and Mindful Callback.

In this guide, we present configuration requirements for the following processes and components.

  • Configuring DIDs for the contact center and high-priority holding queue
  • Call routing via ICM scripts
  • Establishing an offer threshold in Cisco UCCE/PCCE based on the wait time
  • Providing a callback offer on the UCCE/PCCE platform
  • Retaining user data between Callback and UCCE/PCCE via Mindful Datastore
NOTES
  • For further validation against additional integration options, please contact a Mindful representative.
  • This article is not intended as a configuration guide for a Cisco UCCE/PCCE environment. For help with UCCE/PCCE deployments and configuration, consult the official Cisco documentation.
  • Are you looking for the Cisco PCCE and Mindful Callback Integration Guide without Mindful Datastore? The non-Datastore version uses SIP Headers to retain user data instead.
  • PCCE 12.5 and UCCE 12.1 were used to validate the integration.
BEST PRACTICES
  • When quoting the estimated wait time prior to offering a callback, it is a best practice to set an upper limit for the amount of time that can be quoted. For example, if the wait time exceeds 10 minutes, you might choose to say "...more than than 10 minutes from now" rather than quoting an exact time.
  • We recommend setting a minimum offer threshold based on the current estimated wait time to ensure that callback offers are not made when wait times are very low. You may also wish to check agent availability prior to offering a callback.

Overview

This integration guide covers the following topics.

  • Components and architecture
  • Step 1: Configure your Mindful account
  • Step 2: Install CTI Event Relay on a Windows server
  • Step 3: Configure your SBC
  • Step 4: Configure your UCCE/PCCE environment
  • Call flow diagram
  • Optional: Consolidate return-call destinations
  • Optional: Offer Second Chance Callback

Components and architecture

Expand the following content to to review the definitions of acronyms and terms used throughout this guide. You can also view a high-level overview of the components and architecture of the integration before getting started.

View acronyms and definitions

TermDefinition
DNDialed number
ECC variablesExpanded Call Context (ECC) variables are used by ICM to store and preserve contextual call data.
Peripheral variablesPeripheral variables are also used by ICM to store and preserve call context.

View components and architecture
architecture diagram

Mindful Callback componentDescription
SIP ProxiesSend and receive SIP messaging
RTP ProxiesEstablish and maintain RTP streams
Callback ApplicationTracks callbacks and system configuration
Management InterfaceProvides a user interface for administrators
DatastoreStores and provides user data KVPs
Cisco UCCE/PCCE componentDescription
SBCEAvaya Session Border Controller for Enterprise was used in the Mindful lab to validate the Cisco UCCE/PCCE and Mindful Callback integration.
VXML Gateway / CUBECisco Unified Border Element (CUBE) provides several features of a session border controller (SBC).
ICMIntelligent Contact Management (ICM) provides scripting and routing features in the UCCE/PCCE environment.
CVPCustomer Voice Portal (CVP) provides the main call routing features used in this integration.

Step 1: Configure your Mindful account

Before your ACD can send inbound calls to Mindful, there are a few items that must be configured on the Mindful side:

  • At least one Call Target to register and dial callbacks
  • One Scheduler Widget for each Call Target used in the integration
  • A Data Set Template in Mindful Datastore (if you intend to use Datastore to store custom user data and context)

Call Target configuration

There are a few settings in Callback that must be adjusted to integrate with your ACD.

Registration

Quick access: Callback > Call Targets > Your Call Target > General tab > Registration

  • Offer ASAP Callback: Select this checkbox to offer callbacks to be returned as soon as possible.
  • Offer Scheduled Callback: Select one or both of these checkboxes (Voice and/or Widget/API) if you wish to offer callback scheduling for specific dates and times.

Contact Center

Quick access: Voice > Call Targets > Your Call Target > General tab > Contact Center

  1. Callback Telephony Type: Select SIP.
  2. Callback Number: This will be configured in a later step.

Callback Strategy

Quick access: Voice > Call Targets > Your Call Target > General tab > Callback Strategy

Most of the Callback Strategy settings are not relevant to the integration, and they can be set however you would like. However, there is one notable exception when using the Customer First Callback Strategy.

When using Customer First, enable Wait for live Agent. This will prompt agents to press a digit to accept a callback, which provides an Agent Answer event to Mindful. The Agent Answer events assist in calculating an accurate Estimated Callback Time (ECBT).

screenshot of the wait for live agent setting

Phone Numbers

Quick access: Configuration > Phone Numbers

On the Phone Numbers page, provision as many SIP numbers as needed and assign a number to each Call Target in your Organization. This is the number to use when configuring the SIP endpoint to which to send inbound calls for callback treatment.

Scheduler Widget configuration

Each Call Target used in the integration will require a Scheduler Widget. These Widgets will provide API endpoints that will allow your ACD to check the status of a Call Target before forwarding an inbound call to Mindful. Important points for the Widgets used in this integration are listed below:

  • Template: Select any Scheduler Template. Templates will not be used since this Widget will only be accessed via API, but Mindful Callback requires a Template to be assigned.
  • Call Target: Select the appropriate Call Target. The ACD will check the status of this Call Target (via the Widget) to ensure it is ready to register callbacks before transferring inbound calls to Mindful.

For complete instructions on creating Widgets, see Getting Started with Scheduler Widgets.

Datastore configuration

Mindful Datastore allows you to store user data to maintain call context at critical points in an interaction. If you intend to use Datastore, you will need to perform the next few steps within the Datastore user interface.

A Data Set Template contains a collection of Data Keys that allows the Mindful Datastore to store customer data during the callback request process. This collection includes:

  • The set's name and description
  • How long you want to retain collected data submitted with this Data Set
  • What information you want the set to collect (through configuration of Data Keys)
  • The API token that is used to associate data submitted via POST requests and return information via GET requests

The Mindful Solution Delivery team can assist with setting up a Data Set Template, as well as a unique authentication token. To create one on your own, use the steps below.

Quick access: Datastore > Data Set Templates

  1. On the Data Set Templates page, click Add Data Set Template. This takes you to the New Data Set Template page.

screenshot of the data set templates page

screenshot of the new data set template page

  1. Name: Enter a name that will be recognizable to others in your organization.
  2. Description: Enter a description for the benefit of other Administrators.
  3. Data Retention Period (Hours): Manually enter or use the +/- buttons to customize your Data Retention Period. You can retain data for 1 hour, or for up to 48 hours.
  4. API Token: The system automatically generates your API Token.
IMPORTANT
If your API Token is already plugged into your routing logic, regenerating the token here will break that link. To re-establish the link, update your host with the new API Token. Contact Mindful Support for assistance.
  1. Template Data Keys: You can select from existing Data Keys in your system or add new keys. The selected keys will filter out any submitted data that does not correspond to one of the configured keys, and will only retain submitted data that matches the configured keys.

Add a Data Key

Click Add Template Data Key. This opens the New Template Data Key modal window.

  1. Click in the Manually Enter Data Keys field. 
    1. If your Mindful Datastore instance contains existing Data Keys, select one from the dropdown list that appears.
    2. If not, type the name of a new Data Key here.
  2. When finished, click Add.

Your key now appears in the Template Data Keys list.

EXAMPLE
In our example integration, we set up the following Data Keys for callbacks:
example data keys
  • FirstName
  • LastName
  • AccNum
  • CallId

You can configure Data Keys in the same way for any user data that you need to maintain in your environment.

Call Targets > General tab > Mindful Datastore Integration

With the Mindful Datastore integration already enabled for your Organization, you can now enable it for individual Call Targets. Complete the following steps for all Call Targets within your Organization:

Quick access: Call Targets > Your Call Target > General tab > Mindful Datastore Integration

  1. Select the Mindful Datastore Integration checkbox to reveal additional settings below.
  2. In the Data Set Template field, select the Template that you created in a previous step.

datastore integration


Step 2: Install CTI Event Relay

The CTI Event Relay is an on-premise component that must be installed on a Windows server. CTI Event Relay passes user data between UCCE/PCCE and the Mindful Datastore application. In a later section of this guide, we will configure an Application Gateway in the Cisco environment to allow communication between the UCCE/PCCE platform and Mindful Datastore.

Installation notes

Consult the following instructions and notes to run the CTI Event Relay Setup Wizard:

Quick access: Mindful Datastore > Data Set Templates

  1. Click Edit on the Data Set Template you want to connect to your Mindful Callback instance. This takes you to the New Data Set Template page.
template data keys
  1. Click +Add Template Data Key. This opens the New Template Data Key modal.
new data set template
  1. Download the CTI Event Relay executable (.exe) file by clicking the Click to download the CTI Event Relay link. Then click Cancel to close the modal.
new data key
  1. Launch the .exe file. You may need to grant permissions for this trusted executable file to be run.
  2. Close all other applications before starting the Setup Wizard. This keeps you from having to reboot your computer if there are relevant system file updates that need to occur during setup.
  3. Follow the Setup Wizard prompts.
  4. On the first config page:
installer
  • IP Address and Port number for the local machine the event relay is being installed on.
  • API Access Token copied from the Mindful Datastore's Data Set Templates page.
    Quick access: Mindful Datastore > Data Set Template
    • In the template list, select the API Token for your Data Set Template, and copy the token string.
    • Return to the config page and paste the API Token into the API Token field.
  1. Confirm the Destination Folder where the CTI Event Relay will live.
  2. Next, click Install. You will see a progress bar advance until installation is complete. 
  3. When installation is marked as Completed, click Close.
installer
  • Local IP Address: The IP Address of the Windows server on which the CTI Event Relay is installed
  • Local Port: The TCP port on which the CTI Event Relay will listen for connection requests from the Application Gateway.
  • Datastore API Token: The Datastore API token generated in a previous step 

Configuration notes

Locate the CTIEventRelay folder using the file path from Step 8 under Download and install.

IMPORTANT

Work with the Mindful Solution Delivery team to integrate the CTIEventRelay with your telephony system.

Configuration details

appsettings.json houses the configuration items for the EventParser and CTIEventRelay

Item name

Description

switch_type

Sets the default root log path for log files

Currently only supports the value of TIALICM.

local_ip_hostname

The IP or hostname to start the Application Gateway server on. 

More than likely this should be the IP or hostname of the machine that the CTIEventRelay is running on.

local_port

The port that the Application Gateway server will be listening on

datastore_url

URL to the data_sets API of the Datastore

api_token

API token that correlates to the Datastore data set

log_level

Controls the verbosity of the logger. By default this should be set to 5

log_path

Sets the default root log path for log files


Example configuration

{
    "switch_type": "TIALICM",
    "local_ip_hostname": "10.100.61.14",
    "local_port": 3000,
    "datastore_url": "https://qa-datastore.vhtops.net/api/v1/data_sets",
    "datastore_api_token": "KV+xz9REqgfGpvZK31VV6UGeq78Y9oYinGCRzlvWha4=",
    "log_level": 5,
    "log_path": "C:\\EventRelay\\Logs"
}
 


Logging

Startup logging

On startup, the logs will be quiet until events start coming into the system unless there was an issue loading the TIAL dll or an issue starting the Application Gateway server.

Log messageLikely causesNotes
TIALWrapper::TIALWrapper|Failed to load DLL: TIAL_ICM.dll
  • Mindful Datastore failed to load the TIAL dll.
n/a
TIALWrapper::TIALWrapper|Failed to load DLL:[dll name](presence of dll name)
  • An issue locating the dll.
The switch_type was set correctly.
TIALWrapper::TIALWrapper|Failed to load DLL:(no dll name)
  • The switch type was not set correctly.
n/a
TIALWrapper::TIALWrapper|Failed to initialize AppGWServer with HostName 10.100.61.14 and Port 3000
  • Mindful Datastore failed to start the Application Gateway. 
  • Hostname is not correct.
  • Port is not available.
n/a
 

Event Processing 

When an event enters the system, initial checks are made, and the event may be discarded as a result of missing fields or unexpected values.

Log messageLikely causesNotes
DS_GET:1234567890n/aWe expect the subtype to be either DS_GET or DS_POST. These values can be suffixed with the customer's contact number.
TIALWrapper::process_event|Failed TEPRM_SubType missingThe subtype field is missing.n/a
TIALWrapper::process_event|Failed invalid TEPRM_SubType: Some_Other_ValueThe subtype is not:
  • DS_GET or
  • DS_POST
n/a
TIALWrapper::process_event|Failed|customer contact number not set
  • The subtype is not suffixed with customer's contact number  AND
  • The calling line ID is not set with the customer's contact number
We expect either the calling line ID to be set or the contact number to be suffixed onto the subtype. The contact number in the subtype takes precedence over the calling line ID if both are set.
TIALWrapper::process_event|Failed|could not create interaction IDThe router call key and router call day values are not available.The router call key and router call day are used to generate an interaction ID for the request.
TIALWrapper::process_post|Sending POST request for interaction ID = 153288|301n/aSend a POST request to the Mindful Datastore.
TIALWrapper::process_get|Sending GET request for interaction ID = 153288|301n/aSend a GET request to the Mindful Datastore.


Web requests to Mindful Datastore

Log messageLikely causesNotes
GetHandler|Failed|interaction ID = 153288|301|Datastore URL = https://qa-datastore.vhtops.net/api/v1/data_sets|HTTP Response Code = 500Unsuccessful GET request to the Mindful Datastore.n/a
PostHandler|Failed|interaction ID = 153288|301|Datastore URL = https://qa-datastore.vhtops.net/api/v1/data_sets|HTTP Response Code = 500Unsuccessful POST request to the Mindful Datastore .n/a
GetHandler|Exception|interaction ID = 153288|301|Datastore URL = not://a.valid-uriGetHandler Exception orccurred:
  • URI is not valid or
  • Network connectivity issue
n/a
PostHandler|Exception|interaction ID = 153288|301|Datastore URL = not://a.valid-uriPostHandler Exception occurred:
  • URI is not valid or
  • Network connectivity issue
n/a


Mindful Datastore - Data Keys

Call Variables

Up to 10 call variables are supported. The expected key names are as follows:

call_variable1, call_variable2, call_variable3, call_variable4, call_variable5, call_variable6, call_variable7, call_variable8, call_variable9, call_variable10

Call Context Collection

The expected key name is:

call_context_collection

app settings dot json

In the appsettings.json configuration file, you may need to update the datastore_url field. The default value assumes you will use direct HTTPS over port 443 to reach the Datastore application. If you are using a proxy server pointed to the Datastore application, enter the appropriate proxy URL instead.


Step 4: Configure your SBC

Mindful Callback integrations can function with different Session Border Controller (SBC) products regardless of the ACD platform used in your environment. Click any of the links below for instructions on integrating your chosen SBC.

  • Avaya Session Border Controller Enterprise (SBCE)
  • Cisco Unified Border Element (CUBE)
  • Audiocodes Mediant
NOTE
We plan to add integration guides for more SBC products over time. Check back here for updates or let us know if you would like us to cover a specific SBC!



Step 5: Configure your UCCE/PCCE environment

To complete the configuration of your UCCE/PCCE environment, you will need to configure the following items:

  • Dialed Number Pattern
  • Cisco SIP Proxy
  • Application Gateway
  • ICM Script and Application Gateway Nodes
IMPORTANT

If the Mindful Callback application utilizes Twilio trunks to receive inbound calls (default configuration), then the ANI of the call sent from the ACD environment to Mindful Callback must be in e164 format. The ANI must be prefaced with +1. If a custom range of DNs is used instead, e164 format is not required.


Configuring the Cisco environment using a SIP proxy and SBC

The following additional configuration is necessary to ensure that calls are allowed to leave the Cisco environment via the Cisco SIP proxy and SBC. Two tasks are required to accomplish this:

  1. Create a new Dialed Number Pattern to manage outbound calls.
  2. Update the configuration for allowable SIP headers in Call Server settings.
NOTES
  • Our example integration uses a Cisco 3900E ISR as the SIP proxy.
  • If no Cisco SIP proxy or other SIP edge device is available in your environment, you can use CUCM to send calls via a third-party SIP device. Using CUCM is necessary in this case because UCCE/PCCE does not allow third-party SIP proxies or SBCs to be added as route targets.
  • If the Mindful Callback application utilizes Twilio trunks to receive inbound calls (default configuration), then the ANI of the call sent from the ACD environment to Mindful Callback must be in e164 format. The ANI must be prefaced with +1. If a custom range of DNs is used instead, e164 format is not required.



Configure a new Dialed Number Pattern in CVP

Quick access: CCE Management interface > Call Settings > Route Settings > Routing Pattern

Create a Dialed Number Pattern to identify calls coming from CVP that are 11 digits long and begin with 1. The pattern should send the identified calls to the SIP proxy. The following image shows how this is configured in our example integration.

route settings

Configure the Cisco SIP proxy for outbound calls to the SBC

Create a dial peer on the Cisco SIP Proxy to send calls from CVP that match a specific number pattern out to the SBC. In our example, we configured the SIP proxy to catch numbers beginning with 1 that are 11-digits long. Use the following example as a guide to create the dial peer.

dial-peer voice 1 voip
 destination-pattern 1.........
 session protocol sipv2
 session target ipv4:10.100.70.31:5060
 session transport udp
 incoming called-number 1.........
 voice-class codec 12
 voice-class sip early-offer forced
 voice-class sip pass-thru headers unsupp
 voice-class sip referto-passing
 dtmf-relay rtp-nte
 no supplementary-service sip refer
  • destination-pattern: Use 1......... (10 digits total)
  • session target: Use the IP address of the SBC’s internal signaling interface.
  • dtmf-relay: Specify rtp-nte (This allows RFC2833 DTMF)
  • voice-class sip pass-thru headers: Specify unsupp (This is very important. A value of unsupp allows custom SIP headers to be passed through the SIP proxy. Without it, SIP headers would be stripped from the signal before the next leg of the call.)

Create ICM scripts

In this step we will configure an existing ICM script to push user data to the Mindful Datastore API prior to sending inbound calls to Mindful Callback. For return calls, we will configure a new ICM script to retrieve data from Mindful Datastore before queuing to an agent skill.

Click both of the following tabs for configuration instructions for the inbound and callback script.

1. Inbound ICM script

Add the following three new nodes into your existing inbound ICM script:

  1. Set Variable
  2. Gateway
  3. Label

These nodes should be placed after PV and ECC data has already been populated and after the callback offer decision has been made affirmatively.

routing blocks

1. Set Variable node

set variable node

The Set Variable node ensures that the calling line ID is in the expected format. The calling line ID should contain the customer's phone number, which will be used as the key for KVPs sent to Mindful Datastore. To meet the expected format, the calling line ID must include a 1 in front of the 10-digit phone number.

2. Gateway node

gateway node

The Gateway node invokes the POST logic to send the selected PVs and ECCs to the CTI Event Relay application on the Windows server. CTI Event Relay will then forward the data to the Mindful Datastore application. 

You can ignore the Receive tab for now.

3. Label node

label node

The Label node is placed at the point where we are ready to send calls to Mindful Callback for treatment, going from CVP, through the SBC, to Mindful Callback.

  • Label Type: Set to Dynamic in order to allow a custom target number. This should be Dynamic unless you are routing to a pre-configured fixed label.
  • Label Expression: Enter the Call Target phone number provisioned in the Mindful Callback application. This can be a variable if the Call Target phone number is defined elsewhere in the IVR script or if it is the default value of the variable.
  • Enable target requery: Select the checkbox to allow error handling to occur.

The exit from the Label block will only occur if a call fails to route to Mindful Callback. In this case, the call will be sent to queue according to normal routing procedures.

NOTES
  • If Enable target requery is not selected, the Cisco platform will not handle any errors that may arise when it attempts to send calls to Mindful Callback. Instead, it will drop calls if errors occur. 
  • When Enable target requery is selected, an exit port is made available from the Label block to allow calls to continue routing to an agent skill or to be handled in another way.


2. Callback ICM script

Add the following two nodes into a new return-call ICM script to invoke when callbacks are received.

  1. Set Variable
  2. Gateway

These nodes should be invoked before ICM sends calls to queue to an agent skill at high priority.

routing blocks

1. Set Variable node

set variable node

The Set Variable node ensures that the calling line ID is in the expected format. The calling line ID should contain the customer's phone number, which will be used as the key for KVPs sent to Mindful Datastore. To meet the expected format, the calling line ID must include a 1 in front of the 10-digit phone number.

In this callback ICM script, the phone number will have been populated by Mindful Callback before returning the call.

2. Gateway node

gateway nodegateway nodeThe Gateway node invokes the CTI Event Relay application on the Windows server to retrieve the stored PVs and ECCs from Mindful Datastore. Remember that the customer phone number will be used as the key when retrieving KVPs from Datastore.

In the Receive tab, select the specific PVs and ECCs you expect to receive.



Call flow diagram

Callback Call Targets use a complete phone number for the inbound call transfer. Each Call Target represents a queue/skill/group, such as Sales or Billing.

The call flow examples use three example Call Targets with the following phone numbers.

  • Support Call Target: 111-111-1111
  • Sales Call Target: 222-222-2222
  • Billing Call Target: 333-333-3333

call flow diagram


(Optional) Consolidate return-call destinations

Expand the content below to learn about best practices for return-call routing when the same group of agents are spread out among multiple queueing destinations.

Configure consolidated return-call destinations

This integration guide has assumed that each Call Target is configured with a Call Center Phone Number leading to a single group of agents in your call center. However, in some ACD environments, the same group of agents are spread out among multiple queueing destinations. Since a Call Target is intended to serve a particular agent group, there needs to be a way to deliver callbacks and return-to-hold calls to a single destination that can ultimate route calls throughout the entire agent group.

You can configure a Call Target to send calls to a Call Center Phone Number that leads to a shared disposition destination, then make further routing decisions based on data attached to the call. This form of queue consolidation allows you to route return calls among multiple destinations representing the same group of agents.

How it works

Using a consolidated callback destination requires custom data to be passed to Mindful Callback with inbound calls to identify their ultimate return destinations. This can be done in two ways:

  • Send the destination to Callback via SIP Headers. This requires that you configure additional Metadata Items for each affected Call Target. Or...
  • Post the destination to the Mindful Datastore application, using the customer's ANI as the data key. This method can be used even when calls are delivered via the PSTN rather than SIP.

In either case, Callback will re-attach the custom data to the return call (whether it is a callback or a customer returning to hold) and deliver the call to a single return-call disposition destination. From there, you can use the custom data to route the call to the appropriate agent groups.

NOTE
We recommend using different universal return destinations for callbacks and callers who chose to hold. The choose-hold destination is only needed if the Callback Offer or the End of Day Handling > Return to Hold settings are enabled.
EXAMPLE
Consider the following example. Let's say you have the same agent skill assigned to different queueing destinations labeled 111, 222, and 333. You have a single disposition destination for callbacks and another for return-to-hold calls. In this case, the routing path for a callback could look like this:example routing diagram
  1. You identify that a particular new inbound call should ultimately be delivered to 333, so you attach that destination number to the call as custom data when sending it to Callback for treatment. 
  2. When the time comes, Callback delivers the return call (a callback in this case) with the destination number still attached.
  3. When the call arrives at the callback disposition destination on your ACD, additional routing logic ensures that the call ends up with agents at 333. 
  4. The appropriate priority is set, and the call is delivered to an agent.



(Optional) Offer Second Chance Callback

Expand the content below to learn how to make additional callback offers in your holding queue after a customer has declined the initial offer.

Configure Second Chance Callback

Second Chance Callback is a best-practice methodology that can increase the take-rate of callback offers and lower the abandon rate in your call center's holding queues. With a few updates to your routing logic, you can provide additional callback offers to customers waiting on hold who have already declined an initial offer. 

There are a variety of reasons that customers might appreciate a second chance to accept an offer of a callback. For example, perhaps something has come up that requires their attention and they can no longer wait on hold. Perhaps the quoted wait time was low when they declined the first offer but queue conditions have quickly changed and resulted in a longer hold time. Regardless of the scenario, Second Chance Callback ensures that customers have the callback option available when they need it.


Benefits

Our research shows positive results for call centers offering Second Chance Callback, including:

  • Keeping customers in control with additional options while holding.
  • Reducing abandoned calls in the holding queue by offering an alternative option.
  • Fully controlling Second Chance offers in your ACD with no integration constraints.
  • Adding another tool to address unexpected increases in hold time.
  • No additional requirements for customers. They are not required to respond to Second Chance prompts, but can instead simply continue to wait on hold if they choose.

ACD configuration

Most configuration for Second Chance Callback is done on your ACD platform, so the technical implementation will vary based on your integration. In all integrations, the following logic must be introduced to interact with customers in the holding queue.
second chance callback flow diagram

  1. Whether offers are made in your ACD or in Mindful Callback, the process begins with the first offer. If the initial offer is accepted, then a callback is registered and no Second Chance offer is needed.
  2. If the initial offer is not accepted, callers are routed to a holding queue.
  3. A timer begins in the holding queue. When the specified time expires, another callback offer is made. 
  4. If the customer declines the Second Chance offer, then the timer is reset, and another offer will be made when it expires again.
  5. If the customer accepts the Second Chance offer, the call is sent to Mindful Callback for treatment.
NOTE
You can add logic into the routing script to limit the total number of offers made per call.

THINGS YOU'LL NEED

If you wish to use a single Call Target for normal inbound calls and Second Chance calls, you will need:

  • Two Phone Numbers provisioned for the same Call Target.
  • The Return to Hold Call Target setting disabled. Offering a hold option in Mindful Callback after a customer has already chosen to leave the holding queue can negatively impact the customer experience.

If you wish to use separate Call Targets for normal inbound calls and Second Chance calls, you will need:

  • Two Call Targets configured with the same Call Center Phone Number targeting the same group of agents.
  • The Return to Hold setting disabled for the Second Chance Call Target. The setting can still be enabled for the normal inbound Call Target.

For either method, you will also need:

  • The ability to capture DTMF input from customers in your holding queue.
  • The ability to play audio prompts to customers in your holding queue based on a timer.

Mindful Callback configuration

There are two alternatives for preparing your Mindful Callback account for Second Chance Callback. Each alternative introduces its own advantages and drawbacks.

  • Option 1 (best practice): Use separate Call Targets for normal inbound calls and Second Chance calls.
  • Option 2: Use a single Call Target for both normal inbound calls and Second Chance calls.

Option 1 (best practice): Use separate Call Targets

This option uses the first Call Target to service normal inbound callback requests with a second Call Target dedicated to servicing Second Chance callback requests. For an initial offer, send the call to the first Call Target. For a Second Chance offer, send the call to the second Call Target. This option separates the two types of calls for ease of reporting and real-time analysis.
multi call target example

AdvantagesDrawbacks
Call Detail reporting is more convenient.ECBT is not combined between the two Call Targets. Therefore, ECBT on the normal inbound Call Target may be lower than it should be, since the call volume from the Second Chance Call Target is not included in the calculation.
Real-time monitoring clearly distinguishes the two call types. 
You can enable the Return to Hold option on the normal inbound Call Target while disabling it on the Second Chance Call Target. 

Option 2: Use a single Call Target

The second option uses a single Call Target to service both normal inbound callback requests and Second Chance requests. This method is easier to configure and maintain, but it introduces a few additional drawbacks to consider.

single call target example

AdvantagesDrawbacks
Configuration is simpler.When a Second Chance ASAP callback is registered, it will be placed at the back of the virtual queue or waitlist. This can result in customers who accept Second Chance offers waiting longer than they would have if they remained in the holding queue.
 Return to Hold should not be offered by the Call Target. This can affect your offer strategy for normal inbound calls, which may not be intended.
 Reporting on Second Chance interactions requires additional steps.
 Real-time monitoring combines normal inbound callback requests and Second Chance requests together.

Reporting on Second Chance Callback interactions

As noted in the lists of advantages and drawbacks, reporting on Second Chance interactions varies depending on whether you use one or two Call Targets.

Reporting with separate Call Targets

On the Metrics, Executive Summary, and Call Detail pages, use the Call Target filter to view data only for the Second Chance Call Target. This will exclude any data from initial offers and callers that chose to hold. If you offer Second Chance for multiple lines of business, you can add all of your Second Chance Call Targets into a shared Reporting Category to view all Second Chance interactions.

On the Callback Status page, review real-time statistics for the Second Chance Call Target or use the Category filter to limit the view to only Second Chance Call Targets.

Reporting with a single Call Target

When using a single Call Target, additional configuration is required and the reporting capabilities are limited.

Preparation:

  1. Provision two Phone Numbers in the Mindful Callback user interface, and assign both Phone Numbers to the same Call Target.

phone number assignment

  1. In your routing scripts, send normal inbound calls for callback treatment to the first Phone Number.
  2. Send Second Chance calls for treatment to the second Phone Number.

Reporting:

  1. On the Call Detail page, export the reporting data to CSV. In the exported CSV file, the Call Target Phone Number to which each call was sent will be noted in the Source column.  
  2. In the CSV file, filter the Source column for all records matching the Second Chance phone number. The remaining data will include only Second Chance interactions.
NOTE
When using a single Call Target, the Callback Status, Metrics, and Executive Summary pages will combine Second Chance interactions with initial offers and callers that chose to hold.

Was this article helpful?

Changing your password will log you out immediately. Use the new password to log back in.
First name must have atleast 2 characters. Numbers and special characters are not allowed.
Last name must have atleast 1 characters. Numbers and special characters are not allowed.
Enter a valid email
Enter a valid password
Your profile has been successfully updated.