How to test your IVR and call flows with live logging

The safest way to test call flows and find out exactly what is happening at each stage is to examine the 'Logs' section (found under the 'Reporting' top-bar navigation menu) whilst making test calls. This is essentially a readout of almost everything that is happening on a call.

Here we'll be testing a very simple flow in order to check whether certain things are happening correctly during the call. Often it is unclear whether they have happened just by listening to the call, so the logs provide a quick reference for all call activity.

The call will be routed straight to an Input Reader where a DTMF input variable will be stored: "1" for sales, "2" for support.

Then the call will be routed to a Switch Node, which will use the variable value to decide which application to route the call to – either 'Sales info' (pressed 1) or 'Support info' (pressed 2).

Simple_switch.png

Now let's make test call straight to this flow. In order to route the call straight to the Input Reader we need to go to 'My Settings' > 'Numbers', find the number which you would like to test with and select the Input Reader application. 

Then, we call that number... no matter what happens here, make sure to have the Logs open in another tab or window so you can see them appear in real time. 

This is the Logs readout from that call. Note the timestamps recorded for each log entry:

When the number was called, a list of options was played, asking the caller to press 1 for sales information or 2 for support information. "1" was entered at this point. But after "1" was processed as a DTMF input, the call was routed to support information, not sales. Let's take another look at the Logs to see what could have gone wrong:

As you can see, the logs are not always ordered chronologically, so a bit of detective work is required to see what happened when. We can break the call logs down into 3 parts with the help of the timestamps:

  1. The first part happens between 09:43:47-48 – the inbound call attempt appears, and a URL is resolved in order to play the 'Service options reader' prompt listing the options (press 1 for sales, 2 for support). 

  2. Moving up to step 2 (09:43:56), we can see that, as shown by the prompt URL in step 1, the 'Service options reader' application was successfully reached. The log entries within this second of the call all happen within applications, which is indicated in the 'Category' column – they are of the type 'VOICE_APPLICATIONS'.

    "1" was pressed during the call, and we can see a highlighted log in this part: "read input serviceoption = [1]". "serviceoption" was the input variable, so the DTMF input "1" was stored successfully as this variable. The remaining log in this part shows that after having done this, the call was sent to 'Service options switch'.

  3. Part three happens in the same second as part two, but we can see that everything in this part happens in the 'Service options switch' application. After having reached this app successfully, we see that one of the log entries begins with "[switchNode]". This indicates that this log entry will give information about what happened when the Switch Node decided where to route the call.

    The "triggered app is [Support info]" shows which Prompt Player the call went to, but below this we can see that "[[trigger] Pressed 1 for sales info (ALL)]" was fired. Here is our problem: the routing options in the Switch Node are mixed up. 

In order to fix this, we just have to go back to the 'Applications' view, enter the settings for 'Service options switch' and make sure that the routing to the sales and support information application modules matches up with their respective triggers. Et voilà! The next call gave gave the correct routing and produced these logs:

 

Have more questions? Submit a request