HOW TO: Optimizing Aculab Cloud Platform Usage in Outbound Dialling
Aculab Cloud provides you with the means to make outbound calls for just about any purpose. Using Aculab Cloud’s simple, high-level APIs to launch outbound calls, numbers can be manually or automatically dialled, and what happens during and after call set-up can be controlled by the application. For example, an answering machine can be detected, using what’s called call progress analysis, whereupon the system will wait for the tone or ‘beep’, before playing a message or otherwise interacting with the called party’s device.
But what about those calls that don’t connect and are reported back as ‘busy’ or ‘unobtainable’, or classed as ‘no answer’? Those short calls are still billed at 1 cent per minute. You’d be forgiven for wishing there was a way to optimize that situation so that your platform usage could be minimized in relation to non-completed or short duration connected calls.
The good news is, there is a way!
When designing your outbound call application, instead of thinking of it as a phone call, think of it as an application with a lifetime of multiple calls. To begin with, instead of passing the number to dial as a parameter, consider pulling those parameters from a database or web service within the application. That minimizes the number of arguments and also generalizes a bit more, so to speak, your outbound application.
Once you have your application pulling arguments for the outbound call from a database (i.e., phone number, text or wave file to play, or call flow), the next thing to do is to make the application loop. Why make it loop? Well, if the phone number you retrieved and dialled was busy, and that took only five seconds to figure out and update in your database, you still have 55 paid for seconds with which to play! So, loop back to the start of your application and grab another phone number to dial and get its call flow. Then make that call and keep doing that until there are no remaining phone calls to make. Once there are no more phone calls to make, exit the application.
The natural result of following the above steps is that you will have saved a lot of application time. That’s good! But what if you have a system that needs to make 50,000 calls? If you’ve followed what you’ve just read, you will not allow your application to launch 50,000 instances. Because of the looping technique, you will instead launch say, 1000 applications, and each of those 1000 application instances will make an average of 50 calls.
Note that the number of applications launched vs. the number of calls made per application (or per campaign) is up to the application that launches the calls.
That will get you so far, but if you are now asking if there is an alternative to launching 1000 application instances, your thinking is along the right lines and you’re asking a good question. It does seem like a waste to make 1000 separate web services calls (for that’s how you start outbound applications!). And the answer is…
Create an outbound call application that launches any number of application instances you care to specify. That can be a single application or 1000 simultaneous instances. In terms of Aculab Cloud, all you need to do is to specify the number of instances of a specific application and the appropriate resources will scale up to that number and the resultant calls will be distributed to your application servers.
A single outbound application launches ‘n’ dial-out application instances, each of which in turn makes ‘x’ outbound calls.
Chris Flynn, lead technical consultant, Aculab Cloud USA