I have a question, and I wonder if somebody could help me a bit .
It is possible to log an agent into Genesys system using the physical phone to log them?
The fact is that yesterday our GIS server stopped workin, so our custom agent desktop was stopped also. The problem was that agents wanted to log into Genesys using the physical phone instead of our desktop application, is there any option to achieve that?
We are running under 7.1 Genesys version with an Avaya PBX.
I am one hundred percent sure that you could do it with Nortel.
I also remember that at my previous company, people were able to login into Genesys using hardphones.
AgentID and person ID would need to be the same. So, if you could log into the hardphone, Genesys would use agentID it receives from PBX to tie it with the person. So, yes, you can login into genesys using hardphone. I think you might need some PBX settings though.
Yes, itâs definitively possible on Avaya PBX by dialing the login feature access code (FAC). The easier way is to use programmable keys on the hard phones and assign login/ready/not ready/logout âfunctionsâ to the keys. Unfortunately I donât have step-by-step description how to configure the hard phones so I suggest you to contact your PBX guys. If necessary I can try to get the description for you but it takes me some time.
Exactly; but just a hint: I run some tests some time ago and with ASAI version 2 the agents were able to log into the switch this way but the switch did not pass this info (e.g. EventAgentLogin) to Tserver; so in this case Genesys was not aware and out of synch about agents state. Toni, you could try to run some tests with the new ASAI version 4.
Thanks for your hint. I didnât know about that. Maybe thatâs the reason why Genesys doesnât support ASAI version 2 and version 3 or 4 is required by TServer.
Iâll start searching how to configure the feature acces codes into the Avaya hardphones and Iâll try it.
I saw that when I tried to log in with the hardphones (the same way agents where doing before having Genesys) the T-Server log didnât show anything, so I suppose (as you said) that the PBX is not sending the EventAgentLogin to T-Server.
I was trying to do some test, and I could log me into the PBX with the hardphone, but the T-Server dindnât received any RequestAgentLogin or something from the PBX.
It only received a EventOnHook and EventReleased,but that was because when I introduced the login code into the hardphone gets OnHook and then when it logs into the PBX gets released.
May be am I introducing a incorrect feature access code? Iâm using *25 followed by the agentid
Please check the TServerâs option âquery-agent-work-modeâ which should be set to value âon-releaseâ. Another option I suggest you to check is âacd-register-modeâ which has to be set to the value corresponding to your switch configuration (see TServerâs documentation for details).
Yes Fra, youâre right. Iâll never get an RequestAgentLogin, if only I could receive an EventAgentLoginâŠit would be great!
I got that from the Genesys T-Server for Avaya document:
âCurrently, the PBX does not notify T-Server when the agent changes state
using the standard buttons on the physical phoneset. To ensure proper
agent synchronization, Genesys suggest using either a softphone for all
agent state changes, or feature access codes. In addition, the configuration
option query-agent-work-mode, with its value set to on-timer, can be used
to request agent states for all properly configured agents who are logged in
but who are not on calls. See âquery-agent-work-modeâ on page 202.â
As you said Fra, I used the query-agent-work-mode, and I set it on-timer with the deafult value of 3 sec. In the T-Server log I saw that all the querys made to the PBX where returned null⊠Iâll continue looking why but Iâll accept any of your marvelous comments ;).
Iâve check TServerâs log and there is no information about a login attempt :(. Itâs really strange as there are no information about dialling FAC code (*2566003) too. That info has to be in the log because TServer is monitoring the deviceâŠ
âŠyou have to set the ***-fac options in the TServer to tell TServer which FAC codes relate to which state change.
e.g. auto-in-fac=â*25â or whatever - this tells TServer what diallable number relates to which state change.
You also need to be monitoring the ACD Queue (Hunt Group/Skill Extension) that the agent is logging into - otherwise TServer will not see the login/out events for the ACD Queue.
BTW The TServer should âseeâ Login/out without FAC codes monitoring - it is only state changes (auto-in/manual-in/acw/aux) that are not signalled to ASAI clients. Therefore the ways to get Genesys to âseeâ agent state changes are:
on-timer - check every x seconds - not good for stat server agent state report accuracy (or router target selection accuracy!)
XX-fac - check all dialling events and associate dialling *23 with AUTO-IN - more accurate but off-hook/on-hook is not always great for agents who are on calls etc.
Seb hits the nail on the head (Thanks Seb) - you have to monitor ACD Queue (Hunt Group/Skill Extension) to receive agentsâ related events! I forgot that :(. Itâs a quite long time I worked with Avaya switchesâŠ
Just been looking at this problem last week and came to the same conclusions presented above.
Another potentially useful settings are âroute-thru-queueâ = âtrueâ. This means the call is treated as an ACD call so an agent is put into ACW immediately after a call.
Also âlogin-for-all-queuesâ = âfalseâ generates login messages for all the Hunt Groups an agent logs into which can be useful for troubleshooting or if you are using the Hunt Groups to gather reporting data. Once the agent has logged in you the normal message flow occurs.
One thing to watch out for is changing the query mode to âon-timerâ can cause problems depending on the size and volume of your call centre. The Avaya link can only handle 200-240 message per second so during a period of high call volume in a site with a large number of agents the link can become swamped and calls will default route.
.
, in your case EventAgentLogin.