check the .wav folder for StillQueued.wav or rebuild a test call flow maybe a corrupted database.

At the end of the "Queued" call flow you need to add a [TRANSFER] with a transfer call to destination $ACD

ezapdk I've heard people say that before, but I've never found a need to do so, and in fact the documentation states that you should simply end the callflow, any unlinked results will put the caller back in his place in the queue.

Although I admit I haven't tried this on 2.1 yet.

I have had this before after an hour of trying to make it work i built a new group and it worked fine mide you in this case it was version 1.2.

And as far as I know you must transfer back to $ACD to keep the caller in the Queue

Morrack is correct, when programming a custom Queued or Still Queued start point, you don't need to add a $ACD to the disconnect.

Using the VM Pro client, put somthing into the default Queued start point and then select File | View as Text and look for the default.ACD.Queued sections.

For the action you inserted you should see "EVENT RESULT.Next=Abrupt Queued Disconnect.Route" and if you look for the "Abrupt Queued Disconnect.Route" it should show


Abrupt Queued Disconnect.Route
{
    INTERRUPTABLE
    ACTION WAIT
    EVENT RESULT.NODE_ENTRY=Abrupt Queued Disconnect.Action
}

Abrupt Queued Disconnect.Action
{
    INTERRUPTABLE
    MSG en\MC_02
    ACTION TRANSFER=$ACD
}

The Abrupt Queued Disconnect Route for Queued call flows is assigned to any action results which don't have a specified following action and it is always set to $ACD. If your having to insert $ACD thats a bug.

Another key thing to know is that it is the switch, ie. the IP Office control unit that presents calls for the queued and still queued events plus passing across the call data (position in queue, eta, etc). So if still queued is never happening its likely a switch problem, not VM problem.

On VM Lite and a VM Pro in IP Office mailbox mode, it easy to test by accessing the hunt group mailbox and recording different queued and still queued messages for the group (ie. without having to add any custom callflow, access the mailbox and press 3 and then either 3 (queued greeting) or 4 (still queued greeting)).

There is a limit on Hunt group naming of 13 characters anything over this it will replay the .queued and never go to still queued.

Does this help ??

0

MrIPO that looks like that could be my problem! The Group name is CustomerService, I will rename and try again.

Just Renamed CustomerService to CustService and changed VMPro and all is working!!

Guess we all learn somthing new, A tip well worth remembering MrIpo

Thanks, MrIPO... your post sure helped me... I had about exhausted all the troubleshooting possibilities I could think of... then I thought, "I'll check Tek-Tips!"

Great insight... you get a "star" from this newbie!

Mark

Isnt the limit on users 15 characters, why 13 on groups???
Strange Avaya engineers!!!

They has been a recent Avaya IP Office tech tip on this subject that explains the problem (and yes its looks like a design and test oversight).
 

To all,

This thread caught my eye because I just finished a 412 that had issues w/ the Queued and Still Queued announcements.  Either custom or defaults.

In our case, calls were getting trapped in the queue.  This is still the case.  Avaya has identified it as a bug and is currently working the case.  If others have found work-arounds for it, wonderful.  However, don't bang your heads too much.  Again Avaya identified it with us as a bug and is working on a maintenance release for the system.

Just an FYI...

Hope this helps...

Kris

@kristiandg:

Don't know how to thank you!
We have tried reporting that bug several times now! We have two systems with that failure, but Avaya have newer accepted the problem..

We have seen the problem in 1.4, 2.0 and 2.1

I hope the maintenance release wi'll be out soon