Integrate with Mindful Feedback for surveys

The Mindful Feedback integration with Genesys Cloud includes several ways to deliver surveys to customers, including via SIP call transfers by agents and automatic embedding into Genesys Cloud web chat windows.

In this guide, we will focus solely on creating a button in an agent script to allow agents to transfer customers to a voice survey after an interaction. For more information on other integration points, see the Mindful Feedback documentation.

Before you begin

To transfer callers to Mindful Feedback via SIP, you will need to configure several items in Genesys Cloud:

• A SIP Trunk to Mindful Feedback

• An outbound call route that uses the configured SIP trunk

• A phone number configured in the dial plan to use the outbound route

In addition to the items listed above, you will need to create:

• A Secure Call Flow in Genesys Architect to set UUI data and transfer calls to Mindful Feedback

• An Agent Script to provide a button for agents to transfer calls to the Secure Call Flow

Use the steps in below to complete the required configuration.

Acquire a SIP Survey Token

To configure the Secure Call Flow, you will need the SIP Survey Token for the survey you wish to play after transferring a call to Mindful Feedback. You can find this token in the Mindful Feedback user interface at Surveys > Your survey > Advanced tab:

Configure a Secure Call Flow

Create a new Secure Call Flow to accomplish two tasks:

1. Set UUI data on the call before transferring (blind) to Mindful Feedback.

2. Transfer the call to Mindful Feedback with the UUI data attached.

Use the following steps to create the Secure Call Flow:

Set UUI Data block

1. In Genesys Cloud Architect, add a new Secure Call Flow.

2. Within the new call flow, add a Set UUI Data for Transfer block and configure it with an expression in the following format:

   "SDX-survey_sip_token:<sipsurveytoken>;SDX-external_ref:" + Call.ConversationId + ";SDX-respondent_language:en-US"

UUI parameters

Mindful Feedback expects the UUI Data string to contain attributes with a prefix of SDX-, which it will parse when the call arrives. The required and optional attributes are explained in the following table:

Example

The following example shows a complete expression with SDX-survey_sip_token, SDX-external_ref, and SDX-respondent_language parameters:

Transfer to Number block

After the Set UUI Data block, add a Transfer to Number block to transfer the caller to the SDX SIP endpoint via the configured number. The example call-flow screenshot above shows 10000 as the SIP endpoint.

Before the transfer can take place, you must have the following items configured in Genesys Cloud:

• A SIP Trunk to Mindful Feedback

• An outbound call route that uses the configured SIP trunk

• A phone number configured in the dial plan to use the outbound route

Configure an agent script

Create a new agent script, or edit an existing script, to enable agents to transfer callers to the survey by clicking a button. In the script, add a button and set the button's action to "Invoke Secure Flow" with the following configuration:

• Secure Flow — Select the call flow configured in the earlier steps.

• Flow Data Field — You can select any field here. It is required but not used.

• Button > Text — Add a descriptive label for the button, such as "Transfer to Survey" or "End Call".

Enable the button for inbound or outbound calls as needed, then add it as a Screen Pop block in the appropriate Architect Flow just before transferring to an agent.

That's it for the SIP transfer from Genesys Cloud to Mindful! Your agents should now be able to click a button to transfer customers to SDX for survey treatment when a conversation ends.

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

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

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

One additional feature that the Genesys Cloud integration with Mindful Callback allows, is Second Chance Callback, which enables the Queue to offer the caller a call-back as part of the queuing treatment. This is done via use of an In-Queue Architect flow that can be assigned to a queue. Here are the steps to set up a sample Second Chance Callback flow and assign it to a queue.

Sample second chance callback Architect In-Queue Flow

This In-Queue Flow plays queuing treatment (e.g. music and/or announcements, and also periodically offers the caller the option to take a call-back, and loops until either:

• The call is answered by an agent

• The caller takes the call back option

• The caller abandons the call

• The maximum number of loops has elapsed, at which point the treatment loop ends, but the call continues queuing.

Second chance callback Architect In-Queue Flow steps

To create an In-Queue flow, open Architect from the Genesys Cloud CX admin console, and where the drop-down list shows Inbound Call, select In-Queue Call, under the Supporting Flows section, as shown here:

Click the Add button to add a new In-Queue Flow and create a new flow using these key steps:

Loop (treatment loop)

This block sets the number of times that the In-Queue treatment – including the Second Chance Callback offer, will play. The maximum number for the Loop count is 99, and once the loop has expired, the call will no longer loop back to the start, but will continue queuing until an agent answers, or the caller hangs up the call.

Hold treatment (music/waiting announcements)

Within the loop, normal queuing treatment music and/or announcements can be played – these should be set so that the total duration covers the time between each call-back offer. This example here shows music being played for five minutes.

Collect Input block (callback offer)

This Collect Input block is where the second-chance callback offer is made. The input audio should allow the caller to remain in the queue, or optionally take a callback (for example "Please remain on the line for the next available representative, or press 1 to receive a callback").

Set the Input Data Name to the name of a variable to record the response (e.g. callback_option) and then set the No Entry timeout (e.g. 3 seconds, and the number of digits (typically exactly 1 digit) and the block will play the offer prompt, then wait for a single DTMF press within the timeout period.

If the caller does not press anything within the timeout period, the call exits though the failure path and the treatment loop is restarted.

Decision block (check offer response)

If the caller responds to the above Second-chance callback offer, the DTMF digit pressed is checked against the preconfigured value in this decision block – the full expression in this example is:

Task.callback_option == "1"

If the input value matches the configured value in the expression (such as 1), then the call exits this block via the Yes path. Otherwise, it exits via the No path and the treatment loop is restarted.

Transfer to Number (Transfer to Mindful second chance Call Target)

Connected to the Yes path of the previous Decision block, this Transfer to Number block initiates a transfer to the SIP number provisioned against the second-chance Call Target. This will be another number in the same range as configured in the Mindful Callback Number Plan earlier in this guide.

If the transfer fails, the failure path from the Transfer to Number block should connect to an Exit Loop block to exit the loop so that the caller is not continually offered callbacks that cannot be registered.

Associate the In-Queue Flow with a queue

Once the In-Queue flow has been saved and published, it needs to be associated with the relevant queue.

In the Genesys Cloud CX admin console, on the Contact Center page, click Queues, and select the Voice tab:

In this tab, select the In-Queue Flow created previously, and then save the queue. The In-Queue flow will now be executed against new calls queuing arriving on this queue.