How to automate test calls

[beckyjmcd]

We are trying to proactively identify problems in our call center.  We would like have a program run at regularly scheduled intervals (several times each day) that places calls to specific numbers.  The program would want to know if the call successfully went through (rang and was answered, i.e. no fast busy or dead air).  If the call was NOT successful (some sort of error), we would want the program to email a distribution list alerting the technical team of a possible phone problem.

I am a software developer but am new to telephony.  Is this possible using the Genesys SDKs or the Outbound Dialer?  Or, is there a telephony service that could provide this functionality?

Thank you,
Becky McDermott

[Adam G]

If you already have the Genesys telephony environment built, you can build a Routing Strategy to make calls and extract results through reporting (CCPulse+, CCA, Info Mart, etc.) .  Your Strategy can be invoked to run at regular intervals through IRD, making the overall process automated.  If the test call runs into difficulties, you can build in an (SNMP) Alert within the Strategy (if you have SNMP Alerts configured/purchased) - or you could create an Alert via CCPulse+, if you know the exact conditions (Not Answered is one outcome - there might be others...)

HTH?

[mduran22]

Hi Becky,

I have seen this done with Dialogic SDKs and with Genesys. There are companies out there that will provide a service for you on this as well but they can get expensive.

The biggest challenge I have seen with automated monitoring like this is the false positives. As an example if your application can't dial out because of internal congestion it might alert you something is wrong with your toll free.

Also you have to consider what the agent is going to hear when the call is answered (are you going to play a message stating that this is a test call?). In one instance I worked with we had a slew of tickets opened after deploying a automated testing solution by agents saying there were getting calls that were just dead air and then disconnects, which was caused by the monitoring calls.

Mike

[beckyjmcd]

Mike,

Thank you for bringing up some good points to consider when deploying a testing solution.  We will need to think that through.  Do you know of specific companies that provide the service to test phone numbers?  I found "Number Sweeper" by Empirix but am having difficulty finding services that will specifically call a list of numbers.

Most of our issues are pbx/hardware related so we want to know when we have a problem with things even getting into our system.  In these cases, Genesys does NOT alarm at all and thinks everything is ok.

Thank you

[mduran22]

Emprix/Hammer technologies was the one I was thinking about. If they don't have anything on line, I would call and talk to someone as I am sure they would customize something for you.

In the case of developed solutions, either with Genesys or another SDK, you can connect a server either to the same PBX, a separate PBX or you can even hook up pots or a separate T1 directly into the server or even a hosted server solution.

Google autodialer services or companies, most should be able to customize a service for your if they don't have one.

[victor]

There are several ways to do this:

1. Hammer- great product, but expensive
2. automate softphone (pretty simple, should take you half a day at most if you have access to source code)
3. phantom stations (but it is mainly for CTI load testing, not voice)
4. get a temporary number to handle the volume and post it on craiglist offering a used car for free (we have done it and it was simply the best load test ever! Turning off the number would remove the load, and no one even knows who you are!)

[Dionysis]

Another excellent testing platform is Cyara.

http://cyara.com

They can do automated testing from the pstn all the way through to the agent (by analysing the audio that the agent actually hears), including voice quality testing, load testing, etc etc.  We've used them quite a few times.

Beware though, it can be expensive, and the data you can get is extremely comprehensive, so expect to spend a lot of time reading reports and listening to test recordings.  You also need to be very clear about what constitutes a failure scenario as it uses voice recognition on each and every message, if it's confidence level is below x, the whole test fails.  This can skew your test results initially.

[genesysguru]

Hi,

The key thing here is to understand your architecture in a bit more detail to determine the best place to inject test calls. If SIP based a quick and cheap solution would be FreeSWITCH with a suitable dialplan and/or custom dialplan application.

[victor]

You are right! FreeSwitch should be a perfect way to do it. Add Dialogic card or an Audiocodes gateway and you can get PSTN calls as well. Why did I not think of it?

Of course, this still leaves the agent side - how to have softphones auto-answer and behave like a call center?

[genesysguru]

Vic,

I love FreeSWITCH and will be blogging about my customisation of it shorly based on some Genesys INAP integration work I have recently been doing:

http://genesysguru.com/blog/blog/2015/01/03/genesys-inap-integration-2/

Anyway - the agent side I would automate with something like this:

http://genesysguru.com/blog/blog/2010/10/16/genesys-test-utility-gtu/

[cavagnaro]

Greg as always your blog is full of interesting information... My hat off

[victor]

Greg,

your article  is simply amazing. I just was wondering one thing: couldn't SS7/IP be done with an AudioCodes gateway? Or did you build on top of Dialogic protocol to reduce cost?

Cav> don't you mean turban, and not hat?

[genesysguru]

Hi,

There are a few SS7 stacks available but I chose DSI since a) it has been around long enough and b) there is great flexibility in terms of protocol stack configuration. In the case of the blog article it was INAP over SIGTRAN but there is no reason why it could not be reconfigured to use MTP3 on physical links etc.

[jamesmurphyau]

I've used SIPp to automatically generate calls to a SIP Server before - it was a bit finicky and you need to either setup a Trunk DN or allow calls from unknown trunk IPs but it ended up working pretty well.. I can try dig up the SIPp scenario file if interested.