[cisco-voip] UCCX Queuing and Over flow Queueing Best Practice

[Anthony Holloway]

In my opinion, you're not going to get a Cisco best practice on this one.
You have to play Engineer and figure out what's best for your given set of
criteria.  Also keep in that, sometimes people speak about solutions, when
what they really should have done, is create a problem statement first.
What problem/challenges are they facing today?

By the way, there is one major flaw in the solution you have described.
Which is, Queue A would end up handling 100% of the calls.  Sounds crazy?
Keep reading.

First, let's agree on two things:

   1. You said all of the Agents will be in all three CSQs
   2. The time between each CSQ transition is arbitrary; the fact that
   there is a transition is what's important (E.g., CSQ1 then CSQ2 then CSQ3)

So, take this simple script as an example, where I queue to three different
CSQs for 10 seconds each, allowing me time to go into the Ready state
during each transition:

[image: Inline image 1]

When I let the caller queue to only teir1, then I think we can all agree
that the outcome is expected: tier1 gets credit for handling the call.

What might not be as obvious is, when I let the caller queue to tier2 or
tier3, then tier1 still gets credit for handling the call.  Why?  Well, you
have to consider that UCCX is looking for the oldest waiting contact to
handle next, and when comparing tier1, tier2 and tier3, it's tier1 that
will always have the oldest contact, since it was queued to first, and
hence the system is using tier1 as the CSQ to handle.

You can see below where I placed test calls in to this script, letting the
caller queue to the different tiers and checking the outcomes.

Note a few points:

   1. I placed 6 total calls, so you cannot simply add up the calls
   presented column to arrive at 6
   2. Only tier1 has any handled calls
   3. tier2 and tier3 have their calls handled by other column > 0


[image: Inline image 3]

Lastly, if someone were to say: "Yeah, but Anthony, seeing the calls
presented column for the overflow queues shows us how many callers are
making it that far in the queue, and that's valuable information."

I would agree, but then challenge them and ask "Do you know how many CSQs
your system is allowed to have?"  It's 35 CSQs for the 100 Agent OVA.
Granted, it shoots to 250 for the 300 and 400 (nice sliding scale there
Cisco), but the point is, there is a resource constraint, and you cannot
scale this solution of using dummy/shell CSQs simply for collecting metrics
which are otherwise already in the reports (E.g., callers hold time).  I've
seen people do that for collecting menu choices as well.

So, with all of that said, what you'll likely need to do is, go back to
them and ask "What are you current challenges?" or "What are you trying to
achieve by using overflow queues?"  You might just find that they need
something entirely different, and you can avoid the nested queuing
altogether.


On Thu, Sep 8, 2016 at 2:11 PM, Max Harmony <bmaxim88 at gmail.com> wrote:

> I have a customer that is requesting to have a main Queue, and two
>> overflow queues, and they intend to have the same agents in all three
>> queues with the same skills. I am not very confortable with the user
>> experience but can anyone advice on what would be the best recommendation
>> for this situation?
>
>
> Please see below logic
> Caller --- goes to Queue A---35secs delay --->redirected to
> OverflowQueueAOverflow--5MinutesDelay--->Redirected to
> QueueAGeneralOverflow--5MinitesDelay------
>
>>
>
>
>
>
> --
> --
> Grace Maximuangu
>
> CloudPOP/InvictaCloud
> www.cloudpop.com
>
>  *“Go beyond your limits, push yourself, be the best you can be.*
> *Experience new cultures, broaden your horizons, stay connected.”*
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160908/6540ca2a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 25558 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160908/6540ca2a/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14733 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160908/6540ca2a/attachment-0001.png>