Priority depending Interaction Type

[terry]

Not sure about exact meaning of "priority applies for the RP".
For URS priority is property of call (that can be set/changed anytime by strategy processing the call).
startegy processed vioce calls can Call Priority[100] ans startegy processing emails can call priority[10], if startegy process both types of call then media type of call can be checked in strategy.

In any case I believe only available options (after compeeting calls "presdented" to URS) are:
- use priorityies
- use service obejctive
- use thresholds - condition imposed on URS' queues (aka target selection objects) -
        like placing voice call in one queue, emails in another and impose condtion on second queue -
        do not route untill there is at least one call in first queue.
        This last approach is quite complex, also can require complex statistics.
        (first 2 approaches are much easiier)


   

[cavagnaro]

From Genesys support:

[quote]
However, if no capacity rule specified for Person, Place, and Tenant object, the Default Capacity Rule <system default> always displays 0 as a maximum number of interaction for any media, except voice
[/quote]

That means you are not declaring Capacity rules actually and let by default Statserver to use the ones created on CME without including Voice...not very nice from my point of view.
Why not create a Capacity Rule with Voice and Chat, Voice Email, Voice email chat and let them be 1 on all of them?


Edit: Check case 000037293

[terry]

Might be wrong but up to my knowledge out-of-box capacity rule "Default_One_interaction_of_any_type_only" already has right defintrion- you probably need just to configure tenant with this rule and thats it.

[cavagnaro]

[quote author=terry link=topic=8071.msg35573#msg35573 date=1383931324]
Not sure about exact meaning of "priority applies for the RP".
For URS priority is property of call (that can be set/changed anytime by strategy processing the call).
startegy processed vioce calls can Call Priority[100] ans startegy processing emails can call priority[10], if startegy process both types of call then media type of call can be checked in strategy.

In any case I believe only available options (after compeeting calls "presdented" to URS) are:
- use priorityies
- use service obejctive
- use thresholds - condition imposed on URS' queues (aka target selection objects) -
        like placing voice call in one queue, emails in another and impose condtion on second queue -
        do not route untill there is at least one call in first queue.
        This last approach is quite complex, also can require complex statistics.
        (first 2 approaches are much easiier)


 
[/quote]

Hey terry,
Well I do know we can upload a Voice strategy on a email logic but would that make sense?

I mean, even if same strategy is attached to different RPs and Virtual ones on Multimedia interactions, do you mean a priority applied to a Routing Point X will also reflect on another Routing with same strategy loaded on a Routing Point Y?
I always considered that each interaction was independent about on which RP it was loaded. Of course you have stats that can be applied to get a global view but my priority applied on RP X wouldn't matter to the RP applied on Y.

If so I'd like to understand that much better as would be something very new to me...never saw on URS Genesys logs something that would indicate such behavior...if you can expand your explanation that would be great.

Thanks!

[terry]

Sorry, a bit confused, may be I put it wrong.
All calls/interactions of course are independent (doesn't matter are they on same RP or not, do they run the same strategy or not).
Just under applying priority I mean calling in strategy function Priority[] which will affect only call that execute this function.
I meant that if startegies for voice calls somewhere at the beginning execute Priority[20] - every vocie call going through it will starts from priority 20. if strategirs for emails has somewhere at the beginning
Priority[10] - just the same all emails has priority 10.
In such case when agent is waited by both voice and email and becomes ready then voice call will always be selected.

If strategies already use priorities for something then probableyranges of priorities can be allocated to different medias (emails operate in range 1-100, voice in range 101-200) etc so voice calls will always be prefereble over emails calls when some agent become ready.
 

[Kubig]

From my point of view in standard deployment -> one common pair URS + StatServer for voice and eServices layer -> the voice interactions always have priority over other interaction types in routing, because voice interactions are "real-time" and must be delivered as "first". Just for imagine:

[list type=decimal]
[li]In routing is one voice interaction and one email interaction. The email interaction is in routing for longer time[/li]
[li]Each interaction type is routed through another RP,VQ and targeted on another VG[/li]
[li]Your agent belong to both VG. Does not matter if though his skills or linked to VG directly. And the agent is not ready for both channel[/li]
[li]Both interactions are waiting in different VQs[/li]
[li]Agent change his status on both channel from NotReady to Ready (=> WaitForNextCall)[/li]
[li]URS with statserver "cooperation" check current waiting interactions and "compare" with agent state and capacity rule (when used)[/li]
[li]If the agent "meets" conditions for both interaction. URS will preferred the voice interaction before email, block the agent for another routing and routes to him (EventRouteUsed -> EventDiverted)[/li]
[li]If your capacity rule allows combination of voice + anything others - the email which was waiting in routing is routed to the agent in a short time after voice. If the agent status is still ready for that media of course[/li]
[/list]

I mean just nothing to do here if your deployment is properly

[terry]

I'm afraid it is not exactly so - all medias are the same for URS (there is no "built-in" prioritization based on medias or whatever else for that matter, except waiting time of calls - longer waiting calls tends to be ahead in queues comapred to calls waiting less).
Strategies should give explicit instructions (through prioroty, service objective, etc) to make URS put calls of one media ahead of call of other media.

[Kubig]

My tests in my lab show and confirm my opinion, but may be I am wrong. Just describe how it works in real :-)

[cavagnaro]

URS seems to check Multimedia Interactions based on some timer, not as voice which if going to run on a race is already on the set, ready position waiting for the go. You can test this by having an email on queue, set an agent on ready and the email doesn't appear immediately. As if you test voice it is send as soon as see the agent Ready. If you put one-one interaction you will always see voice arrives first.

Now, of course, the scenario we are talking is if the agent, place or tenant has that capacity rule of "Only one of any type" configured as gzooby suggested he has. Otherwise, he has N channels being N the amount of media types configured on the capacity rule.

Reading Capacity Rules guide and some URS options, seems voice is always prioritized by default.
We can seem to be able to change that rules by creating some functions on the strategy by checking agents states, but never a voice priority will affect a email priority for example, just because each interaction has a property which controls that, "media type".
What capacity rules can do with the Capacity Rule Editor (not the wizard to create Capacity Rules) is to be more flexible and if for example agent has 1 voice call, then no other multimedia, but if he has 1 email only then you can send 3 more emails and 1 chat, if 1 chat then send voice too...
I actually never read before this feature, which seems very very interesting and of course, such routing as not as simple as voice standard (default by URS) will add more complexity to the strategies and design of the overall functionality. No out-of-the-box solution.

So I don't see priorities being a part of this solution.
Service Objective neither because again it works for a media type only, not a global one, because URS focus on interactions, not the agent side exactly, it see something ready  for distribution of an interactioin, bam! send it! (bam! on multimedia not very bam!...)

I'm loving this post because is making me read a lot and investigate, even find some contradictory states on the Genesys documentation about this stuff.
Of course, best way will be now to do some lab tests as never used such rule of 1 type only...for me seems a waste of time and resources. An agent can handle an email and if voice comes, let him get it, he can work the email later as is much much passive interaction. Chat goes on second place after Voice, as you have a person behind but we are Ok if chat takes a few seconds to be answered, if we receive a please wait, we wait...not as in voice, where we want to spit it all now...human nature....

So now will do the techy part Will see how this goes on the BY DEFAULT method

Terry I'd love also to see some logs on your side backing your ideas which also sound pretty interesting but again I have no evidence nor documentation to back them... :-/ We do know not everything is documented and many things need tests to make it work with specific configuration and strategies. So would be so cool you could show us how to do so.

Thanks guys for this post which started as a simple question

[terry]

Then such test (how URS works with media by default) probably supposed to look like this.

- simple strategy (the same for voice and email) from one object which just try to send call to some agent and wait few minutes if no agents happen to be ready.

- Set URS option verification_time to few seconds (agent readines can be reported
by statserver not in one but few events like ready for vocie immediately followed with ready for email,
and in such case the media reported as ready first will be selected if URS rirectly react on every event). This option allows URS to absorb few agent readiness/not readiness events before reacting on them.

- make email call and see in URS log that email was submitted to URS.

- about 10-20 seconds later make voice call, and again see in URS log that he has this call.

- make agent ready (for both voice and email). Basically email call (as waiting longer) will be selected first.

When URS checks agent and if according to information that URS has at THIS VERY moment more then one waiting calls CAN BE ROUTED to this agent then call will be selected based on following (I don't have logs confirming it right now, may be I'll can get them later, but can put my head() that it is really so - if not it will be considered as defect and fixed ASAP):
- calls with higher prioority will be selected.
- if still there are more then one call (= all of them have same priority) waiting time of competing calls is considered. It can be just plain time calls are waiting or in case of using service objectives compared values are waiting_time/service_objective. This values are counted with milisecond precisson.
- if still there are more then one calls (= values calcualted on previous step are the same up to miliseconds) then call who starts wait the agent first will be selected (there is counter increasing every time some call begins to wait some target, and call with smaller value of this counter will be selected).

When considereing some agent URS prints in log ordered list of calls waiting him (calls will be tried exactly in this order). If URS option default/verbose is 6 then in this list will be provided extra information (in brackets) explaing why every call has position that he has (priority, waiting time, service objective, prediction, etc).
       

[cavagnaro]

Hey terry,
Yeah sounds reasonable here*. Where I have my doubts yet is the inverse scenario, where the voice arrived first and then you want the email to be routed first even if arrived later. Again, only lab tests and logs will confirm

* For my knowledge IXN always does a loop on queued emails as they are not alive on IXN like voice on Voice TServer. They are stored on a DB. So each cycle it goes, retrieves and try to route...so your scenario would have to be very synchronized. Again here, tests will say what happens exactly.

Cheers!

gzooby just hope you didn't get scared by this lol

[gzooby]

Not at all...
I´m happy that my simple question generated such discussion!
Thank you all for your time!