UCCX - Dynamic NoMatch/NoInput Tries

Question

CCX Experts,
One of our project requirements is to play different prompt to the caller in any Dialog state based on the NoMatch / NoInput count.
For Eg:
Dialog                : Please press 1 for Option A, press 2 for Option B, press 3 for Option C.
User Input          : Press 5               (NoMatch count=1)
Dialog                : Sorry, you’ve entered an invalid input. Please try again. Please press 1 for Option A, press 2 for Option B, press 3 for Option C.
User Input          : Press 6               (NoMatch count=2)
Dialog                : Sorry, still you ‘ve provided an invalid input. Please try again. Please press 1 for Option A, press 2 for Option B, press 3 for Option C.
User Input          : Press 7               (NoMatch count=3)
Dialog                : Sorry, you’ve exceeded your maximum retries.
Limitation of UCCX:
UCCX doesn’t allows us to play a custom prompt for NoMatch/NoInput individually.
The system prompts associated to NoMatch/NoInput also cannot be altered during runtime and also it refers to the same prompt irrespective of the tries.
So we have come up with an alternate solution like below:
Solution:
Set the “Maximum Retries”  under Input tab of any GetDigitString to “0”
Create following variables,  
noinputTries      int           0
nomatchTries    int           0
MaxTries          int           3
For any NoInput and NoMatch, the dialog control comes to Timeout and Unsuccessful path respectively. During such scenario, we are incrementing the respective tries and validate against the MaxTries value [pre-defined / configurable]. If the tries didn’t exceed, play appropriate NoMatch/NoInput prompts based on tries.
Attached the script (StandardTries.aef) for reference. Few clarifications on how we can do the same functionality in an efficient way.
In the dialog step itself if we can have a provision to map the NoMatch/NoInput prompts based on count. Then we can directly map the prompt Ids in the step itself. By this, the no.of steps execution would be decreased instead of writing 3 to 4 steps to implement the same behaviour for a single dialog.
If we have any API support
To throw and catch No Match/ No Input events and then take the caller to apt flow.
To play prompts dynamically
Also for the above point if we can dynamically populate the value for Goto step, so that we can create a different flow for this and route it to the place from where it was invoked.
What will be the performance issues if we increase the no of steps from the default value of 1000.
Thanks in advance
-Sethu

Answer 1

Hi
I use a similar technique myself. Generally I don't care if I can tell whether the user gets something wrong or times out - both those are the same to me.
I just have a 'count' integer that I increment each time I hit timeout or unsuccesful, and if that hits 2 or 3 or whatever the customer wants, go to a failure action.
In answer to your questions:
1) It has been a limitation of the step for a long time. I don't expect it to change, since the workaround is pretty easy.
2) a) No idea
     b) You can set the prompts dynamically. Just set the value of a prompt var to a string (e.g. if you want to play 1.wav, set the Prompt var to "1" - it automatically looks for 1.wav in the current language.
3) Gotos are static. You can control which goto step you hit using IF or Switch steps then branching out.
4) Don't worry about it. I have some management scripts that run a lot of steps; this counter is there as a loop break mechanism. As long as you don't put in any infinite loops, you won't have a problem. I increase it on most of my installs.
Aaron