MiVB MiCC 9.0.1.0 - UPIQ total time in queue present different menu 1

[TCSI17]

Hi,

Does anyone have any experience with presenting different options to the caller when they are in queue for a certain length of time (via UPIQ Workflow)?

What I'm trying to do is if the call hits a certain time in queue 2min 30secs that the UPIQ will then start to present the caller an option for callback (along with the regular UPIQ options).
I have the queue and UPIQ setup properly to play the messages in 30secs intervals and that is all working ok.
I checked the variables and I don't see a variable similar to currentCallTotalQueueTime - something that will give me the time that the current call was in queue for and when it hits my 2min 30secs mark, I would like to to essentially branch off and add another menu in there.
I'm still playing around with this and I think i can do it with variable date/time compares, but was wondering if there was a more elegant way to do it?

 

[Billz66]

I also tried and eventually gave it up.

Mitel need to better documentthe ivr call flow options as there are so many things like this that look like we should be able to do but are too hard to work out how to do it.

I tried messing with an inqueue workflow to route calls that had arrived before closing and got therough teh schedule check but then ended up in a queue with no agents and no path unavailable or forced interflow.


If I never did anything I'd never done before , I'd never do anything.....

 

[techymitel]

Use interflow dialling lists on the path along with rad messages.

Your rad message can offer continue holding or press 1 for callback for example. Interflow dialling list associated with that path option 1 will be a hunt group going back to the ivr. The workflow associated with the ports will have a hunt group match rule and will go into a callback action. Usually the same workflow as your call initially came into - just a different branch based on hunt group. Initial call may go through scheduling etc based on cli or hunt group.

More details here.

http://micc.mitel.com/kb/KnowledgebaseArticle51669.aspx

 

[Billz66]

I agree with techy , thats probably the only option , make last rad play the message with options, set interflow dialling list to send calls to an ivr hunt group for the callback
if they press teh digits they leave the queue and get the callback enter dialog , if they dont , then they stay in the queue

If I never did anything I'd never done before , I'd never do anything.....

 

[TCSI17]

@techymitel - Thanks very much for your input. I ended up using the hunt group action to forward the interflow dialing list option 1 calls to, and match calls coming in via those hunt groups as you mentioned and pointed them to the callback workflow. Works very well!
I had to use 3 RADs to get the call flow to be how i wanted and on the 3rd RAD I used the interflow dialing list to enable the option 1 for the caller. Works well.

I originally had this more or less done within the Inqueue workflow and variables to track the loop but it didn't work quite right. I was surprised that I was able to as the IVR is pretty flexible, but nonetheless it wasn't exactly what I needed. Your suggestion was spot on though.

Very much appreciate your help. Also thank you @billz66 for your comments as well.

 

[AlphaMann]

Correct that inqueue workflow basically runs like a RAD. You can use it to easily play different messages for different positions, wait times, or many other variables, but in the end you need the path interflow dialing list. I usually configure a silence RAD at the beginning of the path to enable interflow dialing list and then use the inqueue to do all sorts of other wonderful stuff.

 

[TCSI17]

Ahh, I see what you mean. Great idea!