Genesys Pure Engage and Mindful (With Datastore) integration guide

The Mindful Callback integration with the Genesys Pure Engage platform utilizes reliable SIP-based communication without the need for custom development. The example integration presented in this guide allows the Genesys platform to send inbound calls to the Mindful Callback application for a callback offer, while maintaining user data and context for each call.

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 by a single Genesys Queueing Strategy
  • Establishing an offer threshold in Genesys Pure Engage based on the wait time
  • Providing a callback offer in the Mindful Callback application.
  • Retaining user data between Callback and Genesys
Note:
  • For further validation against additional integration options, please contact a VHT representative.

  • This article is not intended as a configuration guide for a Genesys Pure Engage environment. For help with Pure Engage deployments and configuration, consult the official Genesys documentation.

  • This guide covers the on-premise Genesys Pure Engage platform. For information about integrating with the Genesys Pure Cloud platform, see the Genesys Cloud and Mindful Callback integration guide.

  • 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 sending calls to Mindful Callback.

Overview

This integration guide covers the following topics:

  • Components and architecture
  • Step 1: Configure your Mindful Datastore account
  • Step 2: Configure your Mindful Callback account
  • Step 3: Configure your SBC
  • Step 4: Configure your Genesys environment
  • Call flow diagram
  • Optional: Offer Second Chance Callback

Components and architecture

Definitions and acronyms

TermDefinition
DIDDirect Inward Dialing phone number
SBCSession Border Controller
SIP TrunkVirtual phone line that enables users or applications to make and receive calls
SIP URISIP addressing scheme that determines where to send SIP calls
UUIUser to User information about a call, passed in a SIP header

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
Pure Engage componentDescription
ORS/URSOrchestration Server / Universal Routing Server. We used URS 8.1.4x in our example integration.
Avaya SBCESession Border Controller for Enterprise. We used SBCE 8.0 in our example integration.
SIP ServerWe used SIP Server 8.1.1x in our example integration.
IRDInteraction Routing Designer is used to implement subroutines to handle call routing.

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

  • 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

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

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:


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.

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

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

d

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

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 Genesys environment

Several items will need to be configured or edited in your Genesys environment to complete the integration. The following steps and examples cover four additional tasks:

  • Create Trunk DNs
  • Configure a Routing Point
  • Set SIP Server Application Options
  • Configure Genesys routing

Create Trunk DNs

You will need to configure two Trunk DNs for this integration. Both DNs allow calls to pass through the SBC, with one DN allowing traffic to your telephony service provider and the other allowing traffic to the Mindful Callback application.

Quick access: Genesys Administrator > Switches > Your SIP Switch > DNs > Trunks

Open both of the following tabs for information on the two required Trunk DNs.

1. Normal Trunk DN to the SBC

Configure a normal Trunk DN for dialing out to your telephony service provider through the SBC. This Trunk DN will also be used to validate the SBC as an authorized device for incoming SIP requests.

Use the following image and table as a guide when configuring the TServer options for this Trunk.

example genesys configuration

TServer optionValue
contactEnter the IP address of the SBC's internal interface.
cpnEnter the ANI that will be provided as the From address in a SIP INVITE.
prefixCalls received by SIP Server with the configured prefix will use this Trunk.
refer-enabledSet to false (this is recommended when inviting an endpoint outside of the network).
Replace-prefixEnter 1. When SIP Server receives a request to dial an external number with a 91 prefix, it will send an INVITE to the SBC without the leading 9.
Note:

This trunk may already exist if your Genesys environment is configured to route inbound and outbound calls through your SBC.

2. Trunk DN to the SBC for Mindful Callback

Configure a second Trunk DN to allow calls to be dialed out through the SBC to the Mindful Callback application. The configuration of this Trunk DN is similar to the normal Trunk DN for your telephony service provider, with a few key differences.

Use the following image and table as a guide when configuring the TServer options for this Trunk.

example genesys configuration

TServer optionValue
contactEnter the IP address of the SBC's internal interface.
override-to-on-divertThis instructs SIP Server to replace the To: header of the inbound call (which will have the number of the routing point) with the number that needs to be invited (8088xxxxxxxxxx). In our example environment, this option and value were required to make the call flow work correctly.
cpnNote that the CPN is not included this time. This is to allow the caller's ANI to pass through to Mindful Callback.
prefixCalls received by SIP Server with the configured prefix will use this Trunk. Note that this Trunk is configured with a different prefix to differentiate it from the normal Trunk to the SBC. In our example integration, we used 8088 as the prefix.
refer-enabledSet to false (this is recommended when inviting an endpoint outside of the network).
Replace-prefixEnter +1. When SIP Server receives a request to dial an external number with a 91 prefix, it will send an INVITE to the SBC with a plus symbol (+) prefixed and without the leading 9. This also strips the 8088 prefix in our example integration.
userdata-map-filterThis parameter is not needed for the integration with Mindful Datastore.
Note:
  • The TServer/cpn option is not used for this Trunk. Not using cpn allows a caller's ANI to pass through the SBC to Mindful Callback.
  • The Genesys userdata specified in the userdata-map-filter option will vary based on your environment.

Configure a Routing Point

Configure a single Routing Point for the entry DN that callers use to enter the Genesys environment. This Routing Point DN will be used by the Mindful Callback application to send callbacks to your Call Center.

Set SIP Server application options

TServer/userdata-map-trans-prefix

The SIP Server Application Option TServer/userdata-map-trans-prefix is null by default. We recommend setting the value to X-Genesys-. This is required if you use GVP as an IVR, but is still a best practice in other cases. The value of this option must match the prefixes configured for the Metadata items in the Mindful Callback user interface in a prior step.

Configure Genesys routing

For routing in our example integration, we configured an inbound strategy, two return call strategies, and a single subroutine that can be invoked from all of them. The inbound strategy posts custom call data to a Mindful Datastore account before routing the call to Mindful Callback for treatment. The return call strategy handles both callbacks and callers who chose to return to the holding queue from the Callback IVR.

Inbound strategy

Use the following steps to configure the inbound strategy and the HTTP POST portion of the Callback subroutine.

inbound script example

  • Set the Mindful Callback transfer number. This should be the Call Target Phone Number provisioned in the Mindful Callback user interface.
  • Send the call to the Mindful Datastore subroutine along with any custom data you wish to store for the call.
    • Set the RequestType parameter to post in the Call subroutine properties window.
  • If the subroutine fails for any reason, or the system is unable to send the call to Mindful Callback, exit the subroutine and queue the call for an agent at normal priority.

Mindful Datastore subroutine - POST

A single subroutine will be used to POST or GET information to and from Data Set records in your Mindful Datastore account. When a call enters the subroutine with the RequestType parameter set to post, the POST portion of the subroutine will be used.

Use the following image and steps as a guide when creating the HTTP POST section of the subroutine.

example subroutine

  • Begin by setting a few default variables. In our example integration, we set two variables:
    • OriginalUUID: This can be retrieved for return calls to pair them with inbound calls in Genesys reporting, such as ICON.
    • vht_ANI: The ANI is required by the Datastore application, as it is used as the lookup key for stored records.

example genesys configuration

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.

  • Use the Cat function in an Assign properties block to combine all of the custom data into a single string. The example image below shows the Cat function creating a string with customer_contact_number as the key while concatenating all other data together as the value:

example genesys configuration

Important:

The custom data string must match the format of the string shown in the Data Set Template's sample HTTP POST. The sample post can be found in the Mindful Datastore UI by clicking the Data Set API icon on the Data Set Templates screen.

example data set template

  • Perform an HTTP POST to Mindful Datastore with a Web service properties block, using the following image and notes as a guide:
    • Web Service URL: Set to the URL of the Mindful Datastore API
    • Method name: POST
    • Headers: Add two headers:
      • authorization: Set the value to the API Token assigned to the Data Set Template in the Datastore application. In the Datastore UI, the API Token can be found on the Data Set Templates screen.
      • Content-Type: application/json

example genesys configuration

  • If the HTTP POST succeeds, route the call to Mindful Callback via the number passed into the subroutine.
    • Make sure this number contains the appropriate prefix (8088 in our example) to send the call out of the appropriate trunk.

example genesys configuration

  • If the HTTP POST fails, attach default user data for screen-pop or other purposes, then exit the subroutine.
Note:

This guide assumes that a callback should not be offered if user data cannot be passed to Datastore. If you would like to offer callbacks regardless of the outcome, you can set the line out of the red port of the Web Service block to connect to the TRoute block.

Return call strategies

The following table provides an overview of the Choose Hold and Callback Return strategies. The Choose Hold strategy will be used for calls returned from Mindful Callback after customers choose to return to hold from the Callback IVR, while the Callback Return strategy will be used for callbacks sent to the high-priority holding queue.

Choose Hold strategyCallback Return strategy
choose hold strategyreturn call strategy

Mindful Datastore subroutine - GET

A single subroutine will be used to POST or GET information to and from Data Set records in your Mindful Datastore account. When a call enters the subroutine with the RequestType parameter set to get, the GET portion of the subroutine will be used.

The GET portion of the subroutine will accomplish several tasks:

  • Perform a lookup in the Datastore records based on the customer's ANI.
  • Retrieve data stored in the appropriate Datastore record.
  • Parse the results from the JSON string received in the response from Datastore into individual variables.
  • Attach necessary data to the return call for agent screen-pop or lookups in the queueing strategy.

Use the following image and steps as a guide when creating the HTTP GET section of the subroutine.

example subroutine

  • Begin with a Call subroutine properties block that sets the RequestType parameter to get.

example genesys configuration

  • Concatenate the customer's callback number to use as the ANI in the Datastore GET URL.

example genesys configuration

  • Perform an HTTP GET to Mindful Datastore with a Web service properties block, using the following images and notes as a guide:
    • Web Service URL: Set to the URL of the Mindful Datastore API, containing the customer ANI from the previous step.
    • Method name: GET
    • Headers: Add two headers:
      • authorization: Set the value to the API Token assigned to the Data Set Template in the Datastore application. In the Datastore UI, the API Token can be found on the Data Set Templates screen.
      • Content-Type: application/json
    • Result tab > Assign output value to variable: Select the variable that should contain the returned data values. In our example, this variable is named vht_DataValues.
example genesys configurationexample genesys configuration
  • Use a Multi Assign properties block to parse the returned values into individual variables. In our example integration, we use the KVListGetStringValue function to parse the JSON values.

example genesys configuration

  • Attach KVPs to the call via a Multi Attach properties block for use in agent screen-pop.

example genesys configuration

  • Set the call priority to the value of the callback priority passed in.
  • Exit the subroutine back into the Callback Queueing strategy to be queued for the appropriate agents.

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 example uses 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: 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.

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.

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

example call targets

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.

example call target

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 screens, 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 screen, 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.

example phone numbers

  • 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 screen, 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 screens will combine Second Chance interactions with initial offers and callers that chose to hold.