Cisco UCCE/PCCE and Mindful integration guide

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.

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
  • 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
Note:
  • 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.

  • The configuration in this guide is an example and may be used as a template for integrating with Mindful. Any sample code in this guide should not be considered ready for production.

Tip:
  • 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 Callback account
  • Step 2: Configure your SBC
  • Step 3: Configure your UCCE/PCCE environment
    • Alternative: Use CUCM to send calls via a third-party SIP proxy
  • 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.

TermDefinition
DNDialed number
CUCMCisco Unified Communications Manager (CUCM) provides call control and session management features. Using CUCM is optional for the UCCE/PCCE and Mindful Callback integration.
ECC variablesExpanded Call Context (ECC) variables are used by ICM to store and preserve contextual call data.
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
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 Mindful Callback

Provision a phone number

Provision a phone number in your Mindful Callback Organization and assign it to a Call Target. The Cisco platform will route inbound calls to this number for callback treatment. This number can be dialed via SIP using the URI format +<DID>@<Callback SIP endpoint>:<port> or via the PSTN by using the DID without the leading plus (+) symbol.

Phone numbers page

There are a few configurable settings in Callback that must be adjusted to integrate with the UCCE/PCCE platform.

Dial Settings

  • Set the Callback Telephony Type to SIP.
  • Callback Phone Number: Enter the address of the Cisco CTI DN to which callbacks will be sent.
    • Use the public IP address that is translated by your firewall to the external interface of the SBC.
    • Use the SIP port of the SBC external interface.
Note: For Government Users - SIP is the only Telephony Type supported in the Government instance.

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, select the Wait for live Agent checkbox. This will prompt agents to press a digit to accept a callback, which provides an Agent Answer event to the Callback application. The Agent Answer events are then used to assist in calculating an accurate Estimated Callback Time (ECBT).

Configure Metadata items

Before Mindful Callback can process data contained in SIP headers, each header must be defined as a Metadata item.

Use the following image as a guide to configure the necessary metadata item.

metadata tab

  • Name: User-to-User
  • Type: SIP Header
  • Max Length: 10
  • Terminator: N/A
  • Prompt: N/A
  • Persist forever: Disable to prevent unnecessary storage of data

Optional configuration

The Callback application supports SMS callback notifications, voice-to-messaging transitions, and proprietary drop-in web widgets to provide a digital callback offering.

To learn more about the many options available to configure your Call Target, see How do I set up a Call Target?.

Step 2: 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
  • Ribbon SBC
  • Oracle SBC
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 3: 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
  • Expected SIP headers
  • ECC variables
  • ICM scripts

Configure 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:

  • Create a new Dialed Number Pattern to manage outbound calls.
  • Update the configuration for allowable SIP headers in Call Server settings.
Note:
  • 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.
    • For more information about this alternative, see the CUCM section later in this guide.

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 sends the identified calls to the SIP proxy. The following image shows how this is configured in our example integration.

Important:

If the Mindful Callback application utilizes Twilio trunks to receive inbound calls (default configuration), then the ANI of the call sent from the Cisco 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.

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: 1...........
  • 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.

Define the expected SIP headers in CVP Call Server

Before SIP headers can be captured by CVP and provided to ICM scripts, you must first define the expected SIP headers in CVP Call Server.

Quick access: CVP OAMP interface > Device Manager > Unified CVP Call Server

All Call Servers in the list must be modified to match the same SIP header configuration. For each SIP header that you expect to send and receive, first click the SIP tab, then configure the headers in the SIP Header Passing section.

We included three SIP headers in our example configuration (first name, last name, and account number), but you can define any SIP headers needed in your integration the same way.

device configuration

Example SIP headers:

  • X-cisco-first-name
  • X-cisco-last-name
  • X-cisco-acc-num
Note: The SIP headers configured here should match the Metadata Items configured in the Mindful Callback application.
sip header passing

Configure ECC variables

The data received from the expected SIP headers will be placed into corresponding ECC variables, so the next step is to define the ECC variables that will be used. These variables will also be used to display user data in Finesse.

Use the following image as a guide to configure your ECC variables.

route settings

In our example configuration, we defined the following three ECC variables to correspond to our expected SIP headers.

  • user.acc_num
  • user.first_name
  • user.last_name
Note:

The Max Length field for each ECC variable was configured according to the needs of our example integration, but you may find that higher or lower Max Length values are needed in your environment.

Create ICM scripts

In this step we will configure ICM scripts to retain SIP headers and user data before either sending calls to the Mindful Callback application or queuing calls to an appropriate agent skill.

Both an inbound ICM script and a callback script are needed. Click both of the following tabs for configuration instructions for each script.

1. Inbound ICM script

The Inbound ICM script will handle inbound calls by populating a call variable with data received from SIP headers, setting a label, then sending calls to Mindful Callback for an offer. If an inbound call cannot be successfully sent to Mindful Callback, the script will queue the call at normal priority.

Use the following steps to configure the first ICM script.
flow diagram

Begin with a Set Variable block that sets the SIPHeader call variable to include all of the SIP headers that will be added to the SIP signaling when sending the call to Mindful Callback. The SIP headers captured here must match what is configured in the CVP Call Server configuration and the Metadata items configured in Mindful Callback.

example configuration

example configuration

Example

Use the following format when adding SIP headers in the Set Variable block:

"<SIP header name 1>~add~<SIP header value 1>|<SIP header name 2>~add~<SIP header value 2>"

In the following example, we set X-cisco-acc-num to 123456, X-cisco-first-name to Jane, and X-cisco-last-name to Doe.Text

"X-cisco-acc-num~add~123456|X-cisco-first-name~add~Jane|X-cisco-last-name~add~Doe"

Create a Label block next, using the following image as a guide.

example configuration

example configuration

  • 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.
Note:

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 instead drop calls if errors occur.

When Enable target requery

  • 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.
2. Callback ICM script The second ICM script handles callbacks received from the Mindful Callback application. This script extracts any attached user data, sets a Finesse layout to display the newly populated ECC variables, then queues calls to a skill at high priority.

Use the following steps to configure the callback ICM script.

flow diagram

Begin with a Set Variable block to extract the final piece of user data included in the SIP headers received from Mindful Callback. The account_number variable was listed last in our example configuration, but that may differ in your environment.

example configuration

example configuration

In this example, the value of the X-cisco-acc-num user data is assigned to the user.acc_num ECC variable. This is the last piece of user data attached to the SIP header in our example integration, because it was the last Metadata item added in the Mindful Callback UI earlier in this guide. Because it is the last piece of data, the value returned does not require additional string content. Next, include additional Set Variable blocks to extract all additional user data passed via SIP headers. In our example configuration, we have two more variables to parse: first_name and last_name. Note that this includes all data except the final piece, which we have already handled.

example configuration

example configuration

example configuration

Two Set Variable blocks are needed to extract each variable. The first block will begin by returning everything in the SIPHeader variable after the variable string (For example, the string X-cisco-first-name). Since this is not the final variable in the string, you will need to trim the excess characters with a second Set Variable block.

Set the Finesse layout that will display each user data item, then queue the call to an agent skill at a higher priority than normal inbound calls.

Alternative: Use CUCM to send calls to Mindful Callback via a third-party SIP proxy

If you do not wish to use a Cisco Sip Proxy as we did in our example, but you wish to use a third-party SIP proxy instead, then certain changes must be made to the default configuration presented in this guide. These alternative steps require the use of CUCM to send calls via a third-party SIP proxy.

In the following sections, you will find some items that need to be modified from the previous steps, and others that are unique to this approach.

SBC trunk

Earlier in this guide we configured an SBC trunk to the Cisco SIP proxy. For the CUCM alternative, you must configure the SBC trunk to point to the CUCM SIP IP address and port, instead.

Dialed Number Pattern

There are changes that must be made to the Dialed Number Pattern, as well. Use the following image as a guide when setting up the Dialed Number Pattern.

route settings

  • Routing Pattern: Configure the pattern to catch 12-digit numbers beginning with 91.
  • Destination: Enter the FQDN of the CUCM instance.

CUCM SIP Normalization Script

By default, CUCM will remove all custom SIP headers, including those we created in the ICM scripts. To prevent this, create a Normalization script that allows a custom SIP header to be passed.

Quick access: Device > Device Settings > SIP Normalization Script

example configuration

The body of the script should look like the following example when complete. The script checks for any SIP headers named User-to-User then adds the value to the outgoing SIP message.

M = {}

M.allowHeaders = {"User-to-User"}

function M.inbound_INVITE(msg)

local ntcorrid = msg:getHeader("User-to-User")
if ntcorrid
then
pt = msg:getPassThrough()
pt:addHeader("User-to-User", ntcorrid)
end

end
return M
Important:

We have only validated this SIP Normalization Script to allow a single SIP header. This may be a limitation of the alternative CUCM approach, unlike the CVP approach which sends calls directly to a SIP device capable of processing multiple headers.

CUCM SIP trunk to the SBC

Configure a SIP trunk in CUCM which points to your SBC. In our example integration, we used an Avaya SBCE.

Quick access: Device > Trunk

trunk configuration
  • Destination Address and Destination Port: Use the IP address and port of your SBC's internal interface.
  • Normalization Script: Select the Normalization Script created in the previous step.

CUCM Route Pattern

Create a Route Pattern to take the number passed from CVP, which should be 12 digits in length and begin with 91, and send the call to your SBC.

Cisco ICM Scripts

When using CUCM as an alternative method, the ICM scripts will look mostly the same as with the basic Cisco SIP proxy method. However, a few changes are needed to account for the fact that only a single SIP header can be passed when using CUCM.

1. Inbound script

The following image shows the Set Variable block including the single User-to-User SIP header:
set properties block

Example

If you need to pass multiple pieces of user data to Mindful Callback, you can do so by adding a single value containing a pipe-delimited string. The following example shows how this could be done to pass an account number, first name, and last name:
User-to-User~add~accnum:123456|firstname:jane|lastname:doe
In this case, the entire string would be captured by Mindful Callback and passed back to your Cisco environment with the callback. You could then parse out the individual pieces of user data the same way described in the basic inbound ICM script earlier in this guide.

2. Callback script

The callback ICM script is nearly identical to the default configuration as well, with the exception that only a single SIP header will be received. In this case, the Set Variable block will simply parse everything after User-to-User in the data received.
set properties block

Quick access: Call Routing > Route/Hunt > Route Pattern

example configuration

In our example configuration, we have specified the ASBCE device as the Gateway/Route List.In our example integration, we used the built-in Called Party Transformation named PreDot. We also used this Called Party Transformation to prefix a plus symbol (+) to the number. Prefixing the plus symbol (+) in this way is an alternative to using an SBC Header Manipulation Rule when using CUCM.

Earlier in this guide, we configured the CVP Call Server to make SIP headers available to your ICM scripts, and we defined three headers to pass to ICM. This configuration will look different when using the CUCM alternative method. When using CUCM, you will need to define a single SIP header (User-to-User) which will contain all user data in a combined string.

sip header passing

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.

Examples

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
  • 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.
  • When the time comes, Callback delivers the return call (a callback in this case) with the destination number still attached.
  • 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.
  • The appropriate priority is set, and the call is delivered to an agent.

(Optional) Offer 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
  • 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.
  • If the initial offer is not accepted, callers are routed to a holding queue.
  • A timer begins in the holding queue. When the specified time expires, another callback offer is made.
  • If the customer declines the Second Chance offer, then the timer is reset, and another offer will be made when it expires again.
  • 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:

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

phone number assignment

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

Reporting:

  • 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.
  • 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.