Skip to main content
Skip table of contents

Features of OCP miniApps®

Introduction

A common feature set is a key to the OCP miniApps® concept. OCP miniApps® are built with uniformity and simplicity in configuration and maintenance, designed to have the maximum possible positive impact on the task completion rate (TCR) of the self-services they are involved in. All miniApps are able to use custom prompts, configured at the time of invocation. Prompts may be pre-recorded audio files, TTS-based generated audio files, or real-time TTS streaming. There is an unlimited level of prompt customization, to match any requirement:

  • Information Request Prompts

  • Confirmation Prompts

  • Disconfirmation Prompts

  • Reactions

  • Agent Request Prompts

  • DTMF Agent Request Prompts

  • Hold functionality prompts

  • Error Handling Prompts

  • Input Validation Prompts

This guide describes the features that exist in all offered miniApps with minimal differentiations depending on the actual type of each one of the miniApps.

Error Handling

All the error handling fields have built-in optimized default values but allow you to fully configure them if needed.

The following Error counters are used in the application:

  • NoInputs: Global counter of No Input events (i.e. no speech was heard) occurring throughout the dialog.

  • Consecutive No Inputs Counter: Counts consecutive No Input events. The counter is reset if an event other than No Input occurs in the dialog.

  • NoMatches: Global counter of No Match events (i.e. speech was detected, however, no interpretation was assigned to the caller’s utterance) occurring throughout the dialog.

  • Consecutive No Matches Counter: Counts consecutive No Match events. The counter is reset if an event other than No Match occurs in the dialog.

  • LowConfRejections: Global counter of No Match events (due to low confidence) occurring throughout the dialog.

  • ContinuousLowConfRejections: Counts consecutive rejection events, the counter will be automatically reset to 0 if another event occurs.

  • Consecutive (Mixed) Errors Counter: Counts No Match and No Input events. The counter is reset, if an event other than No Match or No Input occurs in the dialog.

  • Global Error Counter: Counts NoInput, NoMatch, Rejection, Same State events throughout the dialog. It is not reset.

  • Same State Counter: Counts Same State events. A Same State event occurs if the system has assigned interpretation to the caller’s utterance, however it did not manage to update its belief state and continue with a different action.

  • ContinuousSameStateEvents: Counts consecutive same state events. The counter will be automatically reset to 0 if another event occurs.

  • Wrong Input Counter: Applies to the sub-dialog. Counts invalid user information entries.

  • Disconfirmation Counter: Applies to the sub-dialog. Counts user disconfirmation/rejection on the confirmation step.

  • Agent Request Counter: Counts the number of times the caller requested to speak to an agent throughout the dialog.

Request prompts

The request prompts (a.k.a Ask prompts) are the prompts responsible for extracting the target information from the caller and are set up as such. OCP miniApps® allow you to fully configure these prompts. Each of the prompt types allows to configure up to three different prompts that will be played sequentially when there is a no response or no interpretation error. The prompts that can be configured for handling this request step depending on the dialog step are the following:

  • Initial: This is the initial prompt that will try to extract information from the caller.

  • Reask: Reask prompts handle cases where you want to re-prompt the caller after the requested info was provided by the miniApp.

  • New Task: New Task prompts handle new cases when the previous case was completed.

  • Start Over: This prompt is similar to reask prompts but takes place with the help of Flow application and starts the whole process from the beginning, and any previously received data is removed.

Reaction prompts

Reaction prompts help you interact with the system, thus giving you a more natural feel. When an event occurs (set to be handled with a reaction) one of the following custom reaction prompts is played before continuing with the flow.

  1. Error reaction

  2. Nice reaction

  3. Agent request reaction

  4. Greeting reaction

The Error reaction, Nice reaction, and Agent request reaction have three prompts that can be customized. Every one of these prompts is associated with one of three built-in probability values called weights. The first prompt has a weight value of 40, the second a weight value of 30, and the third a weight value of 30.

The system will randomly choose one of the defined prompts based on the weight value. This method helps introduce randomness and increases the seamlessness of the system prompts.

Sometimes, when prompted for input, a caller may first greet the application instead of giving the input directly. For these cases, it is possible to configure a Greeting Reaction, which will trigger in conjunction with the initial prompt resulting in a more human-like experience.

Agent Request

All miniApps have the ability to understand when the caller asks for an agent. The behavior of any one of the miniApps in response to an agent request is fully configurable, in order to blend seamlessly with the overall IVR experience offered to the customer.

Since the miniApp is set to trigger both the Agent request reaction and then the Agent request prompt, it is recommended to set them both up and in a way that makes sense for the caller.

There are three prompts that can be configured for handling this request step depending on the error level of the dialog step.

Hold Functionality

OCP miniApps® have the embedded capability to understand a Hold request from the customer, for example, while the customer is trying to locate a card or membership number. The caller asks for the system to wait, and the call flow enters a Hold mode for a pre-configured duration, which can be extended if the caller asks for more time. The feature can be turned on/off at configuration stage and is fully configurable in terms of waiting time and prompts.

There are five prompts that can be configured for handling this request step.

  • Initial Hold Prompt allows you to set up the audio music file that will be played back during the Hold functionality.

  • Ending Hold Prompt that handle cases where the system asks for your information followed by a [NoInput] event. These prompts help the dialog seem more natural and also notify you that the system supports a Hold functionality option.

  • Max Hold Response 1

  • Max Hold Response 2

  • Max Hold Response 3

Each one has its own error level to configure according to the dialog step.

Not Available Functionality

Further to the Hold functionality, a miniApp can detect the inability of the caller to provide the information. If the Hold functionality of the miniApp invocation is disabled, the miniApp will exit with an appropriate reason code (notAvailable). If however the Hold functionality is enabled, the miniApp will propose to provide the caller with additional time.

miniApp : "May I have your ID number please?"

Customer: "I’m afraid I don’t have it readily available…"

miniApp : "Would you like me to wait for you to retrieve it?"

Confirmation (User Input Read Back)

All OCP miniApps® feature a versatile confirmation mechanism, which reads back the information provided before moving to the next step and asks the caller to accept or reject it. On accepting, the miniApps will exit successfully passing the data back to the IVR flow. On rejecting, the miniApps will ask for the information again. Confirmation functionality can be turned on and off from the configuration, and the prompts used to confirm and the number of disconfirmations allowed are fully configurable.

  • Standard vs Dynamic Confirmation
    Confirmation behaviour can be customized to either ask every time ("standard") or based on a confidence threshold ("dynamic"). When standard confirmation is configured, the system will always request the caller to accept or reject the input. Dynamic confirmation leverages the confidence score returned by the ASR engine during processing and decides whether or not it will request a confirmation from the customer. The behaviour of the confirmation feature, as well as confidence threshold can be set at configuration stage and all prompts (including disconfirmation prompts) are fully customizable.

  • Slow Confirmation
    To further enhance the customer experience, the confirmation module features an additional mechanism which, when enabled, adds short pauses between a long piece of information being read back (for example, between each digit of a credit card number) to give time to the caller to verify it. The mechanism can be enabled or disabled at configuration stage.

  • DTMF Confirmation
    To resemble the legacy confirmation behaviour of DTMF systems, the confirmation module also allows the caller to accept or reject using keys instead of natural language (voice). Key assignment is customizable, for example, 1 for confirmation, 2 for disconfirmation.

Confirmation prompts

There are three prompts that can be configured for handling this request step depending on the level of the dialog step.

However each prompt is composed of two sub-prompts:

  • The Pre prompt which contains a relative prompt played before the read back of the input value provided from the caller.

  • The Post prompt which contains a relative prompt played after the read back of the input value provided from the caller.

Rejection prompts

OCP miniApps® allows you to fully configure the prompts played back in case the caller disconfirms during the confirmation step.

There are three prompts that can be configured for handling this step depending on the level of the dialog step.

Dynamic confirmation confidence threshold

The confidence threshold represents the confidence of the automatic speech recognition (ASR) module and has a range of values from 0 (lowest) to 100 (highest).

During the confirmation step the user can set the confidence threshold to let the system decide whether or not it will enter the confirmation mode.

The system assumes that if the confidence of the ASR is equal or higher compared to the confidence threshold (for example 90), there is no need to add additional confirmation steps in the mini dialog and proceeds by sending the information back with success.

Slow confirmation

Slow Confirmation can be turned on for cases where the system will read back a long piece of information to the caller. This will add a pause between each character and give time to the caller to verify the validity of the information that is read back.

Slow confirmation does not work with TTS/speech morphing.

Confirmation read back

The confirmation read back can be customized to allow during the confirmation step different ways of reading back the information gathered to the caller. There are three different ways the read back can be configured.

  • Plain read back of the values

  • Read back using predefined examples set by the user

  • Read back using the examples the caller provided during his input

The noExamples setting will just read back the values to the user.

System : "Please give me your ID number."

Caller : "AP856196"

System : "To confirm your ID number is "a", "p", "eight", …​.. , "six", correct?"

DTMF Confirmation, Rejection keys

Another feature of the confirmation mechanism is that the caller during the confirmation mode can confirm or reject by using custom DTMF keys. This is useful if the old system required similar functionality. For instance, # 1 for confirmation, # 2 for disconfirmation.

Navigation Commands

OCP miniApps® can understand navigation commands that will result in exiting the step with an appropriate reason code, for example, go-to-start or go-back.

  • Data Validation
    All miniApps expect input related to their type. For example, the "Digits" one expects a set of digits, either one-by-one, grouped together or as a full number. In order to tailor miniApps to specific implementation cases, data validation rule sets are used to narrow down the scope of acceptable values. miniApps feature 5 different data validation methods:

    • Length or date range (input must be within a number or date range)

    • Pattern (input must match a predefined pattern)

    • In list (input must match an entry in a pre-configured list)

    • Custom function (input is validated against an external JS function)

    • Pre-built, off-the-shelf popular validations based on the above, such as credit card numbers, US/Canadian zip codes, etc.

      OCP mniApps® can also use external values to further enhance the above methods and support multiple rulesets per invocation, which means that a miniApp may accept for validation a 4 digit PIN and a 16 digit credit card number at the same time!

  • Barge-in
    OCP miniApps® can be configured to allow callers to barge in while a prompt is being played back. This greatly improves customer experience for those who know what the system is about to ask.

  • DTMF Handling
    Each one of the OCP miniApps® may be configured to be backwards compatible with legacy DTMF systems, recognizing key presses as required. The caller can input numeric values, amounts, and even dates, which are then validated like any other input.

    • Date & Time: configurable to resolve as YYYYMMDD, MMDDYYYY or other patterns.

    • Agent Key: configurable to replicate the legacy system behavior, such as #0 for an agent

    • Escape/Termination Keys: configurable to replicate the legacy system’s behavior for exiting a specific step in the dialog:
      ”Please give me your ID number. At any point, you can press # to skip authentication”



JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close