CCX "Delay step" Interuptable

[ryan_oconnell]

Hello all

I am trying to build a simple section within a call flow and CCX is not behaving the way I think it should. What I’m trying to accomplish is present a customer waiting in a Queue with the option to press 1 at “Any time” to be diverted to voicemail instead of waiting for the next available agent. Nothing fancy. What I have built, is

a Menu step within the Queue that provided the customer with instructions that they can press 1 now or anytime to be sent to voicemail.

After the Menu step I used the “place call hold” trigger

followed by the “delay step” which I have made interruptible,

then Call un-hold” trigger

followed by a Goto step back to the same Menu prompt.

The Menu prompt is set Not to flush the input buffer, so that any keys pressed in the Loop is processed soon as it gets to the menu again.

So everything above works fine except the “Delay Step” When I press 1, the system is recognizing DTMF was sent to the IVR but it doesn’t interrupt the Delay step for whatever reason, it just waits for the full timer of the delay step then it processes the 1.

This is CCX version 7 with CUCM 7. We are using CUC for the voicemail.

Thanks

[Jonathan Schulenberg · Accepted solution]

The interruptible parameter is referring to other script code (e.g. An agent becoming available). What you are looking for is a Barge In parameter (i.e. Contact Input) which does not exist in this scenario. For starters the media stream is disconnected from the CTI Port and CUCM has instructed the calling end point to play MoH instead.

The workaround we have historically used is to crop a WAV file equal to the length of time you want between prompts and then to play that as part of the menu step. Essentially you mud keep the caller on a step that accepts input and not put them on hold.

Sent from Cisco Technical Support iPhone App

[ryan_oconnell]

Hi Jonathan,

Thanks for the info on the Delay step, I assumed "interuptable" ment "dtmf interuptable" not a change in the ready state of the agent.

As for the workaround i was hoping there was another way. Croping a Wav file means forcing the callers to listen to the same "file" every (period of the loop duration) which forces the caller to hear the same thing over and over again. Unless you use several different wav files, then it just become a managment issue.

I am surprised that there is not a step that can put a caller into a holding pattern of your difined duration, and have it "barge capable". I know I have called into many IVR's in the past and had this option available to me, this is where I got the idea from in the first place. I guess in these cases the IVR's I was calling into were not CCX

If you have any other Ideas for workarounds I will be glad to hear them. Otherwise thanks for your clarification on what "interuptable" really means

[jasyoung]

It's not clear to me whether DTMF reception works, or is supposed to work consistently while on hold in UCCX. It doesn't quite make sense to me since media traffic is directed toward a MOH sever rather than UCCX while on hold. I actually lost money on a bet with a coworker, he told me he'd done exactly what you wanted above (Hold-Delay-Unhold with working barge-in) and it worked. I told him he was full of it, and he showed me that it worked on his customer's system in reactive debug. But, the same type of script doesn't seem to work on my other customer systems. I'm not sure what the variables are, CUCM and UCCX versions and gateway types and connection methods and so forth.

Anyway, if you're successfully buffering DTMF in a Hold-Delay-Unhold loop and your only problem is lack of barge-in on Delay, change your Delay step to a Play Prompt with a prompt value of DP[1000 * HoldLoopSecs]. The DP[] syntax is used to play silence of X milliseconds, so you'd want 60000 for 60 seconds. It's usually used as part of concatenated prompts, to space out other Prompts you want to play, but you can use it here just for the delay/sleep effect. It's valid, or at least you don't get exceptions, playing prompts toward a Contact on hold. The advantage of Play Prompt is you can definitely barge-in, just set barge-in yes and flush input no, and make sure your succeeding Menu or Collect Digits step doesn't flush input.

In the alternative you can, of course, play a fixed MOH-like prompt or set of prompts as Jonathan describes above. If you do that it's best to have several prompts and do random rotation, or sequential rotation with a random start point in the list.

Let us know how it works out.

[Anthony Holloway]

Awe man, I was going to propose the play prompt dp[] solution. Nice one!

Sent from Cisco Technical Support iPhone App