If you are an Asterisk integrator, it may have happened to you: one of your clients requires simple outbound capabilities, e.g. calling back a customer who filled in a recall form on their website. Simple enough. You start by creating an Asterisk call-file to generate each call - it works nicely and it is easy to set up, but if the call does not complete then it is lost. So you have to create a process that keeps track of the call and retries it in time. And that's not an easy feat to pull off when starting from a call-file. The first thing your client notices is that calls end up using an unpredictable amount of lines - as they basically have an office PBX, people cannot dial in because at peak times your script is saturating all outgoing channels. Management is not happy and you have to keep track of trunk usage - not only your own, but your client's as well.

Then your client notices that those calls should not be made outside business hours - a customer might require a call at night, but there must be someone at their offices in order to call back. So you have to implement a calendar in your custom application. Now that you have the calendar, your client notices that calls are generated at inconvenient times - sometimes all of their service reps are sitting idle, and other times they are all busy and calls keep piling up. So you have to edit your scripts to keep track of the current end-point statuses and decide when it is a good time to call. Just at this point, they start to saturate their existing PBX, so they need to set up a cluster of boxes and they want your application to handle this. And while you are at it, what about usage statistics? and why not running different outbound services at once? and did they tell you they need to integrate their existing CRM? and could you add predictive capabilities to the set? It looks like a nightmare. And it actually is - been there, done that. That's why WombatDialer was created: all common outbound logic should be encapsulated through a declarative interface. No need to reinvent the wheel. You program the dialplan to be executed - either manually or through a GUI - and WombatDialer takes care of the rest. You create scripts if you need to send and receive data from WombatDialer, and you can control it all through a simple HTTP interface.