Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: Anthony on January 01, 1970, 12:00:00 AM
-
Our customers inbound calls arrives mostly at a PBX route point which has a script that routes the calls to an available agent in our call center.
But if a customer call arrives at our PBX atendant console and we want to transfer the call to a route point (in order for the call to be handle by my routing strategy), TServer is not receiving the event messages and the agent's extension get stuck in inbound call status. Also if the call is transfer to an ACD Queue the call is not account for in the Genesys canned Queue reports.
Genesys support explained that PBX's attendant consoles are nonAST DNs and TServer does not deal with them, causing call status and report problems.
Has anyone run into these issue with Nortel Meridian and Genesys 6.1?
How do you deal with these calls if you want to transfer them from the attendant console to the call center DNs, and avoid telling the customer to dial the call center number?
Thanks,
Anthony
-
I'm not certain what you mean by 'attendant consloe' but I do know that in our call centre (Meridian ver. 23 and Geneys 6.1 and 6.5) we get issues like this when the AST settings on a handset are incorrect. This is the usual cause so I'd get your PBX guys to confirm the settings are correct.
I'd also check that all components RP, DN, PosID are set up in CME and there is a place group for the console.
-
What is "PBX attendant console"?
-
It is equipment for secretary, telehone is card in the computer.
-
Anthony,
This is correct we see the same issues with nonAST handling. Anytime a call is transferred from NonAST to AST it loses all Genesys routing controls and is default routed. Supposedly Genesys has a fix in the latest TServer for Symposium release. Anyone out there had this problem fixed?
-
Yes I had the problem on customers getting to the console and becaue the call is transferred from the console agents were locking up. I know this may sound dumb but to resolve we programmed a 2008 AST enbaled phone that the console operator transfers the customer to first and then transfers from there to the CDN (route point). This will not lock up the agents.
-
We have the same issue with calls getting in the 'stuck' state and we have traced it back to the consoles as well. We have though about putting a speed dial on the 2250 attendant consoles and send the call out to come back on a DID pointed to the application. We have 5 2250 consoles and replacing these with 3904 or 2008's to fix Nortels issue seems ridiculous. Anyone else have any ideas on a better way to fix this issue than the console to AST enabled to application fix. With high call volume this will ruin our ROI.
-
We did not replace the 2250 just programmed a seperate 2008 AST enabled phone and do a double transfer. Transfer the call from the console to the AST enabled phone, and then use that phone to transfer to a route point in Genesys. This has resolved the issue of agents being locked up because Tserver assigns a unique call id and Stat server can disconnect the call id.
-
We have our attendant transfer the calls to the actual phone number associated with the CDN, rather than to the CDN itself. That way, Genesys sees the call like any other coming in from the network.
-
We have experienced the same sort of symptoms both transferring calls from our attendant console (Nortel's PC CONSOLE) to a CDN controled by Genesys, as well any calls which first interact with our CALL PILOT environment for a menu option before being transferred to Genesys for Routing.
What we found is that the calls coming through the PC CONSOLE or CALL PILOT were not always releasing their control of the call before Genesys would try to route the call. Most of the problem calls from CALL PILOT were found to be calls that were being attributed still as "Consult" calls rather then "inbound" calls, because of the fact that the Nortel still had not released the call properly even though it had already arrived on the CND. The result would be that these calls would drop through to our underlying ACD queue because Genesys was not able instruct the switch on what to do with the call before it was too late. We were actually able to find examples of calls that did get routed correctly of the Call Type actually changing from "Consult" to "Inbound" if we delayed the Genesys routing until the Call Type changed so it was no longer a "Consult" Call.
So the was we have things set up currently is that we actually send our calls initially to a preliminary CDN which only checks the CALL TYPE before transferring the call the primary CDN which will route the call to the appropriate skills set. If the Call Type is a "Consult" call we hold the call for 1 second and then check again to see if the call type has changes to "Inbound". At the same time we have also configured this preliminary CDN to use the Primary CDN as it's default, rather then an ACD queue. The result being is that any call which might get dropped, even if we do delay the call, will still get transferred by the switch to the Primary CDN. The result being that we no longer get reports of calls being dropped from either the PC CONSOLE or CALL PILOT.
Our next idea will be to not even try and route the call from the Preliminary CDN, but rather to just unload the strategy which pauses the cal on this preliminary CDN and just let that switch transfer the call to it's default DN (which is set as the primary CDN we want the call to go to anyway). That way we think that the Nortel switch itself might complete a clean transfer from the PC CONSOLE to the Primary CDN (through the preliminary CDN's default) without the PC CONSOLE still having control of the call when Genesys tries to route the call itself. To date however I have not tried this, as things seem to be working the way we have them, it's just a little messy right now as I need to maintain twice as many routing scripts and CDNs.
In the case of your customerfs environment, is the ACD Queue that the call arrives at set in the switch as the default DN of the CDN? If this is the case I suspect that your problem may be similar to our issue. You may want to try and delay the call to in some way (such as what we have done) to allow the attendant console time to release control of the call.