FIFO Call Priority

[mightyking]

Helllo Experts,

I am building a script in which we have one call and two CSQs. CSQ1 and CSQ2

The call comes in and needs to be answered by the first available agent in either CSQ1 or CSQ2.

Please note this is not a overflow situation. Here're the solutions that I believe would answer to our needs:

Solution #1

The first solution was to use Nested Queuing. With this solution the call is queued into both CSQs which falsifies the statistics in the reporting. If we have 4 calls presented, the reporting shows 8 calls in queue, 4 in CSQ1 and 4 in CSQ2.  Please note that the reports are consulted by two different departments.

I tried several solutions but the following is the chosen solution but in this solution it looks like the FIFO call priority is not respected. We did some intense testing and noticed that the 10th call in queue being answered first and the 5 call in queue answered in third place. Kind of WEIRD!!!!

Chosen Solution:

A third CSQ (CSQ3) has been introduced. All calls will be logged into the CSQ3 for reporting purposes. The call will be delivered to the first available agent in either CSQ. The CSQ3 plays the role of a distributor and contains the details about calls on hold, abandoned, average waiting time etc.

I am attaching the call flow as well as the script. Could you please let me know why the FIFO is not being respected? Any other solution would be greatly welcomed.

Thanks,

MK

[TomMar1]

What do you mean "one call and two CSQs"?

I have 2 call flows and 2 CSQs, I sets skills for the agents for both call flows.  When calls are queued they are presented to agents based on the time they enter the system.  You could be the next call to be answered in 1 CSQ, but based on the time the call originated into the system you may wait for other (older calls) to be handled first.  Obviously the caller does not know this.  No issues with reporting or FIFO.

[Anthony Holloway]

I have never heard of FIFO not working in UCCX.  So, assuming for a moment you didn't just find a defect with the product, I can say two things that should help you.

1. If you're going to test a low-level fundamental feature of the system, you should do so with the most simple script and scenario possible.  E.g., Don't use priorities, don't use different call in numbers, don't check for stats, etc.  Use the fewest number of steps to test your scenario.

2. The area where you use the Select Resource step with the CSQ variable, then later change the value of the CSQ variable and using a Goto to jump back to the Select Resource step; this is unsupported and can cause issues.

[mightyking]

Thanks Anthony,

Regarding your second point, how can I correct the situation in this case?

Thanks,

MK

[mightyking]

I did some changes in the script. Can you please see if this is supported? Script is attached.

Thanks,

MK

[Anthony Holloway]

I can't open your script at the moment, but the solution is simple: never re-use the same Select Resource step within the same script.  If you need to nest queue the contact, use separate Select Resource steps.  The reason is simple: The interrupt handler needs a specific and unique step to jump to.

Also, I never did end up offering an opinion to your original scenario.  My vote would be to use a separate queue for the entire group of agents.  Nested queuing only as a last resort.

[mightyking]

Thanks Anthony,

I would appreciate if you could have a look at the script when you have time and let me know what you think about the changes I made.

Thanks,

MK

[mightyking]

Here's the newest version in which I tried to use a separate Select Ressource statement.

Thanks,

MK