Just wondering if someone can help. We have an issue with a UCCX 7 deployment where an agent in a queue initiates what he refers to as a warm transfer to another queue. Essentially he he is transferring a caller to another queue by initiating a conference with the queue and then ending his side of the call once in there, leaving just the caller hearing the "your call is important" type messages. Think of it as holding the callers hand until they have been queued. The issue is that once their call is handed off to the next available agent in the second queue the caller, the new agent AND the queue are now conferenced together ie. the caller and the new agent continue to hear the in queue messages.
Is this the expected behaviour in this scenario? We have asked the agents to simply transfer the callers to the second queue if possible, but as they aren't very happy with what they see as a loss in functionality I'd like to rule out a possible solution before saying it can't be done. The part that I'm not wrapping my head around is how, once the agent leaves the conference, the caller, the new agent and the queue are being conferenced together. Surely the ad-hoc conference ends once there are only two participants, and if so what is initiating the new conference.
Any ideas will obviously be very much appreciated. Cheers in advance
That's not the correct name, in my opinion.
The industry standard definition of a "warm transfer" or "consultative transfer" is that the caller is placed on hold while the first agent finds the second agent. Whether the first agent does this directly to the second agent, or does it through the queue, wherein he must wait for the second agent to become available and answer the consult call in the queue, is immaterial.
This is "warm" because the first and second agent can exchange information about the caller, producing a smoother handoff of the call. Once the second agent has been given the information and indicates they will accept the call, the transfer can be completed.
There is no need to do this as a conference - and it is detrimental to do so, as it uses up conferencing resources and bandwidth (a problem in a branch office environment). When done as a consult, and once connected to the target agent, one can even use the alternate-reconnect to toggle back to and forth to the caller and second agent to facilitate introductions. With practice, this can be done correctly without doing a conference.
Should no second agent answer the queued call in a REASONABLE time, the first agent gets the caller back (kills the consult leg) and explains the situation. This is what makes it "warm" - the caller is never left stranded.
Now what your blokes are doing is a bit useless. What is the point of the two parties being in conference to hear the queue message? If the agent wants to dump the caller in the queue, which is what they are doing (nothing "warm" about it), then they can start a consult to the queue point, hear the start of the messaging, and complete the transfer - dumping the caller into the queue.
Basically, they are messed up. They COULD do it with a conference as long as they WAIT for the 2nd agent to answer - then all three parties are in conference. But it my opinion it's not needed. But if they want to dump the caller off into the queue, just use a consult + transfer in the normal way.
I really enjoyed reading your response. Great explanation!
I wish more of us where this direct with customers.
Mate, you're preaching to the choir I'm trying to convince them not to bother initiating a conference to the queue, but it's more the mechanics behind the behavior we're seeing that I'm interested in. Just want to know that if a caller is dropped into a queue in this manner should it form a conference with the 2nd agent, caller and queue once the 2nd agent is presented with the call?
Yeah, sorry about that mate. I figured you were between a rock and a hard place.
Quite frankly, I don't know why it does that. I'm a UCCE and CVP integrator. I did experiment with this some time ago and CVP does not do what you have described.
It does sound like a bug though.
It's possible the agent conferenced to queue once, then accidentally conferenced to queue again. In that case there would be two queues as part of the conference, and you would see the behavior you describe. I've seen agents do this before, it's one reason you should discourage conferencing into a queue.
Well now you have me curious. Let me test it in the lab and I'll let you know. I'll be doing it on 8.0, but I am not aware of any direct changes to this part of the code other than what was necessary to port to Linux.
I simulated this with one agent instead of two on the FCS build of 8.0 but was unable to reproduce the behavior you mentioned.
1. Made agent Ready.
2. Called from IP phone to queue and got routed to agent.
3. Agent picked up the call.
4. Hit the Conference softkey on the phone and dialed the UCCX trigger and heard the prompts that I was waiting in queue.
5. Hit the end call button to get the agent out of the call.
6. My agent went into Work state, so I put the agent into Not Ready.
7. I then put the agent into Ready state again and the call got delivered.
8. When I picked it up CID refreshed into a direct call between caller and agent and the audio path did not include the queue.
If you think it's an issue and the agents are not using any of the unsupported softkeys, open a TAC case and we'll take a look.
This is great stuff, Ryan.
Thanks very much for taking the time to check this out in your lab.
Wow guys, thanks! Really above and beyond what I'd expect from most forums. I'm leaning towards a TAC case now, will try and see if I can reproduce the issue with a bit more frequency first. Thankyou so much guys, this really helped!