Definitions and acronyms

Inbound Call Flow

• A customer places a call into the NICE contact center.
• The DNIS is matched to the Campaign associated with the inbound sub script.
• After checking the Mindful Callback status, EWT, and the caller's preference for the callback option, the inbound sub script optionally posts the required user data to the Mindful Datastore.
• The call is transferred back out to the SIP number provisioned for the relevant Mindful Call Target via the TLS SIP trunk between NICE and Mindful Callback, with optional custom SIP headers. Note that if any of the following conditions occur, the call will queue to the agent skill at normal priority instead of being transferred to Mindful:
  • The Mindful Callback availability check fails.
  • The EWT is below the configured threshold.
  • The caller declines the callback option.
  • There is an error in the sub script.

Return-call (Callback) Call Flow

• Mindful calls the customer phone number. The customer answers and presses DTMF 1 to confirm their desire to speak to an agent.
• Mindful calls the contact center number for callbacks via the TLS trunk between Mindful Callback and NICE CXOne.
• The DNIS of the agent leg is matched to the Campaign associated with the callback sub script.
• The callback sub script optionally retrieves custom SIP headers and/or gets the user data from the Mindful Datastore using a query Action, with the caller's ANI passed in as the search key.
• The call queues to the agent skill at a higher priority than inbound calls.

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

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.

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

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.

NICE CXOne Configuration

In this section, you will learn how to customize your NICE environment to leverage the power of the Mindful integration. The following key areas will be covered:

• Create an inbound sub script in NICE Studio: By making the necessary modifications, you can seamlessly incorporate callback options for callers who may decline the initial offer.
• Modify the inbound queue script: The inbound queueing script will need to incorporate the sub script.
• Create the return-call sub script: This script enables efficient handling of callback requests, ensuring smooth transitions between the inbound and callback stages.

This step includes a ZeroQueued exit branch, which is taken when there are no calls currently queuing for the specified skill. In such cases, the call should not proceed with further Mindful Callback logic. Instead, it should proceed to the Return action to exit the sub script and return to the queuing script for the appropriate skill.

Modify the Inbound Sub Script

In NICE CXOne, A sub script is used to create reusable components or functions within a main script. It allows you to define a set of actions or operations that can be called and executed from multiple places within the main script. The inbound sub script used to process inbound calls and queue them to an agent/skill group will need a few modifications. You'll need to add functionality for the following steps:

• Fetch the EWT and turn it into a phrase to play back to callers
• Check the EWT to make sure it is above a defined threshold before offering a callback
• Check Mindful Callback status to ensure it is available and ready to process requests
• Play the EWT phrase and offer a callback
• (Optional) Post data to the Mindful Datastore
• Transfer to Mindful Callback with optional SIP headers

Inbound sub script parameters

This sub script utilizes variables passed in from the inbound queueing script. When variables are passed in using the Runsub action, you can access them within the sub script using the new variable names {p[n]}, where [n] represents the parameter number. It's important to note that the parameter numbers in the sub script are slightly different from the numbering used in the Runsub action.

For example, let's consider the Runsub action described later in the inbound queueing script Actions section, which invokes the Mindful Callback Inbound sub script:

In this example, the first parameter [0] contains the value of the {firstName} variable. However, when using it inside the sub script, you can retrieve the value using the variable name {p1} (because it's the first in the list). Similarly, parameter [1] in the Runsub action becomes {p2} inside the sub-script, and so on. Keep this in mind as you follow this guide and refer to these parameters in this section.

get Wait Time (Getqueue Action)

The Getqueue action in this script performs a lookup against the skill ID passed as parameter [3], represented here as variable {p4}. The metric used in this case is LongestWait, which refers to the longest waiting call. To capture this value, set a variable named waitTime alongside LongestWait. It's important to set the Scope to Ahead, which ensures that only the longest wait for calls ahead of the current call is returned.

This step includes a ZeroQueued exit branch, which is taken when there are no calls currently queuing for the specified skill. In such cases, the call should not proceed with further Mindful Callback logic. Instead, it should proceed to the Return action to exit the sub script and return to the queuing script for the appropriate skill.

Wait Time > 2 Mins? (If Action)

The If action in this script compares the value of waitTime, obtained from the previous Getqueue action, with a configured threshold. If the value of waitTime is below this threshold, it indicates that the call should not proceed with any further Mindful Callback logic. Instead, it should go to the Return action to exit the sub script and return to the queuing script for the appropriate skill.

On the other hand, if waitTime exceeds the configured threshold, the call will continue along the Mindful Callback path within the sub script.

This mechanism is designed to prevent callers from being sent to Mindful Callback when the wait time is low enough that they would spend more time registering and waiting for a callback than they would have waited in the skill queue to speak with an agent. In this example, a two-minute threshold is provided, but you can use a higher threshold if you prefer.

set Wait Phrase (Snippet Action)

The Snippet action in this script is used to define the wait time phrase that will be played back to the caller, setting their expectations before offering them the opportunity to opt for a callback.

To set the name of the action, simply right-click the action and enter the desired Caption value. Once that's done, double-click the Snippet action to define the snippet code.

See below for the complete code:

//Determines wait time prompt or phrase to play to caller
IF waitTime > 3600
{
  ASSIGN waitTimePhrase="Current wait time may be more than 1 hour"
}
ELSE
{
  //If wait time is greater than 1800 seconds, set over 30 mins phrase
  IF waitTime > 1800
  {
    ASSIGN waitTimePhrase="Current wait time may be more than 30 minutes"
  }
  ELSE
  {
    //If wait time is greater than 1200 seconds, set over 20 mins phrase
    IF waitTime > 1200
    {
      ASSIGN waitTimePhrase="Current wait time may be more than 20 minutes"
    }
    ELSE
    {
      //If wait time is greater than 900 seconds, set over 15 mins phrase
      IF waitTime > 900
      {
        ASSIGN waitTimePhrase="Current wait time may be more than 15 minutes"
      }
      ELSE
      {
        //If wait time is greater than 600 seconds, set over 10 mins phrase
        IF waitTime > 600
        {
          ASSIGN waitTimePhrase="Current wait time may be more than 10 minutes"
        }
        ELSE
        {
          //If wait time is greater than 300 seconds, set over 5 mins phrase
          IF waitTime > 300
          {
            ASSIGN waitTimePhrase="Current wait time may be more than 5 minutes"
          }
          ELSE
          {
            //If wait time is greater than 120 seconds, set over 2 mins phrase
            IF waitTime > 120
            {
              ASSIGN waitTimePhrase="Current wait time may be more than 2 minutes"
            }
            ELSE
            {
              //If wait time is under 2 minutes, set the minimum wait time phrase
              ASSIGN waitTimePhrase="Current wait time is less than 2 minutes"
            }
          }
        }
      }
    }
  }

In the example above, the code sets the wait time phrase to be used as text-to-speech (TTS) in the sample sub script. However, recorded prompts can also be used by assigning a prompt variable instead of using the waitTimePhrase variable. For instance, instead of:

ASSIGN waitTimePhrase="Current wait time may be more than 30 minutes"

you can use something like this:

ASSIGN waitTimePrompt="MoreThan30Mins.wav"

Feel free to customize the code snippet based on your specific requirements and preferences.

get Mindful Status (Rest API Action)

This REST API Action performs an HTTPS GET against the Mindful Scheduler API. To do this, use a Mindful Scheduler widget created for the relevant Mindful Call Target. Mindful will return a set of parameters, including widget_status, which indicates whether the Call Target is ready to register callbacks or not.

To configure this Action, provide the following information:

• Caption: Set the name of the action.
• Widget URL: Pass the widget URL into the sub script as parameter [5], which becomes variable {p6}.
• Verb: Set the verb to GET for the secure HTTP GET method.
• Result Set: Store the results from the Mindful Scheduler API in a variable (named something like mindfulStatus).

set Widget State (Assign Action)

The Assign action is parses the value of widget_state from the result set obtained in the previous Rest API action. Follow these steps to configure the action:

• Caption: Provide a name for the action, such as Set Widget State.
• Variable name: Assign a variable name to store the widget_state value. In our example, we use widgetState.
• Value: Enter the value as {mindfulStatus.widget_state}. This references the variable assigned to the result set in the previous Rest API Action (mindfulStatus) and specifies the value to parse (widget_state).

check Mindful Status (Case Action)

The Case action checks the value of the previously assigned widgetState variable and determines the next course of action in the Mindful Callback flow. Follow these steps to configure the action:

• Variable: Set the variable to the name of the widget state variable assigned in the previous Assign action. For example, widgetState.
• Default branch: Set the default branch to the Return action. This action returns the call back to the inbound Queueing script if there is no match.
• Custom cases: To add custom cases, click the Custom Cases (Branches)line, then click the ellipsis (...) on the right.
  • Click Add and set the condition to offer_callback.
  • The destination for this case will be set once the next action in the Mindful Callback flow, the Offer Callback (Menu) action, is created.
• Create a second Case with the same destination, but this time with the condition offer_asap_callback.
  • If either case returns True, we want to offer a callback.
• Click OK to complete the configuration of the Case action.

offer Callback (Menu Action)

Now that the script has determined that the wait time is above the configured threshold and the Mindful Call Target is capable of registering callbacks, it's time to offer a callback via a Menu action.

To configure the Menu action, follow these steps:

• Max digits: Set the maximum digits to 1.
  • This allows callers to input a single digit as their response.
• Timeout: Set a timeout that gives callers enough time to respond to the callback offer.
  • In this example, the timeout is set to three seconds.
• Default result branch: Set the default result branch to exit the sub script and return to the inbound Queueing script using the Return action. If you're using Second Chance Callback (covered later in this guide), we recommend setting a disposition before returning to the inbound Queueing script.
  • For example, you could create an Assign action called Offer Not Accepted and direct the default branch there.
• Custom case: Click the Custom Cases line, then click the ellipsis (...) on the right.

To add a custom case for the DTMF option presented to the caller, follow these steps:

• Click Add to create a new case.
• Set the Condition to match the DTMF digit for the callback option. For example, if the digit is 1, set the condition to 1.
• Set the destination to the next action in the Mindful Callback flow. This could be an action to set a custom SIP header, post to the Mindful Datastore, or simply transfer to Mindful Callback, depending on your requirements.
• Click OK to add the new custom case, then close the configuration page for the Menu action.

Double-click the Menu action to set the prompts that will be played to the caller:

In the example above, TTS is used for the prompts. However, if you're using recorded prompts instead, you would set the menu prompts accordingly. You can use the waitTimePrompt variable as an example, which was created in an earlier step.

For the TTS example used here, the waitTimePhrase variable is played first, followed by the text of the callback offer. The caller is prompted to press 1 to accept the callback offer or press 2 to continue waiting for an agent.

set Routing Token SIP Hdr (SIPXFERPUTHD Action)

Use the SIPXFERPUTHD action to set custom SIP headers to pass to Mindful and pass back to NICE CXone on the callback. This action is designed to allow custom SIP headers to be set prior to a transfer, and should be used instead of SIPPUTHEADER, which may not work in this call flow. Unlike the actions we've seen so far, this action is not found in the Tools tab in Studio, but rather in Framework > Voice > SIP.

A routing token SIP header is required to validate and route SIP requests received by the Mindful Callback SIP router. The routing token for your integration will be provided by the Mindful Solution Delivery team.

To configure this action, specify a name for the action as the Caption parameter (such as Set Token SIP Hdr), then set the name of the SIP header as the headerName parameter. Note that the SIP header should start with X- prefix for transfers to Mindful Callback. In this example, the SIP header X-Mindful-Routing-Token is being set, and the headerValue is the routing token provided by the Mindful Solution Delivery team.

You can set multiple SIP headers, using a separate SIPXFERPUTHD action for each. If you send custom SIP headers other than the Mindful Routing Token to Mindful Callback, you'll need to configure SIP Header Metadata Items for each relevant Mindful Call Target.

(Optional) set DS Vars (Snippet Action)

This optional Snippet action is only required if using the Mindful Datastore to pass data between the inbound call and the callback. The Mindful Datastore can be used instead of SIP headers for this functionality and may be a better solution if a large number of data values need to be passed, or if the integration cannot use a SIP trunk to Mindful Callback.

This action sets the body of the HTTPS POST to Mindful Datastore and formats the data into a JSON string that Datastore will save in the relevant Data Set Template.

To set the snippet, double-click the action to open the snippet text view:

Use the snippet to perform the following functions:

• Create a DYNAMIC variable called dataValues
• Assign custom data into the new dataValues variable.
  • Note: Use key names that exactly match the Data Keys configured in your Data Set Template.
  • The example includes First Name, Last Name, Account Number, and the CXone Call ID. You can use this same method to save any user data you would like.
• Create a new variable called dataValuesJson using an asjson() function which takes the content of the dataValues variable and formats it as a JSON string in the new dataValuesJson variable.
• Create a new DYNAMIC variable called postBody.
• Assign the value of the call ANI variable passed into the sub script ({p5} in this example) to the postBody variable.
• Assign the entire body text for the HTTPS post to the postBody variable using the following format:

{{"customer_contact_number":{postBody.customer_number},"data_values":{dataValuesJson}}

• Lastly, assign the body text to a non-dynamic variable (postBodyJson) to be used in the next Rest API action.

The full snippet text for this example is below:

DYNAMIC dataValuesASSIGN dataValues.FirstName="{p1}"ASSIGN dataValues.LastName="{p2}"ASSIGN dataValues.AccNum="{p3}"ASSIGN dataValues.CallId="{ContactId}"ASSIGN dataValuesJson="{dataValues.asjson()}"DYNAMIC postBodyASSIGN postBody.customer_number='"{p5}"'ASSIGN postBody.body="{{"customer_contact_number":{postBody.customer_number},"data_values":{dataValuesJson}}"ASSIGN postBodyJson="{postBody.body}"

(Optional) Datastore Post (REST API Action)

This optional REST API action allows you to post the data set in the previous snippet action to the Mindful Datastore.

Configure this action as follows:

• Caption: Set to the name of the action, for example, Datastore Post.
• Service Address: The Datastore URL passed into the sub script by the inbound queueing script (represented as {p7} in this example).
• Headers: Two required HTTP headers for the HTTPS Post to the Mindful Datastore:
  • Content-Type: Select application/json
  • Authorization: Enter the authentication token associated with the Data Set Template in Mindful Datastore. This is passed into the sub script from the inbound Queueing script, represented as {p8} in this example.
  • Both headers are added to the Headers parameter in this action in the format: {Content-Type":"application/json","Authorization":"{p8}"}
• Parameters: Use the postBodyJson variable set in the previous Snippet action.
• Verb: Set to POST

Xfer to Mindful (Transfer)

This Transfer action facilitates the caller's transfer to Mindful to finalize the callback registration.

Configure this action as follows:

• Caption: Name the action, for example, Xfer to Mindful.
• Parameters:
  • Destination: Set this to the provisioned SIP number for the relevant Mindful Call Target. Passed into the example sub script as parameter [8], it becomes variable {p9}.
  • CallIerID: The ANI of the caller, including the national prefix (such as 1 for North America). Passed into the example sub script as parameter [4], it becomes variable {p5}.
• Result Branches:
  • Set all branches except the Default to return to the inbound Queueing script.
    • This ensures that any issues with the transfer to Mindful Callback are handled correctly, and the caller will be queued to skill instead.
  • Leave the Default branch blank, and ignore any warnings when saving the sub script.

(Optional) Set Disposition Actions

The previous section showed that all Result branches from the actions within the sub script (where the caller is not transferred to Mindful) should exit the sub script directly via the Return action. However, it is worthwhile to consider setting a disposition value for each type of result. This allows you to differentiate various scenarios, such as when the Mindful status check fails, the EWT is under the configured threshold, or the caller declines the callback offer. A simple Assign action can be used for this purpose, as shown in the example below:

The example sets a variable named mindfulDisposition with a value that describes the reason the caller was not transferred to Mindful. In this case, the value indicates that the caller did not accept the callback offer. You can define different dispositions for various results, as illustrated in this example sub script following the logic described in this section:

These dispositions are returned to the inbound Queueing script and can be utilized to make decisions in that script, for reporting purposes, or even for displaying information in a screen pop for the agent. If you choose to assign dispositions, ensure that the return branches in each step shown in this section, which were previously going directly to the Return action, now point to the relevant Assign disposition action instead. For instance, in the Offer Callback menu action, the default branch should reference the Assign disposition action rather than the Return action:

Return to Queue Script (Return Action)

The Return action serves to direct a call back to the script that initially invoked the current sub script. You only need to configure the ReturnValue parameter when passing data back from the sub script to the invoking script. This includes scenarios like the dispositions described in the previous optional Assign action. In the example below, the {mindfulDisposition} variable is set as the ReturnValue.

This completes the inbound sub script! In the next section, we will complete the inbound configuration by modifying the existing inbound Queueing script.

Modify the Inbound Queueing Script

This step typically involves modifying the existing Queueing script used to process inbound calls and queue to an agent/skill group. It adds Mindful Callback logic using the newly created sub script described in the previous section and can also add some logic around the optional Second Chance Callback call flow (described later).

Follow the steps below to configure the necessary actions.

Set Mindful Data (Snippet Action)

Configure a Snippet Action to assign variables with the data required for the Mindful Callback sub script. To do this, add separate Assign lines within the snippet. Double-click the Action to open the Snippet properties text view.

The following shows example assignment logic:

Assign Caller First Name to {firstname} variable.Assign Caller Last Name to {lastname} variable.Assign Caller Account Number to {accountNumber} variable.Assign Call ANI to {ANI} variable.Assign Target Skill ID for this Call to {skillID} variable.Assign Mindful Callback Transfer Number to {callbackNumber} variable.Assign Mindful Scheduler Widget URL to {schedulerWidgetURL} variable.Assign Mindful Datastore URL to {dsURL} variable.Assign Mindful Datastore Auth Token to {dsAuthString} variable.

The callANI, dsURL, and dsAuthString variables are only required if you're using the Mindful Datastore. You can find the widget and Datastore URLs, as well as the Datastore Authentication token, in the Mindful platform UI.

If you are using the Datastore, remember that the caller's ANI is used as the index key, and both Mindful Callback and Datastore use national numbers (such as 11 digits for North America). Since Nice CXone uses 10-digit numbers, you'll need to concatenate the ANI with the national prefix and store it in a separate variable. Use {ANI} with a prefix of 1 for this purpose, as shown in the preceding example.

subMindfulIn (Runsub Action)

To invoke the Mindful Callback sub script, configure a Runsub action as follows:

• Click Choose Script at the top of the action window and select the sub script you want to invoke.
• Give the Runsub action a name using the Caption parameter.
  • For example: subMindfulIn.
• If needed, set a return variable.
  • In this example, the data returned by the sub script is assigned to a variable called mindfulDisposition.
• Select the parameters to be passed into the sub script. To do this, click the ellipsis (...) on the Parameters line, which will open the editor.

• Add the variables to be passed into the sub script, one variable per line, then click OK.
  • The variables will be listed in the order they were entered, with a parameter number starting with [0] (as the parameters are passed in an array).

In the sub script, these variables will be available using parameter variable names. Note that the variable names start with the number 1. For example, if you have firstName shown as [0] in the Runsub action, it becomes variable {p1} in the sub script. Similarly, lastName shown as [1] in the Runsub action, becomes variable {p2} in the sub script, and so on.

(Optional) Set screen pop (Assign Action)

To present variables to the agent in a screen-pop window when they answer a call, follow these steps using an Assign action:

• Assign the desired variables with a ScreenPop value of True in an Assign action.
• Click the Assign action to open the properties text view.
• Set the variables you want to present in the screen pop by creating separate Assign lines within the action. For example:

Assign callerInfo = {firstName} {lastName} - Account: {accNum}

In this example, the variables first Name, last Name, and accNum are assigned into the callerInfo variable, and the ScreenPop parameter is set to True. By setting the ScreenPop value to True for specific variables, you'll ensure that those variables are presented to the agent in a screen pop window when they answer a call.

Queue to Skill (Reqagent)

To prioritize callbacks returning from Mindful over regular queued calls, use the Reqagent action with a lower priority, as seen below:

• Click the Reqagent action to open the properties text view.
• Set the priority to a value lower than that of regular queued calls.
  • In this example, we used a priority of 10.
• Ensure that there is no acceleration set for the Reqagent action.

By giving the Reqagent action a lower priority than regular queued calls, you will ensure that callbacks will be placed at the front of the queue, as the callers have waited for a callback instead of waiting on hold. This prioritization can be achieved using custom priority management in CXone.

Create a Callback Queueing Script

The return-call (callback) script is typically a new script created to queue return calls from Mindful to an agent/skill group. The key functionality is to:

• (Optional) Retrieve any inbound call data via custom SIP headers from Mindful, or...
• (Optional) Get inbound call data from the Mindful Datastore.
• Queue to the agent skill at a priority higher than inbound calls for the same skill.

The following Actions are used in this script.

(optional) set Mindful Vars (Snippet Action)

This action is only required when using the Mindful Datastore to pass data between NICE and Mindful. This action sets the URL and auth token for the Datastore GET to retrieve the inbound data into the callback script.

To set the name of the action, right-click the action and set the Caption with the action name. Close this, then double-click the Snippet action to define the actual snippet code to set the variables as shown in this example:

(optional) Get SIP Hdr (Sipgetheader Action)

This action is only required when using SIP headers to pass data between the CXOne inbound/callback routing scripts and Mindful (as opposed to using the Datastore). This example shows the value of the X-nice-skillid SIP header being set as variable skillId. This skill ID, set in the inbound script, can be used to target the skill used in the inbound call, so that only one callback script needs to be created, rather than one for every call type or skill.

(optional) datastore Get (Rest Api Action)

This Rest API action action is used to retrieve data from the Mindful Datastore if data has been passed to it during the inbound call. Consult the steps below to configure this action.

• Give the action a name (such as datastore Get).
• Set the service address to be the two variables containing the Datastore URL and the call ANI set in the Snippet action earlier in this script ({dsURL}{callANI}).
• Configure two headers for the Headers property:
  • one for the content type
  • one containing the authorization token (set in the Snippet action earlier in this script).
  • The format will be: {"Content-Type":"application/json","Authorization":"{dsAuthString}"} -- where dsAuthString is the name of the variable containing the Bearer token string set in the previous Snippet action.
• Set a variable name for the resultSet (out) property (such as dsReturn).
  • This will be used to assign the returned individual data items to variables in the next Assign step.

(optional) Set Caller Info (Assign)

This example assign action shows how data retrieved from the Mindful Datastore can be assigned to variables for further use.

Each data value can be assigned using the format dsReturn.<data field name>, where dsReturn is the name of the resultSet (out) variable set in the previous Rest API action, and the data field is the name of the field as it is configured in the Mindful Datastore. For example, if the data field is called firstName, it can be retrieved using dsReturn.firstName. These can be assigned to individual variables for use in routing decision or agent screen pop.

Queue to Skill (Reqagent action)

After any optional inbound data has been retrieved via SIP headers or the Datastore, queue the call to an agent skill. This example shows the target skill using the skillId variable passed from the inbound call, using a custom SIP header or a field from the Datastore GET.

The callback script is now ready for testing and should look something like this example. This example shows data being retrieved using both custom SIP headers and Mindful Datastore--typically one or the other would be used, not both:

(Optional) Second Chance Callback Configuration

Second Chance Callback offers callers the opportunity to receive a callback after they initially decline the offer in the inbound sub script. This option is presented while the call is in the queue, as part of the announcements played during the wait.

The logic for Second Chance Callback is mostly a modification to the queueing part of the inbound queueing script. A typical queueing script would have the Reqagent action target a skill, followed by a Music action and then maybe an announcement (Play action) and then back to the Music action (perhaps via a brief wait step). This would normally loop until the caller is answered by an agent, or the caller disconnects. For example:

The diagram below assumes that the inbound queueing script logic is already implemented. This diagram begins at the point where the caller is initially offered a callback. The second-chance logic modifies the inbound queueing script, so it is more like this:

The script relies on a disposition being passed out of the Mindful sub script so that the second-chance logic will only apply if a customer has already declined a callback offer. This is important, because if the call exits the sub script for any other reason (for example, the transfer to mindful failed, or the wait time is no longer above the configured threshold), then the caller should not continue to receive offers.

We previously assigned the return variable for the sub script, shown here as mindfulDisposition:

This will be used with the second-chance logic, which is described below. Firstly, queue the call to skill as usual using the Reqagent action. This action branches to a Music action which plays music for a set amount of time. In this example, the SecondstoPlay parameter is set to 120 seconds:

Once that time expires, move the call to an If action:

This example If action has an Expression of mindfulDisposition = "Callback Offer Not Accepted". If the mindfulDisposition variable, containing the return data from the sub script, contains the string Callback Offer Not Accepted, then it will once again invoke the Mindful Callback sub script to offer a callback for a second time. If the disposition is not Callback Offer Not Accepted, then do not pass the call the subroutine, instead continuing with the queueing loop until an agent answers or the caller disconnects.

The entire sample inbound script with Mindful Callback logic, including Second Chance Callback, looks like this: