Outbound campaing - the call comes to Agent while still ringing

[Marco64]

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?

pls feel free to make questions or ask for data .

Tks all.

[Dionysis]

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.

[Fra]

[quote author=Marco64 link=topic=3353.msg13948#msg13948 date=1222186389]

the campaign is run in Progressive on a SCS ver 7.
[/quote]
SCS?

[quote author=Marco64 link=topic=3353.msg13948#msg13948 date=1222186389]
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.
[/quote]
It does have those capabilities by using call classifiers and a bunch of fine tuning  - hassle .

[quote author=Marco64 link=topic=3353.msg13948#msg13948 date=1222186389]
The first issue we have is that the calls are coming to operator while still on ringing
[/quote]
What do you mean?

[quote author=Marco64 link=topic=3353.msg13948#msg13948 date=1222186389]
and it's up to the Agent to find what it is. What I can see/configure to handle this?
[/quote]
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.

[quote author=Marco64 link=topic=3353.msg13948#msg13948 date=1222186389]
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?
[/quote]
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?

[Marco64]

[b]Dionysis:[/b]
got it on the PaBX settings. I thought that too. Will check the option on TServer.

[b]Fra:[/b]
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.

Marco of Milano you?

[Fra]

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..

Anch'io, ma lavoro a Londra ora.

[Dionysis]

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?

[Fra]

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..

[Marco64]

[quote author=Fra link=topic=3353.msg13967#msg13967 date=1222247485]
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..

Anch'io, ma lavoro a Londra ora.
[/quote]

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.

 

[Dionysis]

There are 2 things that cause delays like that.

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.

[Marco64]

Tks for answering. Appreciated.

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.

Ciao
Marco

[Fra]

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.

Francesco

[victor]

Ok,

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:
1. delay in classifying the call
2. default-routed call
and the optional third one being:
3. Tony is using your environment for load-testing

[Dionysis]

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.

[Fra]

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

[Marco64]

tks all

the timestamps I have are:

LocalTime TimeinSecs TimeinuSecs '30090'
2008-09-25 15:56:44.9060 1222351004 906000 EventDialing
2008-09-25 15:56:49.2500 1222351009 250000 EventNetworkReached
2008-09-25 15:57:00.7650 1222351020 765000 EventEstablished
2008-09-25 16:00:18.3120 1222354818 312000 RequestReleaseCall
2008-09-25 16:00:18.3280 1222351218 328000 EventReleased

and
LocalTime TimeinSecs TimeinuSecs '30347'
2008-09-25 15:56:57.1710 1222351017 171000 EventDialing
2008-09-25 15:57:01.8280 1222351021 828000 EventNetworkReached
2008-09-25 15:57:33.7500 1222351053 750000 EventEstablished
2008-09-25 15:57:36.2960 1222354656 296000 RequestReleaseCall
2008-09-25 15:57:36.3120 1222351056 312000 EventReleased

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.