Hi,
we are trying to handle a running outbound campaign and will need some help in understanding some points.
the campaign is run in Progressive on a SCS ver 7.
there is no CPD Server thus we have set several Treatments in the calling list. This was done assuming out Switch - Avaya S8720 has the capabilities to recognize fax, Am and so on and will forward the data to Genesys.
The first issue we have is that the calls are coming to operator while still on ringing and it’s up to the Agent to find what it is. What I can see/configure to handle this?
That is the main issue but still have a question:
we use a little strategy to route the Outbounds calls to GA ( VAG - skill based routing) in this it is mandatory to add a VQ? if not for statistical purposes this will be on any help?
For the first part there are settings on the PABX that you need to set in order for it to use call classification when making an outbound call, it allows you to set the actions to be undertaken when the PABX detects a particular call result. I am not an Avaya expert so I’m not sure of exactly what needs to be set up here, I just know the options exist.
In Genesys you need to set an option in the TServer “use_am_detection” - true or false, I believe this may default to false if you do not set it specifically.
As for the VQ question, a virtual queue is purely for statistics, if you do not wish to set a particular virtual queue then Genesys will assign it’s own internal VQ and use that, but you wont be able to get any queue statistics. I find it is better to always use a specific virtual queue, that way you have the option to report from it or not. But if you don’t have it to start with you don’t have the option.
It does have those capabilities by using call classifiers and a bunch of fine tuning - hassle .
What do you mean?
It depends on what you have configured both on the switch and on the Genesys side: you can decide if to put any call through or instead filter the non-human live calls.
Basically as Dionysis said VQs are used for reporting purposes, but they may become useful if you have a complex blended enviroment where your agent groups are targetted by several queues inbound and outbound traffic is distributed from: to help OCS calculate properly the rate it dials calls in predictive mode, you should add to your outbound groups origination DNs any DN calls drop off.
[/quote]
Marco di dove?
Dionysis:
got it on the PaBX settings. I thought that too. Will check the option on TServer.
Fra:
Ciao
SCS sorry … OCS Outbound Control Server 7.2
In regards to the Avaya PaBX you said: “It does have those capabilities by using call classifiers and a bunch of fine tuning - hassle .” -
I’m sure it has but the issue we have is that the 90% of the Outbound Calls come straight to the Agents. And this means that the Agents are receiving: Faxes, AM, Customers, simply a silence, sometimes the Agent just listen to the Ring and has to drop the call himself and so on. As you can immagine this is a big amount of wasted resources ContactCente wise as we are getting very few valid contacts.
well, but what have you set up on the switch and in Genesys? Are you using call classifiers? Did you turn it on? how did you tune the Avaya parameters? What about Genesys use_am_detection option and treatments? There is a ton of stuff to check..
Fra,
With respect to tuning etc, how is this done on an Avaya?
Is there any documentation you could point me towards to read up on this? Our PABX engineers have told me that it’s not possible. Also, do you know of a way to benchmark the AM detection accuracy? eg. can you record the classification portion of the call so that you can go back and listen to them to check accuracy?
You have to work on the pause and talk durations; these are used to classify a call as human or not-human, you can find them in the “sit-treatment”. You may also want to tune the DBs adjustment of the tone detection.
I’m not an Avaya engineer, but I don’t think it’s possible to benchmark the AM classification..
ciao
we asked to the Switch " Operator " to check the Avaya’s parameters and let us know.
Meanwhile have found that on TServer the option ‘use-am-detection’ was set as true.
Have also found a Genesys’s advice in regards the option ‘call_answer_type_recognition’. We had this set to ‘no_am_detection’ and since, with no CDP , it’s not used was set to default = ‘telephony_preset’.
ADDITION
after the above we started to have something working but come accross what seems the real problem to us that is:
there are 2 -3 - even 4 seconds of communication lag between the time the call is established with the remote person and the time that the Agent starts hearing something. We have tried this several times and it works in this way:
– the outbound call reached the remote peer ( IE: a mobile phone)
– the remote person answers it …
– 2 -3 - 4 sec’
– the Agent hears the person.
if someone has experimented this before and can advice or at least suggest where to look please do so.
1 - The classification portion of the call. Depending on how you have it set up it could take up to 5 or 6 seconds to classify a person as a person. This is an issue that I have experienced in the past but adjusted the settings on our dialogic card to work faster.
2 - The switch is taking a long time to transfer the call once it has been classified. This seems pretty unlikely given that the Avaya doesn’t actually transfer the call like Genesys / Dialogic CPD does.
My bet is that it’s just taking a long time to decide that the person you have called really is a person.
We have no Dialogic in place thus no parameter. Will have the man “over” the Avaya to look again in the Switch options/parameters, even if the time the Avaya shound take to “decide” if hearing a human or not is 1,5 secs. But … this is done before. The “voice-lag” is after the established.
If there’s an extra delay after the call classification, there may be some other issues not related to the outbound solution. Post the URS and TServer logs for further help.
in your T-Server logs, look at EventDialing, EventNetworkReached, EventEstablished and then look at EventRinging for the agent. What are the timestamps?
Also, just to be on a safe side and not waste too much time: PegDEF anywhere to show that the call is actually default-routed to you?
My first two guesses would be:
delay in classifying the call
default-routed call
and the optional third one being:
The lag after the established is still probably due to classification delays.
In an outbound call you should see the following events:
RequestMakePredictiveCall
EventDialling
EventNetworkReached
EventEstablished classification time
RequestSingStepTransfer (classification complete at this timestamp)
EventQueued
EventDiverted
EventRinging
EventEstablished (at the agent)
Or at least something similar (I might have missed one or two), the time it takes for call classification is between the first established and the request to transfer the call. If you can use Kazimir on an outbound call you should be able to see clear time stamps and see where the delay is.
yeah, usually it’s like that, but some extra delay cause by the strategy may have occured.
And in his case, Avaya + URS and no CPD, there isn’t RequestSingStepTransfer event and there is the EventRouteRequest
creating the campaigns/calling lists we have associated a defaultDN as before 30090 or 30347 This is a RP where there is a simple strategy with the target block … yet in logs (for outbound as per inbound there are ) I have no EventQueued, EventDiverted or EventRinging.
The problem for me is some parameter on Avaya where you must declare some timers like:
How long does the call must ring before declaring it as No Answer
Values of noise amplitude to be recognized as voice
For me you have a problem with detection, I have faced similar issues with an Alcatel (sorry again but that the only PBX i manage). You must talk to your Avaya guys to do a trace on Voice detection, I guess they should be able to do it. and see the events as you see on TServer. Check that Voice detection is not going over an IP link, I mean PRI boards must be on same hardware as the board that does the Voice detection, if it goes over IP it is a BAD idea as compression/decompression will take some time and add noise to the call (depending on the codec) and will get the voice detection to fail.
about the last post I wandered all night and today pushed to have REAL logs … that I got (the person at the other end of the line sent an incomplete set and I wasn’t able in finding basic events like EventRouteUsed : anyhow ..
these aren’t looking so “slow” to me - what do you think?
cavagnaro:
Check that Voice detection is not going over an IP link, I mean PRI boards must be on same hardware as the board that does the Voice detection, if it goes over IP it is a BAD idea as compression/decompression will take some time and add noise to the call (depending on the codec) and will get the voice detection to fail.
It is a clear Avaya issue.
actually .. I think in this way too. The last time I have seen a issue like this was working with the IPMX. The Video conference was routed and Established in very few time. Then compressed Video-Audio packets where not so fast and the voice was not sincronized until we lowered the compression level AND used a better codec G.723.
Sorry to say but this log says nothing at all: there is no EventNetworkReached and only from a full TServer log on can check when a message from the switch notifing the answer was received.
The only thing that can be said from it is that the routing doesn’t add delay excluding that 1 second between the EventQueued and EventRouteRequest: 10$ (no , hold on, 10€ are worth more now ) that is the “wait-time 1 sec” in the vector before the “adjunct” command
if the event was in the logs I was willing to post it. but there was not. Also cannot upload logs as these are prod ones (with a log of inbound in the middle ) and are 10 Mb each.
Anyhow .. I have partially handled with options mentioned before and new treatments and now the calls that come to operator while still dialing are only the 25% (before it was 100%)
what do you think I should handle to put these under control? still work on treatments? could you post some working one for the No Answered. Also in your call center the calls do ever reach the operator while dialing?
I run 3 different AM detection setups and not one of them will send calls through to agents while still ringing.
One of them is an Avaya using Avaya classification and I have never seen this problem before, this problem will definitely have nothing to do with your treatments as the call should never get to the agent if it is not answered. Unless you have set the “Apply to call” field in your no answer treatment to “Connect”?
