Well here is a loaded question for someone to try to summarize for me. We are implementing Genesys with Nortel M1 Symposium 3.0 and we will be doing a lot of skill based routing based on the customer’s requirements. Question is if we use the secondary DNs as the targets on the agents phones vs the queues we will lose any real ACD functionality in the switch and of course failure of Genesys could have real BIG impacts on the Call Centre. So has any one implemented skillased routing on the Nortel M1 by programming the agents with their own selfcontained queues or even mix of both. I would like to hear what obstacles you had to overcome and what NOT TO DO from your experience in implementing Skillased routing on the Nortel M1?
The best approach I can suggest would be having agents login into a particular ACD Queues, and use IR’s skillased routing.
You will need to plan how exactly you would want your calls to be distributed in case of IR failure, and then design the system accordingly.
Most of the call centers I can think of use both IR skillased routing and ACD Queue login, since one thing does not interfere with the other. I would suggest that you would do the same.
With best regards,
S.
Does Symposium allow you to do routing as well?
It might be tedious, but why not have agents defined both in Symposium AND Genesys? This way, you would still be able to use both of the features, without worrying about TServer crash and its aftereffects.
Tick, tick, tick!
Jeff
In the Nortel environment you can not target the actual positionid for the agent in the Queue (Acd DN key 00) so unless I make each agent have their own queue I have to target their secondary DN key instead because I can only send the call through Genesys to the ACD Queue. Now I could write some (symposium) CCR scripts as well but then if I attach IR strategies to the same CDNs that will cause problems.
If I use the secondary DNs then I am relying on Genesys to not fail. And at this stage of the project I cannot predict the customer’s skillased requirements. So, if I create physical queues and stick agents in them I basically have calls going both directions the queue and secondary dn. Need to monitor both dns so that I don’t end up with two calls ringing at the same time on the agent’s set. I know rel 26 (next year) will fix this issue and allow Genesys target actual positionids in the queue. So I would like to set up agent queues on 11 basis with the agent so it looks more like places in the Genesys world. Then when release 26 shows up I can add more agents to the queue and actually target their positions. But for now the key issue is can a CDN target more than one Queue at a time without CCR? I could look at the MQA option as well. So any experience in this matter would be greatly appreciated.
Routing to the ACD Key would be the dream. You mention you think it is in Rls 26. Have you heard this from Nortel or only a rumor. (I don’t want to get too excited if its only a rumor).
One other concern when you start routing to the secondary DN you loose forced answer. The agents don’t get the beep in their headset.
By routing to the secondary dn of the set you basically losing all the ACD functionality in the Nortel switch which the customer has paid for. So it’s like setting up two routing solutions one when Genesys CTI is operational and another as a backup when it fails. In regards to Nortel Rel. 26 I heard it will be out in Q2 of 2001 but this is not official. Maybe you can verify that with Nortel?
Richard,
I do not think you would have to monitor both DNs, because if you will be using skillased routing, calls will only be arriving on the extension queues are used as an emergency backup, in case Genesys fails.
I know if I use Genesy and just target the secondary dns that will work but if I need to do holdinqueue and or send to a group voicemail box that seems to complicate things and means that more customization through softphone and strategies to do that. Plus by targetting the secondary dn you are circumventing around any ACD capabilities of the switch except for backup when genesys fails.
One of the requirements is to provide minimal routing capabilites at the switch level just in case Genesys does fail.
If you are going to consider each agent having their own queue, the only limitation to this is the number of ACD queues allowed in the M1 environment.(don’t remember the exact number but do recall it is not very big…maybe 99?) Also if you do not have MQA, you loose the ability to have backup since all each agent is in a seperate queue. With MQA the agent could be logged into his/her own queue and a centralized queue for backup purposes. The only caveat here is that you cannot log into multiple queues via RequestAgentLogin from Genesys However if you use the hardphone to login to both queues the first time, subsequent logins from Genesys will get you logged in to both queues. This could be sticky if the agents move around often.
Hope this helps.
We are using the Genesys skills to route calls and setting up ACD queues on the PBX as a backup in case Genesys were to fail. Basically, we defined the groups that our agents are in by skills and agent groups in CME and mirrored that in the PBX. Each CDN, which corresponds to a route point in Genesys has a default DN which is the ACD queue for that group. If a call comes in to that CDN and Genesys does not respond, the PBX will route the call to that CDN’s default DN…so the call will end up going to the same “Agent Group” it would have if Genesys had been able to route the call.
Sorry to reopen an old thread, however, is anyone aware of new releases from Nortel which will support functionality discussed. I know Agent logon to Genesys from hardphone works now but what about routing to positionid?
I have the scenario where I do not want to rollout desktop applications to all call centre staff, only those requiring extra functionality which it will provide. But those without still need to be in the routing plan. All agents require callforce which as far as I can see will only operate with the position not the DN.
Being that Symposium can do this suggests that the functionality is there but possibly not open to Genesys. A note in this thread suggested that M1 rls26 might fix. Don’t really wnat to set up a Q for every agent either.
Any thoughts/updates?
Rory
Appearently Rls 25.4 will allow you to route to the ACD postion key and will increase the number of resourses ACDN/CDNS as per our Bell rep.
Joel,
are you sure about it? Also, when will Rls 25.4 be available?
I have asked our suppliers to confirm this with Nortel. Would be ideal as we are planning to go to rls 25.4. I’ll update if I can get a definitive answer.
Rory
Vic,
From what I hear, rls 25.4 should be available from Macrh.
Rory
I was given a March date as well (more realistic was April) from my supplier as well. Sorry for the tardiness I haven’t been to the board in a while.
Has anyone tested it yet?
I think this would be an ideal thing for Meridian, because then NACD and IR would be routing to the same DN, preventing calls from arriving to agent on both ACD position and IR at the same time ( this happens when IR drops a call to default, which is then arrives at agent’s ACD position. the problem with it is that, IR does not know that the agent received a call on ACD position, and so it still sees the agent as ready, thus routing it a next call it has in a queue. As you can imagine, this results in both calls ringing on the same phone, driving agent and everyone else nuts)
By the way, is there a way to handle this kind of problem without assigning only a particular agent to an ACD overflow?
Vic
Unfortunately the feature being available in the switch software release doesn’t help. The M1 is able to route calls to the position today - just not over Meridian Link. It may be possible in an upcoming release of Symposium Link (SCCS 4.x?), but no matter what switch release comes out, until the CTI link supports it, Genesys won’t be able to get calls routed to the Position ID.
Dave,
Just a thought, but if (big IF) Symposium MLS 4.? does eventually expose the requried functionality to allow routing to a position ID then will Genesys be able to do it or will further devcelopment work be required by Genesys to utilise the exposed functionality?
Rory
I can assure you that if Nortel ever exposes the ability to route calls to the PositionID through the link, Genesys will move very quickly to support it. It likely would require a maintenance release, as there has been no way to design the TServer to support the capability since the capability didn’t exist.
One more reason for Nortel customers to push feature requests through Nortel to get it exposed… 