maximum hunt group (skill) queues

[g3si]

Where do I find this maximum queues setting in my g3si ver 7.1? I am curious if I am having a queue size problem and if that would cause a call to drop once in the vector? Anyone know this one?

thanks

 

[G van Hamburg]

change huntgroup xx.

This is the same number you use in the vector after the que-to command. Plan your work............Work your plan

 

[g3si]

Sorry, I may not have explained this well enough:

I am looking for a system maximum for hunt group queues. I understand how to set the maximum in the hunt group fields, but I am wondering if I have hit a combined system limit and I am also curious what you guys think would happen to a caller if they hit a skill that already is at it's maximum. Would this cause a caller to be dropped? I hope this makes sense.

 

[scottyjohn]

I believe that if a caller hits a skill that has exceeded its maximum calls queued length, they will be presented with busy tone. With regards to exceeding the maximum system limit for calls in queue, look at the "list meas blockage pn yesterday" and this will tell you if you have experienced a blockage for the busiest period the previous day. If the blockage fields in the left column have anything other than zeros in, it means that you have breached the system limit for maximum concurrent calls on the TDM bus and the only solution is to upgrade the switch. John

http://www.eagle-i.co.uk

 

[G van Hamburg]

This is what I tested once:

Max que for huntgroup set to 1.

Vector:

1 wait 2 secs hearing rinback.
2 Que to split xx
3 Wait 10 secs hearing ringback.
4 Announcement xxxx (all busy)
5 goto step 3

The second caller did only hear ringback but no announcement.

This means calls can get lost inside the Definity.

To make sure this never happens (for any reason) use the commands " goto, if calls waiting" or "goto, if counted calls"

Hope this helps. Plan your work............Work your plan

 

[ctr999]

I am not sure if there is a limit to your cumulative queue lengths. The practical limit is the grand total number of trunks that can take inbound calls.

My rule of thumb is to set the queue length to about two times the number of agents in the skill group, with a max length of 100. That may be a little high, but it seems to work well.

Hope that helps.

 

[g3si]

hey, thanks for all the input by the way,

SO I just wrote this in my g3si v7.1 and got different results:

This is what I tested once:

Max que for huntgroup set to 1.

Vector:

1 wait 2 secs hearing rinback.
2 Que to split xx
3 Wait 10 secs hearing ringback.
4 Announcement xxxx (all busy)
5 goto step 3


The second call received the announcements but on list tracing the vector it says queue failed (not surprising), then it just processes the next step. I even tried 3 calls simultaneously, and they all continued processing the steps, just says queue failed. This seems to differ from your results so I am concerned. Not one call dropped for my testing. I have yet to recreate this problem so many users are having. Welcome to my nightmare.

 

[ctr999]

Did you get the announcement?

If the actual calls in queue exceed the queue length on the hunt group, calls will skip the queue step in the vector (the queue failed that you got) and go to your wait step and then continue to go through the loop (wait, announcement, etc.) until the caller hangs up.

 

[lopes1211]

Have you gotten the exact time of the problems and matched them to CMS? You may have a deadbeat agent. Check CMS to see what agents are logged in and trace those agents. After the next complaint, see if you have any agents disconnecting calls after 1 second, etc... -CL

 

[g3si]

ctr999, yes I did get the announcement every time on each call.

While I think that agents are a small part in this, there are too many problems over too many days and over too many different accounts to think it is an agent. I will look at this more closely now however.

 

[lopes1211]

Did you check your measurement reports? "list meas blockage pn today", "list meas tone summary today"? -CL

 

[g3si]

Here is what I see mostly focusing on vec 39 and hunt 14:

Date: 4:19 pm MON SEP 30, 2002

TONE RECEIVER SUMMARY MEASUREMENTS

Meas Total Peak Total Peak Total Peak
Hour Type Req Req Queued Queued Denied Denied

1500 DTMF 580 6 0 0 0 0
1500 GPTD 0 0 0 0
1400 CC-TTR 75 4 0 0 0 0
1500 CC-CPTR 0 0 0 0
1500 CC-MFCR 0 0 0 0

TR Type Total Avail Capabilities

DTMR-PT 20 DTMF
GPTD-PT 10 GPTD
CLAS-PT 8 DTMF,CC-TTR,CC-CPTR,MFCR
ETR-PT 16 DTMF,CC-TTR,CC-CPTR,MFCR,GPTD

Date: 4:22 pm MON SEP 30, 2002

BLOCKAGE STUDY REPORT

Meas Time Division Multiplexed(TDM) Port Network(PN) Link
PN Hour Usage Peg Peak Blockage Time-slots Usage Peg Peak Blockage

1 1000 3486 2502 122 0 766 233 141 13 0
2 1100 798 1017 36 0 766 255 614 15 0



EVENTS REPORT

Event Event Event Event First Last Evnt
Type Description Data 1 Data 2 Occur Occur Cnt

11 No announcement available 39/2 199 09/18/11:41 09/30/12:10 255

This is expected as it is a blank emergency message if needed. No other errors.

HUNT GROUP MEASUREMENTS

14 Xerox Internal Helpdesk 0 800 25 10 14 1 0 173 2
ucd 0

AND FINALLY

ALARM SUMMARY CABINET STATUS
Major: 0
Minor: 0 Emerg Alarms
Warning: 45 Cab Trans Mj Mn Wn PNC
1 auto- 0| 0|29 up
BUSY-OUT SUMMARY 2 n.a. 0| 0|16 up
Trunks: 0 3 n.a. 0| 0| 0 dn
Stations: 0
Others: 0

PROCESSOR OCCUPANCY STATUS
Static: 1% SM: 0%
CP: 1% Idle: 98%

CRITICAL SYSTEM STATUS
Active SPE: A/auto
Duplicated? SPE:n
SPE Power: commercial
Time Source: primary
# Logins: 2 16:26 MON SEP 30 2002

Sorry so much info.

 

[lopes1211]

You are no where near your system limits with any of that. Let's keep looking. -CL

 

[netcon1]

First you will have a problem with a blank message and sending people to it. Call the extension number of the announcement. Do you get a busy? If so then that will mess up you vector processing.

Second disp capacity and look at the 5th page. Queue slots per system. Are you maxed out. (I would not think so as there are plenty!!)

Third check you hunt group/split and make sure that the queue length is set high. If you have 1000 queue slots in the system, then set the hunt group to 99 and eliminate that distraction.

Fourth, check and recheck your vector steps for that split and make sure that there are no events in the "display events" log pointing to that vector you are having trouble with.

The display event log will tell you what event failed in the step and which line it failed at.
eg 11 No announcement available 39/2 vector 39 line 2

Two other points. If the announcement is only to be played in emergencies, why is everyone hitting it now? Also if it is to stay and you get a busy when calling it. record dead air for a second or two and then see if the problem goes away.

Also if you are using it for an emergency, then perhaps you may want to change it to route callers to an emergency greeting only if no one is logged into the group, or if one agent ID is logged into an emergency queue, then play announcment xxxx. The agent isn't actually an agent, but a login/logout button on the supervisors phone which can be logged in and out to activate and deactivate the emergency announcment.
eg

01 goto step 23 if staffed agents in split 99 >= 1
<rest of vector queing and stuff>
23 disconnect after announcment xxxx

Just some ideas.

Netcon1
(Mark if Useful!!!)

 

[scottyjohn]

I agree with Netcon, and I would add a double check step like this

01 wait 2 secs hearing ringback
02 queue to skill xx
03 wait time 30 secs hearing music
04 announcement &quot;we will answer you shortly blah blah&quot;
05 wait time 30 secs hearing music
06 goto step 9 if queued calls in skill xx > xx
07 goto step 4 unconditionally
08 stop
09 disconnect after announcement &quot;sorry we r 2 busy call back later&quot;
10 stop

Also looking at your blockage report you dont seem to be anywhere near the maximum concurrent occupied time slots for the system. I think the maximum on a direct connect sys is 483 slots on the TDM bus but with system overhead you can realistically expect to manage about 420 or so of those for actual calls, both queued and active with an agent. John

http://www.eagle-i.co.uk

 

[g3si]

thanks for the replies again.

Netcon, here is my capacities:

SYSTEM CAPACITY

System
Used Available Limit
-----------------------

HUNT GROUPS, SPLITS, OR SKILLS
Groups/Splits/Skills: 70 29 99
Logged-In ACD Agents: 41 259 300
Logged-In Advocate Agents: 41 259 300
Group Members Per System: 290 710 1000
CMS Measured ACD Members: 266 1234 1500
Queue Slots Per System: 610 890 1500
Queue/Call Status Buttons: 514 0 500+

Intercom Groups Per System: 0 32 32

Modem Pool Groups Per System: 0 5 5

Personal CO Line (PCOL) Trunk Groups: 0 200 200
'+' Limit combined with Facility Busy Indicators

seems ok to me, and I also see I have a maximum of 1500 queue slots in system, and I have not exceeded that.

About the blank announcements; We had set up seperate emergency announcements that would play in the event of an outage, so that we would not have to modify the regular primary announcement. A lot of the accounts use the same generic announcement so that is why we tried this. It is kept blank until needed. It does ring busy when I dial it directly. Is this a poor way to handle emergency messages? Maybe this is the problem? I am removing them from a couple of problem accounts to see if the problem continues.

Scottyjohn, I will take a closer look at the vector sample you provided, but disconnecting a caller because we are busy is not a viable option for me, they would never allow me to do that here in our 24/7 call center.

 

[netcon1]

We have a customer that has added the 99 hunt group optins to all their vectors, so that in the event of an emergency, one login button will set in motion all vectors to announce the emergency message and hang up the caller. The vector lines are put at on the first and last of each vector a caller hits during normal call processing.

You may find that busy announcment is your trouble. Let me know how you make out.

Netcon1

 

[g3si]

hey,

whats your vectoring look like then with the emergency messages in place? I am afraid that that scenario would be fine if WE had an emergency, but typcially the emergency is usually with the client and we play a message to the callers letting them know of a situation with their account, not ours. So one message will not fit all. Make sense?

 

[netcon1]

Sounds like a totally different scenario.

I might approach that using vector routing tables, which would route the caller in the vector to the announcment if their ani or account numbers entered in a vrt routing table.

eg. goto step 32 if ani(or digits) in table 1

That way you can post the bad accounts in the table at will and if the system gets a match, the announcement plays.

There are many ways to do this, but without looking at what you have existing, I cannot comment on any real enhancements.

Netcon1

 

[scottyjohn]

Hi
You could send them to voicemail if you didnt want to cut them off. Or you could put them to a different vector with an eplanation announcement to tell them they may be waiting some time.

Here is a sample vector which includes a refernce to skill 99 as an emergency shutdown skill but also a reference to skill 96 which is one of a number of brand specific shutdown skills so that we can shut down parts of the call centre as well as the whole thing. All that you do is in the event you want to shut down the call centre completely, just login with an ID previously created to include the shutdown skill. So if you had 3 different brand areas you might want to shut down, create 4 skills, 3 for brands and one for total shutdown. These can then be given to the non-technical management to use in the event of a problem outside techie working hours. Just make sure that the skill check is included in the queueing part of the vector so that the shutdown takes care of calls already in the queueing cycle too.

01 wait-time 2 secs hearing ringback
02 goto vector 99 if staffed-agents in skill 99 > 0
03 goto vector 96 if staffed-agents in skill 96 > 0
04 goto step 12 if time-of-day is all 23:00 to all 08:00
05 goto step 12 if time-of-day is sat 21:00 to sun 08:00
06 goto step 12 if time-of-day is sun 21:00 to mon 08:00
07 collect 1 digits after announcement xxxx
08 route-to number 9xxxxxxxx with cov n if digit = 1
09 goto vector 402 (queueing vector) if digits = 2
10 goto vector 402 if unconditionally
11 stop
12 disconnect after announcement &quot;sorry we are closed&quot;
13 stop
John

http://www.eagle-i.co.uk