How to create IVR input structures for menu options with interrupt

Sometimes you will want more control over your IVR menu structures. This article will show you how to implement an interrupt mechanism in a menu, allowing a caller to 'barge in' by dialing an option before the audio prompt has finished. 

There is already a type of application on the babelforce platform which is preconfigured to handle IVR menus - the Simple Menu. But using a combination of two other types can achieve the same effect and offer more flexibility when customizing your call flow. These are the Input Reader and the Switch Node. Let's take a brief look at how they will interact before we dive into the instructions. 

In our example here the Input Reader will play a prompt explaining some typical service options and their corresponding touchtone / diall pad inputs: "Dial 1 for sales queries, 2 for supplier queries and 3 for anything else." After this interaction, the call will be told to route straight to the Switch Node. (If you would like to try an input reader with an easier use case, feel free to read this introduction.)

The Switch Node will then test for the various inputs, and route the call to either the sales, supplier or main agent queues. If it does not find a match, there will need to be further measures used in the call flow.

This tutorial will assume prior knowledge of creating/saving applications and triggers.

  1. To start off with, let's create the two applications we will need: the Input Reader and the Switch Node. First we will need to configure the Input Reader. The below config will work for our scenario:



    There are a few things to note here:

    • 'Min length' and 'Max length' are both 1 as we will be asking the caller to input just one number. Inputs with more or fewer digits must be dealt with separately.
    • 'Termination' is set to 'None' for the same reason; if we were asking the caller to type in a 10-digit number, it would require a sign (e.g. '#') to signal the end of the input. Here, however, it is not needed.
    • 'Read timeout' is the time after which the app will assume there has been no input. This is set to 7 seconds to give the user a reasonable length of time to respond.
    • 'Barge-in delay' will be where you determine the number of seconds before a caller can interrupt the prompt with their chosen input. It is set to 0 seconds here to allow the caller to barge in as soon as they have heard enough.
    • The 'Behavior' settings are set this way to circumvent no-input conditions from triggering within the application. We recommend that you keep 'Ignore no-input' switched off (red cross) unless you would like to use specific audio prompts to remind a caller when they haven't entered anything (after the 'Read timeout' amount); these prompts can be specified in the 'Prompts' tab. If you turn this on and set the 'Max retries' to "2", it will run through these prompts before going to the Switch Node. If you leave it switched off, the Switch Node will deal with all no-input/no-match cases.
    • 'Variable name' is important as it will reflect the decision being made by the user, and should be easily identifiable when we come to building the triggers. It should not contain spaces.
    • 'After flow' indicates where the call will be routed to afterwards, so is set to the corresponding Switch Node application we have already made.  
    • The audio prompt explaining the options will of course also need to be configured in the 'Prompt' tab. 

  2. Now we build the triggers which will be used in the Switch Node to test for the input options. The below configuration will successfully test whether option 1 (sales query) has been pressed. 




    Note here that we have chosen the expression which appears in the dropdown menu with our variable from step 1 inside ("serviceoption"). This trigger just checks the input which corresponds to the variable. Because we defined the variable inside our Input Reader application, it checks to see whether the input was "1".

    The configuration is the same for the two further triggers, which test for options 2 (supplier query) and 3 (other), except of course that the 'Expectation' is "2" and "3" respectively. So we just repeat his process for the other two.
  3. After these triggers have been built, we need to configure the Switch Node to use them. This will make the application use the input and check whether any of the triggers fire. If they do, the call must be routed to the corresponding part of the call flow. So if "Opted for sales - 1" fires, it must send the call to the sales queue, etc.

    But  what if the caller gets it wrong? In this scenario, we would like the call to loop back to the Input Reader again, so that the caller can have another go. But if we just ask it to start again it will sound a bit strange. So there should be an audio prompt in between which says something like: "Sorry, I didn't get that. Please try again". Now the Input Reader will sound much smoother. To achieve this, we're going to ask the call to be routed to this retry prompt application, which will always send the call back into the Input Reader after it has played.

    The complete configuration of the Switch Node will look something like this:



    When configuring the no-input/no-match route, deciding the caller's experience is key to the call flow design. For example, if the menu options they are offered are many, you might decide that the call should be routed straight to the main queue. Or whatever you like. The caller's experience in this case can be designed separately, then linked up to the Switch Node by selecting applications for the appropriate trigger. If you want to learn more about designing a call flow experience, you should read this help center article.

By adjusting the settings in this kind of IVR flow, you can create highly customized call experiences whilst keeping the flow lightweight and efficient.

Have more questions? Submit a request