I have an ACD hunt group that I would like to set up the following way.

If the caller is in queue for over 5 minutes recall to a application that allows them to press a digit to be transfered to another group or continue to stay on the line.

Currently the hunt group correctly recalls to an application that plays the message and gives them the option to transfer. The message plays correctly, and the transfer works correctly, but when then I transfer back to the hunt group (via timeout in digit translation)the caller gets put at the end of the queue. How do I keep their place in line?

You can't do that when the call is sent to a hunt group recall destination. You must use the 'Announcement' or 'Overflow' destination instead. You can give the caller options to leave the queue or do nothing to remain in queue.

Okay, I got rid of the recall destination, and moved my app to the Overflow destination, and the same thing happens.

My app plays the message and people can move out of the queue to leave a message and if they remain on the line I have timeout set to transfer back to the hunt group. When that happens they still go to the end of the line.

Your timeout on the call routing app should be 'hangup'. The overflow and announcement destinations are conferenced in to the hunt group call, so the call routing app will play its greeting script then hangup, which leaves the caller still connected to the hunt group. Keep in mind that the overflow destination is conferenced in every time the overflow timer expires. The announcement destination is conferenced in only the first time the announcement timer expires.

Okay I made the change. It was set to hang up when we were using recall. That actually hung up on the caller.

Can you give me a decent explanation as to what announcment, overflow and recall should be used for. I've read the documentation and it was not clear at all.

By the way our vendor is the one who set up this programming using the recall and caused the caller to be hung up on. That's why I figured I wouldn't ask them to fix it.

I don't blame you. The Announcement dest. is used typically to play an initial recording, usually a call routing announcement (CRA), to the caller while they wait in Q. The Announcement only plays once when the Announcement timer runs out. The Overflow dest. usually is a different CRA that plays to the caller and it repeats every time the Overflow timer runs out. The recall destination can be any device on the system and the call is sent to that device when the Recall timer runs out, removing the call from the hunt group.

So, lets say you have a 'Sales' hunt group. The timers for this hunt group are Announcement: 12 seconds, Overflow: 60 seconds, Recall: 150 seconds.
Announcement Dest.= CRA 2510
Overflow Dest.= CRA 2511
Recall= CRA 2512
Here's how the call flows...

Call enters the Sales hunt group and if a keyset/agent is available, begins ringing that location. If not, the call will camp on to the group.

After 12 seconds, CRA 2510 is conferenced in, the recording says something like "You have reached ABC company sales group. Your call is very important to us and will be answered in the order it was received."

After 60 seconds, CRA 2511 is conferenced in, the recording says something like "Please continue to hold, your call will be answered in the order received."

After another 60 seconds, CRA 2511 is conferenced in again.

After 150 seconds, the call is sent to the Recall dest., CRA 2512. This greeting can say anything or nothing and/or timeout at a reception or mailbox or timeout or whatever.

Thank you for the explanation. It all makes sense now.

Now I think I officially know more than our vendor!

FYI, we are doing this also. In our over-flow message we just found out you could add in audiotex recording to the day and night greetings of the CRA, to announce the callers position in Queue, and expected hold time.
Audiotex Recordings
Q = Queue position
T = Expected Hold time
The hold time is calculated off the Hunt Groups Timer "avg call length" I think

Our customers have been happier just knowing how long they have to wait

Keep in mind that the 'T' or Expected Time to Wait parameter is not dynamic. The phone system takes the Average Wait Time Per Call time from the hunt group timers list, multiplies that value by the number of waiting calls and divides by the number of available agents. If you just happen to get a situation where the PBX is playing to callers that the expected wait time is '2 Minutes' and the caller ends up waiting 10, they are likely to be pissed when the call is answered. If you play to the caller that there are 2 callers ahead of you, and ten minutes later there is 1 caller ahead of you, I think most callers are fine w/ that.