Definitions and acronyms

Architecture and call flow

Call flow diagram

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

Configure the Mindful platform

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

• A Data Set Template in Mindful Datastore (if you intend to use Datastore to store custom user data and context)

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

Registration

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

Voice > Call Targets > Your Call Target > General tab > Contact Center

• Callback Telephony Type — Select "SIP".
• Callback Number — This will be configured in a later step.

Callback Strategy

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

Phone Numbers

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.

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.

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

   

   • Name — Enter a name that will be recognizable to others in your organization.

   • Description — Enter a description for the benefit of other Administrators.

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

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

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

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

   • Click in the Manually Enter Data Keys field.

     • If your Mindful Datastore instance contains existing Data Keys, select one from the dropdown list that appears.

     • If not, type the name of a new Data Key here.

   • When finished, click Add.

   Your key will now appear in the Template Data Keys list.

Example

In our example integration, we set up the following Data Keys for callbacks:

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

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:

1. Open Call Targets > Your Call Target > General tab > Mindful Datastore Integration.

2. Select the Mindful Datastore Integration checkbox to reveal additional settings below.

3. In the Data Set Template field, select the Template that you created in a previous step.

Install CTI Event Relay on a Windows server

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 Mindful Datastore. 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.

For this step, see Datastore CTI Event Relay, then return to this guide to continue.

Configure your SBC

Mindful integrations can function with different Session Border Controllers (SBC) regardless of the ACD platform used in your environment.

See our SBC integration guides for instructions on integrating your chosen SBC.

Configure UCCE/PCCE

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

Configure the SIP proxy and SBC

The following 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.

Configure a new Dialed Number Pattern in CVP

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.

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......... (10 digits total)

• session target — Use the IP address of the SBC's internal signaling interface.

• dtmf-relay — rtp-nte

  This allows RFC2833 DTMF

• voice-class sip pass-thru headers — 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.

Configure ECC variables

You will need to define ECC variables to facilitate the request to the Mindful Agent Answer API that will be made in the callback-return ICM script in a later step.

At minimum, two ECC's or an ECC (API key) and a PV (ANI) will be needed for the Agent Answer API. The first is for the API key needed for authentication, and the second strips the plus (+) from the the Calling.LineID variable in routing.

Create a new Agent Team List

In order to not affect agents that will not be servicing callbacks, create a new Agent Team List in Configuration Manager to apply workflow logic.

In the "Agent Team List" section of Configuration Manager (Tools > List Tools > Agent Team List), create a new team and add the members or teams that will be able to take Mindful callbacks. This configuration will be used in Finesse Administrator later in this guide.

Create ICM scripts

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

Inbound ICM script

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

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.

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 Mindful Datastore.

You can ignore the Receive tab for now.

Label node

Place the Label node at the point where you are ready to send calls to Mindful for treatment, going from CVP, through the SBC, to Mindful.

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

  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.

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

Callback ICM script

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

1. Set Variable for Datastore

2. Set Variable for the Agent Answer API

3. Gateway

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

Set Variable node for Datastore

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-return ICM script, the phone number will have been populated by Mindful before returning the call.

Set Variable nodes for the Agent Answer API

You will need two more Set Variable nodes to facilitate the request to the Agent Answer API. The first will be to assign your API key to the ECC variable created earlier:

• Variable — Select "user.api_key".

• Value — Enter the Base64 combination of Client ID and Secret from a Mindful Application Client.

The second Set Variable node will strip the plus (+) from the E.164 number:

• Variable — Select "user.contactnumber".

• Value — Enter "right(Call.CallingLineID,10)".

Gateway node

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

Check wait time and offer a callback

This example integration makes callback offers in the Cisco environment before transferring callers to Mindful to register a callback. To do this, we recommend using a three-step process:

1. Check the wait time of the targeted queue to ensure it is higher than a defined threshold (for example, two minutes)

2. If the wait time exceeds the threshold, offer the caller the option to receive a callback rather than waiting on hold.

3. If the caller accepts the offer, continue to send the call to Mindful.

4. If the caller declines the offer, send the caller to the queue as usual.

Configure Finesse for the Agent Answer API

There are three categories that require configuration in the Finesse Administrator UI for the Mindful Agent Answer API:

• Actions
• Workflows
• Team Resources

Actions

The Action will contain the bulk of the configuration.

• Type — Select "Browser Pop".

• Handled by — Select "Finesse Desktop".

• Browser URL — Enter the URL of the Agent Answer endpoint:

  https://api.getmindful.com/v2/callback/agentAnswer?apiKey=user.api_key&ani=user.contactnumber

  Click the icon on the right side of the Browser URL field to add the user.api_key and user.contactnumber variables to the associated query string parameters, as seen in the example image above.

  

  You can do the same for any additional query string parameters containing user data:

  

Test the API request before saving:

The expected result is a 404 error, since there will be no call in Mindful to receive the Agent Answer request. This will validate that the Authentication Key is correct. If a 401 is received, that would indicate an invalid API key.

Save the action when finished:

Workflow

After building and testing the action in the previous step, a Workflow needs to be created.

Select “When a Call is answered” in the When to Perform Actions dropdown menu.

Click Add in the Ordered List of Actions section, then select the action created in the previous step.

Team Resources

Lastly, assign the newly created Mindful Workflow to the Workflows tab of any teams that may service callbacks:

Consolidate return-call destinations

The main integration guide assumes 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 across multiple queuing 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 ultimately 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 with inbound calls to identify their ultimate return destinations. This can be done in two ways:

• Send the destination to Mindful via SIP Headers. This requires that you configure additional Metadata Items for each affected Call Target. Or...

• Post the destination to Mindful Datastore using the customer's ANI as the key. This method can be used even when calls are delivered via the PSTN rather than SIP.

In either case, Mindful 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.

Example

Consider the following example. Let's say you have the same agent skill assigned to different queuing 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:

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 Mindful for treatment.

2. When the time comes, Mindful 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.

Offer second chance callbacks

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 later 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, 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.

1. Whether offers are made in your ACD or Mindful, 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 for treatment.

Note that you can add logic into the routing script to limit the total number of offers made per call.

Mindful configuration

There are two alternatives for preparing your Mindful organization 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.

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 Offer Choose Hold Call Target setting disabled (offering a hold option in Mindful 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 Offer Choose 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

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.

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.

Reporting with separate Call Targets

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.

On the Callback Overview, 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 user interface, and assign both phone numbers to the same Call Target.

   

2. In your routing scripts, send normal inbound calls for callback treatment to the first phone number.

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

When using a single Call Target, the Callback Status, Callback Overview, and Executive Summary pages will combine second chance interactions with initial offers and callers that chose to hold.