Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: Richard on January 01, 1970, 12:00:00 AM
-
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... :)
-
I was really hoping to use this function... It would solve a myriad of problems we currently have (calls arriving on both ACD Position and Extension at the same time being one of them).
Vic
-
We'd all love to have this feature available. Unfortunately Nortel has seen this as a way to keep one feature only available within Symposium, even though the rest of it doesn't work very well. The more we push, the better chance we'll have of seeing it available some day.
As for calls arriving on both the PosID and Extension, the only way this should happen is if you're either routing calls using router AND the ACD (in which case the ACD goes to the PosID, and router goes to the Extension), or you're routing some calls in router to the queue and some to the agent. While there is visibility into the ready state of the Position ID, the queue cannot see if an extension is active fast enough to avoid sending a call to the position ID while router is sending one to the extension. The best way around this is to not route to queues (use virtual queues or agent groups instead for this purpose) and let router do all routing, as it can ensure an agent is available before delivering calls.
-
The reason for a call arriving on ACD usually is because it was defaulted by IR or IVR... We have about one per 10,000 calls or so happening all the time. I think this is an IVR problem; however, I cannot really trace it down to anything in partiular calls just are transferred from IVR to a CCR, and then suddenly, I see this call on NACD, which is defined as a default acd for all CDN :(
Does anyone else have a similar problem?
Vic
-
Having met with Nortel, they don't see opening up the required functionality as part of the current roadmap for Symposium MLS. Also they pointed out that the functionality such as call force could eaily be built into TServer by Genesys if they really wanted to!
-
This is, unfortunately, inaccurate. If there were a technical way to force calls to the Position ID rather than the extension without opening up the link API, Genesys would have done this long ago. There is no question that Genesys "really wanted to", as you say. The issue is that there is simply no technical way to route the call to the Position ID without going through the ACD, for which a separate queue would be required for each agent. Nortel does have an API for this, but they will not open it up to other vendors.
If you can get your Nortel person to explain just how this would be possible for Genesys to do without the API or using individual ACD queues, I'd be very, very interested, and could likely assure some form of results in terms of making it happen. I'm inclined to believe, however, that the Nortel person didn't quite know what they were talking about.
-
Dave,
Misunderstanding, I don't think Nortel meant Genesys could route to Position ID, what they meant was that some ACD functionality could be built into Genesys. i.e. have a setting on an agent or skill that would allow a time for call force to be entered and then automatically send an answer command on eventringing for that agent.
Rory
-
I guess I still don't understand the concept. Genesys does have the ability to essentially act as an ACD - using agent groups, virtual groups, and several other methods. It's the "call force/answer command" concept I'm not clear on. Can you give me an example of a call flow to describe what you mean?
-
Dave,
BY Call Force I mean that when a call is delivered to a phone the call is automatically answered without the need or the agent to do anything. ie. they get a beep in the headset and thats them connected.
As we currently don't have any CRM type app implemented I was wanting to implement Genesys transparently for the user with no desktop app to begin with. With no Call Force (ie. auto answer) a change to the centres working would be required and hence no transparent implementation.
Rory
-
Now I understand. :)
If you don't want to do this with a desktop application at each computer, why not use a server application to do it? Write a simple application that registers all of the DNs, and on EventRinging sents a TAnswerCall with the appropriate extension.
This doesn't really relate back to the whole Position ID thing though - while you're correct that Genesys could probably implement this EventRinging/AnswerCall functionality internally to its own software, it doesn't sound like a commonly requested feature - most switches, including the Meridian, can do autoanswer by themselves. If it's important, though, submit a feature request through Genesys tech support. You never know! :)
-
Currently my company is also looking at using Genesys to replace the exisiting CCR & ACD MAX from "Nortel Solution".
However, I notice that Genesys might not be that invisible. There are still loop holes. If the TServer is out of action, all the Call Center reporting will be lost. Also, Genesys does not provide a real "Cradle to Grave" reporting as most believe e.g they still needs a routing point or CDN from the Nortel Switch.Also if the TServer is down, I suspect that all the calls will be ringing in the air or in my case IVRS.This is so since PABX does not do the default routing anymore. It is suppose to be replace my Genesys whichwe have to monitor whether it works fine.
From my personal view, I would prefer a combination of both Nortel CCR/ MAX & Genesys (do not put all your eggs in a basket). In this case even when the TServer is out of action. The basic reporting can be capture in the ACD MAX & call can be routed to default Q as per desires.Symposium or CCR should always be the front end "traffic controller" before passing the call to Genesys for further Call Treatment & Customisation.
-
Johnny,
We are looking at a similar scenario as you may have guessed from previous postings. The default routing question is covered as the Meridian will do this as part of the core ACD functionality of the switch, such that even if Genesys is controlling the routing and fails, then the Meridian will see the timeout for a routing command and then route to the default.
Genesys will not be invisible to the agent, and on the basis of discussion here, is unlikely to be invisible in the short to medium future. The only invisible solution to CCR, LINK, MAX going out of support is to go to Symposium.
Rory
-
Call forcing can be done from Genesys with the implementation of a softphone application. Ask Genesys to show you a site where they have this working.
Beware of skill based routing if calls cannot be routed to the incalls key. write it out on paper. I cannot get into it here, but there is an issue if the Tserver crashes. you will have to have or overflow acd's ready on each agent. went down this route with genesys ps and it didn't wash.
-
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.
this doesn't work, because if you begin skill based routing, genesys will send calls to either DN you have on the key (not key 0, but any other subsequent DN keys" if you force calls they will disconnect active calls. I have seen this happen.
-
This is true. No matter what Nortel does with their release of software, Genesys is not routing the call to the ACD position. They are set up to route more in the Avaya environment, where phone extensions can be added to ACD groups, rather than phoneSETS programmed in ACD groups. This is a Genesys issue.
-
beware. Ask for references. Ask them to take you to a site that is working with a Nortel switch. See what they say. Then let us know if they show you a site. I would love to talk to them. If you are looking for a CTI application, use the Tserver, it works, but look out for any routing solutions, from Genesys, that they say work with Nortel.
-
More and more people seem to agree on this. The Genesys environment fails when taken beyond a screenpop... It is not an ACD, whether you ITgeeks like it or not.
-
Hi Vic,
So did u manage to solve the problem of calls going to position and extension at the same time. Actually we're running a G6.5 environment with MLink5b, but we're facing the problem of calls going to position even though we configured for calls going to extension only. Also we notice that it's not the PABX sending to the default route. If u faced the same problem, may be u can give us some views. or if anyone else faced a similar problem...
cheers
-
Hi Vic,
So did u manage to solve the problem of calls going to position and extension at the same time. Actually we're running a G6.5 environment with MLink5b, but we're facing the problem of calls going to position even though we configured for calls going to extension only. Also we notice that it's not the PABX sending to the default route. If u faced the same problem, may be u can give us some views. or if anyone else faced a similar problem...
cheers
-
Hi
Just to ask for some feedback.
I notice that there is an limitation on Nortel Mlink5B. The PBX will automatically pass the call to the default Q if Genesys takes more than 4Sec to process. Have check with Nortel & they claim that the 4 second timeout cannot be change..
Hope there is anyone out there that can provide me some info. thanks.
-
Johnson,
R u having the same problem as well with Genesys? i.e the 4 sec delay? did u manage to fix the problem or any workaround that can be done in Genesys?
-
Yup, it is the 4sec delay.
Now the Genesys Engineers is suggesting to us to go for Symposium link.Or even ask us to upgrade our Mlink5 to relase 3C. Beside the mentioned "suggestion" given by the Genesys Expert, they have no idea on where to move on..
-
Hi johnson,
Thank a lot .. Where u from ? //Anyway what would u suggest me to do ?
Regards
ahmad
-
There is a user above mentioned using CCR together with Genesys (not put all eggs into 1 basket). Can consider? Hope it help.