Calls holding too long in queue. 2

[RTMCKEE]

I'm having a problem with calls staying in queue too long.

here is what part of my vector looks like

08 queue-to skill 3 pri h
09 wait-time 274 secs hearing music
10 route-to number 918882659000 with cov n if unconditionally
11 stop

my problem is when I check BCMS vu stats (real time) Im having calls hold for longer than 274 seconds. I saw one call today holding for 12 min.

Any one got any ideas? (other than making the agents answer the calls, but that is another issue) Should the call be routing to my 800 number after 274 sec.? When I noticed the call on hold for 12 min. all my agents were in AUX would that have an affect on the call not routing to the 800 number?

Thanks,
RTMCKEE

 

[Phoneman2]

Line 10 with cover should be "Y" Wisdom is Knowledge
that is Shared

Thanks All Phoneman2

 

[netcon1]

Check hunt group 3 and see what the queue length is.
If it is low (5-10) raise it to 99 or 100.

Sometimes if the queue length is too low the caller does not actually get queued or handled properly by the switch.

The twelve minutes was problably due to abandonment.

If you have a problem with your agents, then put line 10 first and then fire the bastards!!!

Have a nice day.

Netcon1

 

[Phoneman2]

If you could copy and post the vector and let us know what you want it to do, you'll get 32 different ways to get it done. Wisdom is Knowledge
that is Shared

Thanks All Phoneman2

 

[tiramisu]

Dear:

I think what is happening in your call center is the famous RONA (redirect on no answer). Especially when you tell us that all agents are in aux.

check your skill 3. Do you have Redirect on number of rings filled in ?

a call will come in to an available station rings X times, put the agent station in aux makes an outflow and an inflow in the same skill and looks for another agent. This call is now beyond your vector control and will keep on queuing at "toppest" priority until an agent becomes available.

To avoid this, you can have rona return to a rona VDN, at least you will have vector control back again.

Hope this helps ??

tiramisu

 

[RTMCKEE]

tiramisu,

You are correct, we have RONA set up but no vdn, we left it blank so the caller would stay in that skill, but we assumed it still followed the vector steps. We have over 30 sites and I assume this is a problem at all of them.

What is the best course to take to correct this? I dont want to have to send the caller back thru the menu. Sounds like I should just build a VDN that routes back into the split?

Thanks for everyone's help.

RTMCKEE

 

[tiramisu]

Dear:

I'm glad I could help. To settle this problem you have to work both on organizational level and technical level:

- organizational: Tell agents this is a bad mistake with consequences for the service level measurements. Have supervisors/teamleaders working only on this (by walking the floor !!!); if you have CMS: print out on a daily basis who is responsible for the rona-calls (agent exceptions report or a custom report with database item: NOANSREDIR)
Are you working with aux reason codes ? aux0 will always be used for RONA. so rename the aux0 in RONA and have your supervisor monitor the real-time reports

ETC.....

- technical: yes, have the calls go to a separate VDN. Be careful to queue them to the same skill, because as you said all your agents were in aux. Can you fall back on an audix system for customers to leave a message/ send them to a free station at the supervisor desk (extra warning: RONA has occurred)

FYI: service level is affected because:

% ACDCALLS/CALLSOFFERED

CALLSOFFERED=ACDCALLS + ABNCALLS + DEQUECALLS + OUTFLOWCALLS(these outflows are your rona calls: so each rona call is counted twice)