Priority depending Interaction Type

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:

[ol]- In routing is one voice interaction and one email interaction. The email interaction is in routing for longer time

• Each interaction type is routed through another RP,VQ and targeted on another VG
• 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
• Both interactions are waiting in different VQs
• Agent change his status on both channel from NotReady to Ready (=> WaitForNextCall)
• URS with statserver “cooperation” check current waiting interactions and “compare” with agent state and capacity rule (when used)
• 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)
• 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[/ol]

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

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.

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

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

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).

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

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