I have several departments that have reported this issue. When they do a cold transfer to another department, where there are already calls queued waiting for agents, the call bounces straight back to the person who just transferred them. The call leaves the My Interactions and is gone, then comes back as a new interaction. It doesn't happen every time, it is sporadic. 2015 R4 Interaction Desktop

Have you looked at the call event log of the problematic call to see what the system shows happened? You could also turn IP up to 80 and look through the IP log for a call that bounced back to get more info.

Originally posted by MarkT;34215
Have you looked at the call event log of the problematic call to see what the system shows happened? You could also turn IP up to 80 and look through the IP log for a call that bounced back to get more info.

I have attached the pictured of the call log. [ATTACH]777[/ATTACH]

That log Appears to show the call being transferred into Attendant from the first user (RobinsonS), then goes to another workgroup, waits the appropriate amount of time for about a 10-second Follow Up time for the agent, then routes to that same agent again...maybe because somehow that agent is activated in both queues?

Originally posted by GGanahl;34276
That log Appears to show the call being transferred into Attendant from the first user (RobinsonS), then goes to another workgroup, waits the appropriate amount of time for about a 10-second Follow Up time for the agent, then routes to that same agent again...maybe because somehow that agent is activated in both queues?

The agent is not, that agent is actually new to the company so they have only ever been in the one correct workgroup. I thought that might have been it as well, I also looked into it being Smart Target but it is not active on either the calling or called group.

Humor me...verify how the agent did the transfer (typed an extension, drag-n-drop to a workgroup, drag-n-drop to an Attendant profile...whatever). Then, verify that the Attendant Group Transfer (which is what it looks like was involved, though not sure) is set up to go to the correct workgroup.

Originally posted by GGanahl;34278
Humor me...verify how the agent did the transfer (typed an extension, drag-n-drop to a workgroup, drag-n-drop to an Attendant profile...whatever). Then, verify that the Attendant Group Transfer (which is what it looks like was involved, though not sure) is set up to go to the correct workgroup.

The way the agents are trained is to hit transfer button and then type in either name of the user or workgroup, then Transfer or Consult. Everything is set up correctly and none of the other departments have problems doing the same thing. Which obviously points to something different in the build of the problem department. While I did not do the build of this department myself, my predecessor did, I have gone through every setting and configurable option in the workgroup setup in Admin, as well as the security settings and individual users and have found no differences other that statuses, numbers, and other generic info. This didn't start happening until my predecessor upgraded to 2015 R4, which is what we are still on. I wondering if it is just some kind of specific bug. I am in the early stages of planning an upgrade for next year but I was hoping I wouldn't have to wait until then to find out.

I think this might be a change of functions between versions. Although I haven't tracked it down I have noticed some interesting transfer behaviors when sending calls to an attendant profile. I experienced this on a CIC 2015 R2 P24 server. The agents transfer to attendant profiles which play some wav files and then do a workgroup transfer to the workgroup. If the agent consult transfers to the attendant profile and presses the transfer call button while the call was in one of the play prompt steps and was not transferred to the queue yet the call would bounce back to the agent who was transferring the call. I never looked into it because the customer never complained about it and figured it was just how I was testing but it seems very similar to the issue you ran into.