UCX V10.5 Script Editor

[rossporubski]

Can anyone please explain what the ‘Barge In’ radio button does within the “Prompt Tab” of the menu attribute? Not from the official White Papers, as that is vague.

[Aaron Harrison]

HI Ross

Barge controls whether the caller  can interrupt playback of the prompt by inputting DTMF etc.

This compares to 'interrupt' which determines whether the system can interrupt the prompt to route the call to an agent.

Aaron

[rossporubski]

Thanks Aaron,

By your definition, is it your professional opinion that if barge is set to no, the caller should 'NOT' be able to make a selection and DTMF should not be recognized at all during message playback? Even if an option is selected during playback, it should 'NOT' route the call at completion of playback?

We're really having a huge problem with TAC about this. By definition in conventional legacy PBX systems Interrupt and Barge mean the recording playback cannot be interrupted at all, including DTMF during playback. The caller can 'ONLY' make a selection after the recording completes.

Cisco is telling us their interrupt in UCCX no longer works the way it's always worked. DTMF can be retained during playback and will automatically route the call after the recording playback has completed without the caller having to make a selection when Barge/Interrupt is set to no.

[Aaron Harrison]

Hi

Well... my professional opinion is generally that I don't have time to spend arguing with TAC if I can engineer a workaround. But I know how you feel.

All we can base it on is what the documentation says (taken from http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_8_5/programming/guide/uccx851_step_ref.pdf):

Barge In Radio button. Yes—The caller can interrupt the prompt. No—The prompt must complete playback before the caller can respond.

Based on that, if the caller CAN respond prior to completion of callback, then it's not performing in accordance with the docs, and it should be fixed.

Of course, TAC will be unhelpful and will log it as a 'documentation defect' as it's easier to fix a PDF than code...

Aaron

[rossporubski]

Your quoted reference from the white papers is exactly our position here. Even the TAC agent agrees the verbiage is vague at best.

[quote]

No—The prompt must complete playback before the caller can respond.[/quote]

Essentially, I can engineer what you are suggesting but it's not something the business wants. If the functionality is there and it's supposed to work, then we want what we paid for. That is currently our argument, if they agree it's not working as designed, (which the engineer has done twice and reneged both times) then they should fix it.

[Aaron Harrison · Accepted solution]

Hi

Agreed, they should fix it. Doesn't sound vague to me - if the customer can queue DTMF then its a response.

It's going to be a long time to hold your breath for though. Believe me.

It's possible to script around it, so that's what I'd do in the interests of reaching a successful conclusion for your client. You can still chase this up separately... just my two pence worth.

Aaron

[rossporubski]

It's an interesting situation. I'm the developer and I'm moving on to another employment opportunity elsewhere. I need to make this as unobtrusive as possible. Not knowing what the next person's level of knowledge is, the scripts have to be as basic as I can make them.
 

[Aaron Harrison]

I've seen some truly horrible CCX scripts. I'm sure if you are a developer and apply some nice logic and flow to the scripts, and annotate/document it well that it will be pretty clear what's going on.

You can even add annotations to each step using the tabs on the customiser for the step, for example to explain why there are seperate prompt/menu steps etc. 

And I think if I was the 'new guy' I'd rather inherit a system that was doing what the customer wanted rather than a horrible long winded TAC case and a problem to fix on a system I may not know that well ;-)

Regards

Aaron