Components and architecture

Review the definitions of acronyms and terms used throughout this guide before getting started. You can also view a high-level overview of the components and architecture of the integration below.

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

• Callback Telephony Type: Select PSTN.
• 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).

Phone Numbers

Quick access: Configuration > Phone Numbers

On the Phone Numbers page, provision as many PSTN numbers as needed and assign a number to each Call Target in your Organization. This is the number to which you will 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

• On the Data Set Templates page, 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.

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

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

Step 2: Configure your Amazon Connect environment

The configuration process required to integrate Amazon Connect with Mindful Callback can be separated into three tasks:

• Configure Lambda functions and permissions
• Configure Contact Flows
• Configure phone numbers

Along the way, we will configure Amazon Connect to send and retrieve call data from the Mindful Datastore application to maintain context and allow for intelligent call routing.

Configure Lambda functions and permissions

In order to leverage AWS Lambda functionality in your Amazon Connect instance, you must first set the appropriate permissions in your Connect account.

Use the image and steps below to set the necessary permissions.

Quick access: AWS Console > Your Connect instance > Contact flows

• Navigate to the Contact Flows submenu
• Use the Function dropdown menu to add the Call-VHT-Datastore-API and connect-time-convert-phrase functions, or click Add Lambda Function to create them now.

Configure Contact Flows

Contact flows contain routing logic and other operations to manage calls entering and leaving the Amazon Connect platform. In our example configuration we used three separate Contact Flows to handle normal inbound calls, inbound calls intended for Mindful Callback, and callbacks coming from Mindful Callback into Amazon Connect.

View the sections below to learn about the required Contact Flows.

1. BasicQueue – Inbound

The first Contact Flow handles inbound calls. This flow can either pass calls onward to receive Amazon Connect's native callback treatment or send calls to Mindful Callback for a callback offer. The following image shows how this flow is configured in our example integration.

• Set Voice: Sets the voice to be used
• Get queue metrics: Obtains the queue from which metrics will be pulled for the life of the call
• Set contact attributes: Stores the customer's phone number to the ANI variable
• Get customer input: Simulates a main menu with conditional branching
• Pressed 1: Sends the call to a Transfer to Flow block that passes the call to a Contact Flow offering Amazon Connect's native callback feature
• Pressed 2: Sends the call to a Transfer to Flow block that sends the call to the BasicQueue Inbound - VHT CBC Contact Flow for treatment by Mindful Callback

2. BasicQueue Inbound – VHT CBC

The second Contact Flow provides options to send KVPs to the Mindful Datastore application while sending calls to the Mindful Callback application, or to simply send calls to a holding queue.

When Amazon Connect receives a callback via the PSTN, it can use the customer phone number to retrieve the KVPs from Mindful Datastore and re-attach the data to the call.

• Set Voice: Sets the voice to be used
• Get queue metrics: Obtains the queue from which metrics will be pulled for the life of the call
• Invoke AWS Lambda function: Invokes the connect-time-convert-phrasefunction.
  • The connect-time-convert-phrase function parses the OCW variable ("OCW":"<Integer>") into a phrase that can be spoken via the text-to-speech engine.
  • It then passes the full KVP back with the full phrase set as the value. For example, "OCW":"Less than one minute".

Example

All KVPs returned from a Lambda function are stored as External Variables and can be referenced as $External.variable_name. The following example shows a TTS string invoking the OCW variable with $.External.OCW.

You have reached the billing department. The current hold time is $.External.OCW. To receive a callback, press 1. To remain on hold, press 2.

• Get customer input: Announces the wait time by calling the OCW variable, then presents customers with the choice to request a callback or wait on hold.
  • Pressed 1: Invokes the Call-VHT-Datastore-API Lambda function to pass all KVPs to the Mindful Datastore application. The function will either send a POST request to push data to Mindful Datastore or a GET request to retrieve data. The method used depends on the parameters passed to the Lambda function.
  • Pressed 2: Transfers the call to a holding queue

Example

The following example shows a complete KVP list provided to the Call-Mindful-Datastore-API Lambda function. The value of the method variable indicates that this example will use the POST method to send data to Mindful Datastore.

"contact_id": "(System attribute - Contact id)","customer_contact_number": "(System attribute - Customer callback number)","last_name": "John","first_name": "Smith","queue_name": "(Queue Metrics - Queue ARN)","token": "sadjf;l+eyg=","method": "POST"

Note that the contact_id and customer_contact_number variables are provided by the native API call from Amazon Connect to Lambda. However, you can define them on your own if you do not wish to use the values provided.

• Transfer to phone number: Sends the call to the Call Target phone number. Calls sent here will be able to register a callback with the Mindful Callback application.

3. BasicQueue – VHT CBC Return

This Contact Flow is used for callbacks sent from Mindful Callback to Amazon Connect. The Call Target will send callbacks to the Call Center Phone Number configured in the Callback application. That number should be provisioned in Amazon Connect and pointed at the BasicQueue - VHT CBC Return flow.

• Change routing priority / age: Elevates the priority level of the call
• Invoke AWS Lambda Function: Uses the Call-VHT-Datastore-API Lambda function to retrieve call data.
• Set working queue: Sets the working queue via the queue_name variable returned in the previous step.
• Transfer to queue: Transfers the call to queue with its newly elevated priority and External Attributes

Example

The following example shows the KVP list configured in the Call-VHT-Datastore-API Lambda function and a response from Mindful Datastore.

KVP list

"customer_contact_number": "(System attribute - Customer callback number)","token": "sadjfhasfhasfhasdfhsakjdfkljafkhkasdjf;l+eyg=","method": "GET"

Example Response

{  "customer_contact_number": "13209071234",  "interaction_id": "68a7ff09-c2ca-49d7-9e66-63a2a92049ba",  "ani": "13209071234",  "contact_id": "68a7ff09-c2ca-49d7-9e66-63a2a92049ba",  "last_name": "Smith",  "first_name": "John",  "queue_name": "arn:aws:connect:us-east-1:XXXXXXXXXX:instance/XXXXXX-bf14-4b7f-b4d9-XXXXXXXXXX/queue/XXXXXXXX-592b-4162-887c-XXXXXXXXXX",}

Provision phone numbers in Amazon Connect

In our example configuration, we provisioned two phone numbers:

• One pointed at the BasicQueue - Inbound Contact Flow for calls coming into the Amazon Connect environment
• One pointed at the BasicQueue - VHT CBC Return Contact Flow flow for calls coming back to Amazon Connect from the Mindful Callback application.

(Optional) Consolidate 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.

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:

• 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

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

• 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 that you can add logic into the routing script to limit the total number of offers made per call.

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.

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

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

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.

(Optional) Automate agent answer confirmation

Under normal circumstances, agents are required to press 1 or speak a key phrase to accept a callback from Mindful. However, it is possible to automate this task to avoid waiting for agent input.

To automate agent answer confirmation, you can first create a Customer Whisper Flow in Amazon Connect that contains a DTMF tone. Then, invoke the Customer Whisper Flow at the point in the Callback Return Contact Flow at which Mindful Callback expects the agent to press 1.

Step 1: Create a DTMF prompt

Create a new prompt containing a WAV file that plays a DTMF digit 1. Click here to download a WAV file containing one second of DTMF digit 1.

Quick access: Routing > Prompts > Create new prompt

Step 2: Create a Customer Whisper Flow

Quick access: Routing > Contact Flows > Create customer whisper flow

Create a new Customer Whisper Flow with a single Play Prompt step to play the DTMF prompt, then connect that step to an End Flow / Resume step.

Step 3: Modify the callback return Contact Flow

Within the callback return Contact Flow, before the existing Transfer to Queue step, add a Set Whisper Flow step. Use this step to invoke the Customer Whisper Flow that plays the DTMF digit 1.

With all of this in place, Amazon Connect will automatically send the expected DTMF pulse to Mindful Callback at the beginning of a callback interaction, and Callback will interpret it as agent input to accept the call. When an agent answers the call, the customer should already be connected.