Return To Queue Calls - Agent Performance Report

[TheCardMan]

We are experiencing an issue with "return to queue" calls showing up in agent performance reports. Our call presentation is set to force the call to the agents. "Call force delay timer" is set to 8 and "After call break timer" set to 2, we also have the check box marked for "Answer by placing DN call on hold". I am seeing pegged calls under the column "Returned to Queue" (not timeout).

I have looked at the call by call detail and found the return to queue happening right after the call was presented. In the same second and the reason code sometimes states NRDY or UNKNOWN. I have set up a test scenario where I duplicated the settings and when presented a call we tried to hit the not ready button quickly or DN button to see if we can send the call back to the queue but all that does is disconnect the call.

How else can I find out what is making this happen? We are using 1150e phones with headsets. Could they be unplugging the quick disconnects of the headset while the forced presentation tone is heard?

 

[dj4020]

Is this happening to everyone or just a select few? If this is just a select few then someone has figured out a way to force a call back to queue, then shared it with friends. However with that being said if the Call by Call shows not ready or unknown the difference is probably when this event happens the system may not know the state due to timing issues in the process. If this is random and is happening all over the place I would look at the LAN side of things start sniffing your network for a short time see if you can relate this return to queue with some QOS issue or some other event ? ? ?

 

[TheCardMan]

I see this across most agents, but a few in particular are really high. I don't know if this is caused by something in the script or all these agents are onto some kind of trick to get out of calls. Like I said, the call by call report show the call being presented to the agent (forced) then immediately returned to queue. This is strange and I do not want to put blame on the agent if this is not caused by them.

 

[sandyml]

We had something similar, with VoIP phones and Return to Queue. In the end, it was a router configuration problem of some sort.

 

[TheCardMan]

Thanks - any information regarding what type of issue it was with the router configuration would be helpful. If you can lend more detail.

 

[dj4020]

If you run a sniffer on your network you will see successful calls and the ones being sent back to queue, You should see the reason why because of what you will see.

 

[Milesprower]

Why is your call force delay so high (8 seconds)? do you have a slow screen-pop application?

It is possible to get RTQ on call forcing, but agents usually have to "get good at it". In other words, they are timing the system try and go busy at the right time.

 

[TheCardMan]

No, no screen pops here. I am questioning the 8 seconds myself. My understanding that the value in that field is in seconds. But when taking the call it seem almost 1 second as you hear the tone you are presented the call. So I don't understand why if the value is 8, I get the call within 1 second of hearing the tone in the headset.

 

[Milesprower]

The system finds an agent and then it waits 8 seconds before connecting the audio path. You should be able to go down to 0 or 1 seconds.

You can create a new call presentation class and move a test agent or two to start.

 

[bajangsa]

Even 1 second between hearing the tone and getting the call is enough time to manually press the Not Ready key and return the call to the queue. You have to react quickly, but I am sure it can be done.

You reject a call by pressing Not Ready instead of answering it, and these calls are pegged as "return to queue".

I would appreciate hearing if anybody out there has experienced otherwise.

 

[sandyml]

CardMan, we were having router timeouts. Do the agents ever complain of having to wait for email attachments to open, etc.? That went along with it, although the agents were more or less used to that and thought it was system normal. But with the IP phones, it looked like the call just timed out. As bajangsa said, check the reports to see if these calls are pegging as RTQ due to timeout, or just RTQ (as in, the call got bounced back).

 

[TheCardMan]

They are pegging as just RTQ. Not Time Out.

 

[sandyml]

Since they are call forced, have you watched some of these agents to see if they are hitting their In Calls button? Or perhaps it is a setting on the phone regarding handsfree vs. headset, or auto answer on the phone or headset?

 

[captaingadget]

I'm with Miles on this one. There is no reason at all to have a delay timeer. You should uses the break timer AFTER a call if you need give the agents a little time.

 

[TheCardMan]

I found out that the Call Force Delay timer is different then what I thought. My understanding if I had the timer set to "8" a call will be presented to an agent with a BEEP tone and the agent would have 8 seconds to prepare themselves for the call before the audio path was connected. I was wrong, it is the time before the agent hears the Beep to present the call. So if I set it to 8 seconds, the incoming call targets an agent that is available, selects that agent, waits 8 seconds (caller hearing ring), then beeps the agents headset and the call is immediately connected. Why have such a timer? A timer after you hear the beep to prepare yourself and your workstation for the call makes more sense to me.

 

[Milesprower]

The timer is there so you can sync with your CTI application. In the olden days, it was common for the CTI app (Screen-pop) to be slow and the call would arrive on the agent phone before the screen popped.

These days, CTI apps are much faster and the need to slow down call delivery is rare.

 

[TheCardMan]

Got it, Thanks Milesprower and all for the understanding. I have a good idea on what is happening here based on what the agents do, going in and out of certain states. This may be causing a lot of these RTQ calls and may not be a agent tricking the system. I am making adjustments to the timers before and after the call so I can eliminate the RTQ a bit and see if any agents are still registering with high RTQ counts.

Thanks again!!