[cisco-voip] UCCX8 Standard: 2 CSQs with same resources

Anthony Holloway avholloway+cisco-voip at gmail.com
Tue Mar 22 12:55:39 EDT 2011


No, it will not crush the server.  In fact, a 1 second delay is sufficient
for not spiking the CPU.  This is from gut feel and experience.  There is no
official way to measure the load on the server that your scripts are
imposing.

Actually, there is a limit of 1000 steps per application anyway, so with
your 5 second setup you can expect it to loop roughly for:

(((1000 - 50 misc. steps) / 5 steps to create the loop) * 5 seconds per
loop) / 60 seconds = 15 minutes

Or with a 1 second delay it will loop: 3 minutes.

You could increase the 1000 step to a higher value, but please do not do it
unless you understand why it says "do not modify" on the page.

If you did increase it, you could go with 5000 steps, and then your 1 second
delay would become a 15 minute window.

Anthony

On Tue, Mar 22, 2011 at 10:28 AM, Anthony Kouloglou <akoul at dataways.gr>wrote:

>  Ok, so if i set the delay between hold and unhold to a low value, lets say
> 5secs, is there a problem for the system? (25 seat license)
> Will it crush or something like this.
> Because, 5 seconds delay i guess reduces the possibility for unfairiness!!
>
>
> On 22/3/2011 17:24, Anthony Holloway wrote:
>
> Yes, unfortunately you are asking for something impossible.  You are trying
> to defeat the FIFO distribution of contacts, which is a hard set feature of
> UCCX and cannot be changed.  I'd offer a solution that breaks reporting, but
> is easier to manage scripting wise, however, you cannot use priorities in
> Standard.
>
>  Anthony
>
> On Tue, Mar 22, 2011 at 10:10 AM, Anthony Kouloglou <akoul at dataways.gr>wrote:
>
>>  Hi Anthony,
>> yes, that helps a lot.
>> I have already used a call hold-delay-15-call unhold, but as far as i can
>> understand:
>> callers that want to enter the sales queue do not have any guarantee that
>> they will even enter the queue.
>> I mean, since there is a delay there, what happens if:
>> there is caller one how wants sales and is in the delay step while on hold
>> for the 15 secs and a second caller who wants sales also calls.
>> I think that the second will enter the queue immediately if there is an
>> agent available.
>> Theoretically, caller-1 may never enter the queue !
>> Am i asking  for something impossible?
>>
>> Best Regards
>>  Anthony
>>
>>
>> On 22/3/2011 17:02, Anthony Holloway wrote:
>>
>> First, don't use AgentReady==1, use AgentReady>=1, this way, it'll work if
>> you have 2 or more Agents Ready also.  ;)
>>
>>  Second, either use the Play Prompt step in between your checks, or use
>> the Place Call Hold step early on, to play music to the caller.
>>
>>  Does that help?
>>
>>  Anthony
>>
>> On Tue, Mar 22, 2011 at 8:16 AM, Anthony Kouloglou <akoul at dataways.gr>wrote:
>>
>>>  Anthony thanks,
>>> i am already a lot of steps ahead!!
>>> It started working fine. (i am sure some refinements are needed!!)
>>> Look what i did.
>>> 1.right before sales queue i used:
>>> a *"Get reporting statistic"* with parameters:
>>>     Report Object: CSQ IPCCExpress
>>>     Field           : Ready Resources
>>>     Row id: CSQ_support (the name of my CSQ with absolute priority)
>>>     Result Statistic : AgentReady (an integer variable)
>>> 2. next i used an if (AgentReady==1) then
>>>         true -> go to select resource for Agent Ready
>>>         false-> delay 5 secs and then go again to get reposrting
>>> statistic.
>>>
>>> Suppose i don't mind if the sales queue is starved;
>>> How can i make the callers hear music while they are in the false exit of
>>> the "if"?
>>>
>>> Best Regards
>>>  Anthony
>>>
>>>
>>> On 22/3/2011 14:04, Anthony Holloway wrote:
>>>
>>> Anthony,
>>>
>>>  First, I want you to know, it's not because of your Standard licensing
>>> that is causing the CSQ's to be FIFO; it's FIFO in all license models.
>>>  Getting around FIFO is something a lot of people try to accomplish.
>>>
>>>  Second,  the solution is a scripting trick, not a UCCX admin config.
>>>  Priorities wont work for you, because you are not queuing callers in both
>>> CSQ's at the same time.  What you need is a check in the Sales script logic,
>>> that does not actually do a "Select Resource" until there are Ready Agents
>>> to service the caller.
>>>
>>>  How do you do that?  Well, it's a bit of a pseudo queue.  You create a
>>> queue loop prior to the Select Resource step, and inside of it, you are
>>> checking an ACD statistic for Ready Agents in the Sales CSQ.  If this value
>>> is less than 1, then keep looping, else, Select Resource.
>>>
>>>  You are basically operating on the premise that: for as long as there
>>> are callers queued in the Support CSQ, your Agents couldn't be Ready.  So as
>>> soon as you have Ready Agents, this is your signal that it's okay to queue
>>> to Sales for the same group of Agents.
>>>
>>>  Be careful though.  There is a reason it's FIFO and you cannot change
>>> that.  You will run the risk of starving the Sales CSQ with a steady flow of
>>> Support calls throughout the day.  One way to mitigate this starvation is to
>>> add logic to your Sales script that injects callers into the Sales CSQ at
>>> certain intervals: either by time, or by callers currently queued in
>>> Support.
>>>
>>>  Make sense?  You have a challenge ahead of you.  Good luck!
>>>
>>>  Anthony
>>>
>>> On Tue, Mar 22, 2011 at 2:39 AM, Anthony Kouloglou <akoul at dataways.gr>wrote:
>>>
>>>>  Hi all, i have a question regarding a UCCX installation Standard.
>>>> I have 2 CSQs (sales and support) with the same resources (agents are
>>>> the same) but with different skills (each is skilled with 10 in support and
>>>> something less in sales).
>>>> I guess, since it is standard version, each CSQ is FIFO.
>>>> How can i make my config (of skills ?) so the support CSQ is always
>>>> served first?
>>>> I don't care if sales have to wait for all support calls to end.
>>>>
>>>> Kind Regards
>>>>  Anthony
>>>>
>>>> _______________________________________________
>>>> 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/20110322/7fdb3bf5/attachment.html>


More information about the cisco-voip mailing list