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?