Agent state change From strategy

[SisB]

Is there any way of changing agent [Avaya] state (Not Ready->Ready) from  routing strategy USING Agent Login Id or employee id? I know it can be done using extension dn with SendRequest but not sure if it is possible using agent id/person emp id.

The idea is to route a call to an agent who is not ready. The call has to be ACD routed thru queue call, not a forced/t routed call. So was thinking if I can make agent ready I can route it using selection block/SelectDN-SuspendForDN.

Thanks.

[cavagnaro]

I think you can use a Force or better a TRoute function, it will not take in account the state of the agent or the target at all.

[kowari]

You could probably do this using a macro, but I am not up on the details of macros.
Anyone else able to write an IRD macro to do this?

Otherwise you can write a custom server to do it for you.

[SisB]

Thanks guys for your response.

cavagnaro,

I can TRoute/Force the call to the target but the problem is the call is not routed through avaya queue and hence not considered as ACD call in PBX. So I loose several PBX features e.g. zip, tacw etc. etc.

kowari,

Yes, we use a similar macro for making agent not ready, but it requires the extension (dn). And Yes, custom server is always an option but wondering if possible to do this using IRD/URS functions.

[cavagnaro]

But if a call arrives to an agent that is on not ready state it will anyway will not be considered as a CC Call but a private call.

[kowari]

well, yes, you need the DN, so you need to translate that to an agent ID (or the other way around).
We generally get our softphones to log that information to a DB which we can then lookup in IRD.  You could try that?

[kowari]

[quote author=cavagnaro link=topic=4267.msg19022#msg19022 date=1244077218]
But if a call arrives to an agent that is on not ready state it will anyway will not be considered as a CC Call but a private call.

[/quote]

If you had agents in a state where they are not wanting to take general inbound calls (as they are doing some after call work or personal callbacks), but perhaps take escalations or priority customer calls I can see this situation becoming apparent.

SisB you would have to check in IRD that the agent state was good for routing though - not ready, and onhook.  There are definately IRD functions to do that.

[SisB]

Yes, that is exactly my requirement.

I've been trying out several functions for some time but nothing has worked out so far. Neither I can make agent ready using employee/agent id nor can translate employee/agent id to extension.

Appreciate your quick responses.

[cavagnaro]

Oh well that is different and understandable.
See the checkAgentState function:

[quote]
Return value type: VOID. This function instructs Router whether to take into account the state of an agent, place, group of agents, or group of places as reported by Stat Server, or to look only for free DNs belonging to the agent, place, or group.
[/quote]

Another one that has an example on G Support site:

UseAgentState

[SisB]

Thanks cav.

I tried using CheckAgentState/UseAgentState. Though never used these functions extensively, this is what I've gathered-

CheckAgentState-

This is useful while an agent is associated with multiple DNs or in other words having ability to handle multiple and different types interactions - e.g. one chat, one voice.

E.g. if an agent is handling a chat interaction, the agent will show as busy but the voice extension might still be free. In such cases, CheckAgentState=false will allow to route a voice interaction.

UseAgentState-

This will allow one to define custom stat types under URS Annex and use these while routing the call.

E.g. examplestat = ready[DN of type Chat]>0

so, when we use UseAgentState[examplestat] is satisfied, the interaction is good for routing.

None of these worked for me.

[Seb Reeve]

You can also use the SendRequest function in URS (same one used in Sample macros) to specifically request an Agent  DN to change state.

This is most often used to force an agent dn to not ready in a RONA situation - but you could also force to ready if you want...

Seb

[bogdan]

I think it is something like this, not really sure though: SendRequest[RequestAgentNotReady, AgentSomething]

[René]

[quote]You can also use the SendRequest function in URS (same one used in Sample macros) to specifically request an Agent  DN to change state.
This is most often used to force an agent dn to not ready in a RONA situation - but you could also force to ready if you want...[/quote]

Seb,

It doesn't work as URS issues the request on DN the strategy is executed on (=Routing Point). I didn't find a way how to "persuade" URS to issue the request on other DN.

It works in RONA situation as in that case strategy is executed on agent's DN (extension).

R.

[kubikle]

As far as I remeber SendRequest understands key thisdn in request body (as well as key tserver).
However URS need to registered on thisDN for this to work (Tserver will rejects requests on DNs the client is not registered at). And to make URS register on those DNs probably some playing with router's option event_arrive will be needed.

[bcyk]

yes... SendRequest() includes "agent mode" parameters for [u][b]registered DN in URS only[/b][/u]

In IRD strategy load screen, it should show all DNs monitored and controlled by URS; thus, registered DNs.

not sure if event_arrive is still applicable on regular DN type such as extension in 7.x version.
try to enable event_arrive option in extension DN and find the DN in "Strategly" Load session in IRS to confirm; if the DN cannot be found, the function may not work

------------------------------------------------------------------------
--------------- previous deployment using SendRequest[] ----------------
The technique was applied to line-side trunk ports for VTOs, mainly for error handling.
VTO DN type, by default, is "registered" in URS.

All VTO ports were special logged-in agents; URS strategy checks for ready VTO agents instead of "on-hook" event count.
Such set up extended exception error handling

1. If the line-side T1/E1 trunk was disconnected, all VTO agents would be logged out by switch
  - it (agent logout by switch) did not apply for analogue line circuit
2. If the server connected to T1/E1 card was powered on but VTO application was NOT active
  agent states stayed in what they were
  - in this case, switch-level NOA must be enabled and diverted the call to another RP strategy, say, let it be VTO-exception
  - the VTO-exception strategy was to change agent to not-ready via SendRequest; thus, to remove the port from VTO usage in URS strategy

Note: needed extra switch / Genesys agent licenses for all VTO ports
------------------------------------------------------------------------