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

[Erick Wellnitz]

I agree with this sentiment.  Nesting CSQs is not only subject to resource
limitations, it can become quite confusing to figure out if you haven't
looked at the configuration in some time.

If you do end up having to nest CSQs, document, document, document.


On Sep 8, 2016 5:28 PM, "Anthony Holloway" <avholloway+cisco-voip at gmail.com>
wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/37655d6d/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/37655d6d/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/37655d6d/attachment-0001.png>