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)).
![[cheers]](/data/assets/smilies/cheers.gif "[cheers] [cheers]")
