Queue Length for Hunt Group/Skill Functionality Question 1

[des0906]

We have been testing our Queue Length settings for hunt groups/skills on a G3r v11 (also known as v1.3). We have seen the following treatment that concerns us:

1) Call goes to Queue on Skill/Hunt Group with a Queue
Length of 1.
2) 2nd Call gets ACD treatment when calling the VDN that
feeds the Vector for that Skill, and does not go into
Queue (which we expect).
3) If Call 1 is abandoned, though, the 2nd call that is
waiting in the ACD loop (music, all agents busy, etc.)
will never go into Queue.

All subsequent calls beyond the Queue length behave the same way. How can we prompt the system to push a call into Queue when a free Queue slot opens up?

Here is the Vector and Skill/Hunt Group we are using for our test. Once again, for test purposes, Skill 41 is set to a Queue Length of 1.

CALL VECTOR

Number: 901 Name: Voice Team Test
Multimedia? n Attendant Vectoring? n Meet-me Conf? n Lock? n
Basic? y EAS? y G3V4 Enhanced? y ANI/II-Digits? y ASAI Routing? y
Prompting? y LAI? y G3V4 Adv Route? y CINFO? y BSR? y Holidays? y

01 wait-time 0 secs hearing ringback
02 queue-to skill 41 pri m
03 announcement 62007
04 wait-time 30 secs hearing music
05 announcement 62008
06 goto step 4 if unconditionally
07 stop
08
09
10
11

HUNT GROUP

Group Number: 41 ACD? y
Group Name: 41-Voice Team test Queue? y
Group Extension: 60041 Vector? y
Group Type: ead-mia
TN: 1
COR: 1 MM Early Answer? n
Security Code:
ISDN Caller Display:

Queue Length: 1
Calls Warning Threshold: Port:
Time Warning Threshold: Port:



Any thoughts on this will be appreciated.

Thanks.

 

[avayafreakje]

maybe you can try this:

CALL VECTOR

Number: 901 Name: Voice Team Test
Multimedia? n Attendant Vectoring? n Meet-me Conf? n Lock? n
Basic? y EAS? y G3V4 Enhanced? y ANI/II-Digits? y ASAI Routing? y
Prompting? y LAI? y G3V4 Adv Route? y CINFO? y BSR? y Holidays? y

01 wait-time 0 secs hearing ringback
02 queue-to skill 41 pri m
03 announcement 62007
04 wait-time 30 secs hearing music
05 announcement 62008
06 goto step 2 if calls-queued in split 41 <1
07 goto step 4 if unconditionally
08 stop
08
09
10
11

Besides of that, why would you want this?

 

[dufus2506]

I believe the obvious answer is to raise the queue limit!

It will behave the same way, and the calls will flow through in the order they were received. If a call abandons, the calls behind it move up in in the order.

I'm confused. Why limit the queue to only 1 call?

Carpe dialem! (Seize the line!)

 

[des0906]

Good thought. Another question, then. Why do callers beyond the Queue Length value go into the normal ACD treatment to begin with, rather than getting a busy signal?

Thanks.

 

[des0906]

In response to dufus2506, this is a test vector and hunt group/skill. Our production environment has queue limits of 10 and 20. Our concern, obviously, is that callers may be waiting to go to queue indefnitely. We inherited a number of programming oddities with this environment and are working through them.

 

[dufus2506]

They're not going into normal ACD treatment. They're just following the vector program.

You don't have to do a single ACD 'thing' to a call for the call to follow vector instructions. When a call fails to queue, the system looks to then next vector instruction for what to do.

In your case, the calls were attempting to queue, failing, and then moving on to the next vector instruction for what to do next with the call. In this case, play a message, wait some time, and play another message, etc...

Since you built a loop, the call always found a vector instruction it could follow. 2nd calls seemed like they were behaving like the queued call, because they were. They were just not in line to be answered.

Increase the queue, and you'll be fine.

Carpe dialem! (Seize the line!)

 

[dufus2506]

I'd increase the queue length if you have a fairly busy call center. Personnally, I make every group queue the same size as the incoming trunks that carry my incoming calls. Having a g3R I have plenty of queue slots to go around.

If you consistantly have 10 or 20 calls in queue, then yes. You could potentially get calls that would be 'parked' in the vector instruction loops, and never answered. They would eventually abandon, or would be disconnected after their call followed 1000 vector steps.

Carpe dialem! (Seize the line!)

 

[des0906]

Good information and thoughts all around! However, is there a way to throw a busy signal out there once the queue limit is reached? If we have to reprogram several hundred vectors, we will. But if we can avoid it....

Once again, great to hear from y'all on this subject. This is a great forum!

 

[dufus2506]

You don't have to reprogram any vectors. Just the queue lengths in the definitions of the skill group.

If you want to limit the queued calls and return a busy, then you'd have to re-write your vectors. (hundreds? shudder...)

This instruction would go before the queue the call instruction:

goto step x if calls-queued in split y => 20

Stepe x would be 'busy'

Be sure to setup an alternate method to queue calls to that skilll that might be transferred from other groups. You wouldn't want a caller to be answered and then transfered to a group only to get a busy signal and be disconnected.


Carpe dialem! (Seize the line!)

 

[telcomnewbie]

A more efficient solution would be to set the queue size equal to your incoming trunks. Start pulling reports to see what type of ACD call volume is coming in. If there are more calls than the agents can handle, there is software out there that can help the manager justify hiring new agents based on call volume, etc.

It's never good practice to give a caller busy signals unless they can't get a substitute for your product or service.

 

[wildcard100001]

des0906,

You could put another queue to skill %%% step in your vector to catch the calls that didn't queue on the first queue step. So, in your loop sequence add the queue step. If a call is already queued the PBX will not re-queue them when hitting this step. The call will keep it's place in queue (if you had additional queue length limits). It's a good way of not looping to the beginning of the vector. In Centre Vue, calls not queued but are in a vector have a status of "seized" on the real time trunk reports.

Hope this helps...

Thanks,

Wildcard