Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Going up instead of down in queue position announcment

Status
Not open for further replies.

haggisuk

Technical User
Jun 20, 2014
1
GB
Hello

we have had queue posisition announcements active for a couple of years on some of our scripts (we use these in conjunction with wait times etc) and we have recently had a couple of caller stats they were told they were 7 then next loop they were 8 (as an example) - as I say only had a couple of people say this - thousands of callers have not - and it is as far as I can see impossible to prove or disprove - anyone had similar feedback before and is it even possible?

The below is the script I use and this is in a loop

many thanks (ps new to this forum so hopefully have done it right!)

ASSIGN POSITION IN QUEUE Skillset_cv TO pos_holder_cv

IF pos_holder_cv <= pos_check_cv THEN
OPEN VOICE SESSION
PLAY PROMPT
VOICE SEGMENT queue_pos1
NUMBER pos_holder_cv
VOICE SEGMENT queue_pos_end
END VOICE SESSION

ASSIGN pos_holder_cv TO pos_check_cv
END IF
 
There are scenarios that can move a caller back in line (return to queue, higher priority call, using oldest instead of first in queue). It appears we are missing a critical piece of information in your sample script - what is the value of pos_check_cv the first time through. If this is all of the code that deals with the variables listed, then it would be helpful to know the default value of pos_check_cv.

Having the whole script would be more helpful.

There is no easy way to prove it. If you thought you wanted to be able to prove it or see a pattern you could use HDX/DIW to save the caller ID, call ID, and position played to a database each time you play the message.

Duane
 
Hello Duane

Many thanks for your feedback

I have assigned 20 to pos_check_cv for the initial pass through - so basically it will only give the position in queue if 20 or under initially and then the scripting takes care of it from there. We have oldest first on the line of business, all our calls route through to forced auto answer (no return to queue) and there is only 1 call and queue priority - hence my confusion. I feel that this may be one that we cant ever prove - if indeed it did happen. In you experience - if there has never been any issues of the type previously in many years, then all of a sudden you get a couple of people saying the same thing "i went up instead of down" in the queue - would this be a fluke or "technical issue" and is it simply a case of "it happened and we wont know why!"

Many thanks again.



 
Could it possibly be an agent misuse?

What is your clerical time (time between completion of this call and start of the next)?

Is it possible that agents are placing themselves into MSB thus forcing a call back into the queues, thus pushing everyone up a position?

Agent performance reports may be your next step.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top