A place to ask questions, connect with others, and stay in the know
We have some questions related to “Starting Menu” on Architect (inbound flows).
When a customer presses an invalid option (for instance, we have the options “1” and “2” and the customer presses “5”).
For timeouts, when a customer doesn’t press any option.
From what we understood, when this kind of timeout happens, the call is automatically disconnected or is redirected to a selected "Default Menu Choice".
Thank you in advance.
Thanks for the questions. :)
Yes, you can do that. The approach we'd use here is to have a reusable task with a Play Audio action that then jumps back to the main menu:
And then under the main menu you go ahead and add menu choices for the "invalid" DTMF values that jump to this reusable task. In the screen shot below I added a couple of the "invalid" menu choices but it shows the general idea:
You could add additional logic to that reusable task from above that increments a counter, add a Decision action and if that counter is greater than or equal to three then you Transfer to ACD, Disconnect or whatever. Otherwise it would jump back to the main menu.
If you used the above approach, one possibility would be to change the audio and play "No valid menu choice was selected". That may be sufficient but obviously doesn't distinguish between the case of "we received DTMF and it was invalid" vs. "no DTMF input received".
Below is another approach because if you want to have more granular or dynamic handling, remember that you can always use a reusable task. The logic below uses a collect input to get DTMF input where 1 transfers to Sales, 2 transfers to Support, any other DTMF will play "invalid menu choice selected" and no DTMF input plays "No menu choice selected":
Obviously you'd want to put that logic inside of a Loop action or something get retry logic set up if there was an invalid DTMF entered, no DTMF or a transfer failure but I wanted to point out you can get a lot more control this way if you really want. FWIW, the switch action would look like this:
First of all, thank you for your answer! :)
I have only one doubt related to last topic, timeout from the costumer/no option select.
The approach where we have a reusable task for invalid options (for 1 Transfer to Sales, for 2 Transfer to Support, and the other digits Transfer to reusable Task) doesn’t distinguish between the case of "we received DTMF and it was invalid" vs. "no DTMF input received".
Therefore, if we want to consider both cases, we need to use the last approach (a Task where we collect the input and use a switch case action).
In this approach:
I think I might be missing something here…
Thanks for the follow-up. As far as this:
Yes, you'd use the task as a starting task on the call flow. Within that task logic underneath the Case statements for the switch you can add actions like Transfer to ACD or whatever as appropriate. The Default case will be invalid choices and the Failure off of the Collect Input will be taken if no input received.
If you wish to use the built in menu support you could use a Jump to Reusable menu action as well in the task. Once you're inside of a task you'll get a lot more flexibility to do what you like but implementing support for picking a "default" would need to be done in the task logic itself. Another benefit is using Transfer actions in a task will also have a Failure output where you can hook up additional logic. Functionally one benefit that menus have over task logic is that they support speech rec and since the Collect Input action is DTMF only, that's one thing to remember is that a task solution wouldn't be able to take advantage of speech rec until you jumped to a reusable menu but it does provide a mechanism to handle the cases which you've discussed here.
There is still the menu approach which I outlined earlier that gets pretty close to handling these cases as well.
Yeah, the one thing to remember is that if you have a starting menu as the start object configured for a flow rather than a starting task, it's menu choices underneath the starting menu that can be a task but the starting menu itself isn't a task. That's why we have the option to set the starting object of a flow, technically it's only certain types of call flows, to be a task or menu. That's also true with the top level menu of a reusable menu as well but menu choices underneath it can be a task. Hope that makes sense. :)
Thank you for your answer :)
I'll use the task as a starting task on the call flow, since here with a switch case and a loop I can do the validations that are required (3 times for invalid options, on each present a message, and on the last one disconnect or transfer the call).
Ok. Good luck! :)
Every year, Genesys® orchestrates more than 70 billion remarkable customer experiences for organizations in more than 100 countries. Through the power of our cloud, digital and AI technologies, organizations can realize Experience as a Service℠, our vision for empathetic customer experiences at scale. With Genesys, organizations have the power to deliver proactive, predictive, and hyper personalized experiences to deepen their customer connection across every marketing, sales, and service moment on any channel, while also improving employee productivity and engagement. By transforming back-office technology to a modern revenue velocity engine Genesys enables true intimacy at scale to foster customer trust and loyalty.