WombatDialer started to be used for production services about two years ago. Its first adoption scenario was telecasting - delivering voice messages to a large set of recipients in a way that was fully automated, scalable, monitorable and integrated with external processes. We put a lot of effort into making sure that this worked to the point of being 100% reliable. Now our baby wombat is growing up.
A lot of users are demanding multi-tenancy and better control of how calls ending up to human agents are to be placed. Version 0.7.0 is available now, and it adds a number of interesting new features:
A complete description of all the changes is available in the updated User Manual, available in HTML and PDF from http://www.wombatdialer.com/manuals.jsp
You can test drive the latest version now, by running “yum upgrade wombat” on an existing installation. Or see http://wombatdialer.com/installation.jsp
We look forward to your feedback and suggestions - we have a special forum for feedback located at http://wombatdialer.userecho.com . Let us know what you think of the new version and what you would like to see in the next version of WombatDialer.
Preview dialing is a type of reverse dialing available since WombatDialer 0.7.0 where the agent has a chance to “preview” the number that is to be called before actually having a call placed.
The way it works is:
In order to run this tutorial, we install a brand-new Elastix 2.4 system. On it we create:
We install WombatDialer on the Elastix system using yum. When we log in, we create:
Local/${num}@from-internalNow we go to the list manager and upload the following list:
300,NAME:John
301,NAME:Mike
This tells WD to dial numbers 300 and 301, and sets a NAME attribute for each call (that will be useful when previewing).
Install QueueMetrics on the same machine as the Elastix system by typing:
yum install queuemetrics-espresso
Now log in into QM and configure:
Now edit the “System parameters” and edit the section realtime.agent_button_1 as follows:
realtime.agent_button_1.enabled=true
realtime.agent_button_1.caption=Wombat
realtime.agent_button_1.url=http://10.10.5.30:8080/wombat/agents/rd_pop.jsp? agent=SIP/[a]&url=http://10.10.5.31/sugar/index.php%3faction=UnifiedSearch%26module=Home%26query_string=<NUMBER>%26name=<NAME>&inset=1
Edit the public IP of your Elastix server and replace the “10.10.5.30” address above.
This code links to an instance of SugarCRM on 10.10.5.31. On it, create a contact named “John” which telephone number is “300” and one contact named “Mike” which telephone number is “301”. You can link to any other CRM software that has a web-based interface just the same way.
Now click on the button called “Wombat” from the Agent’s page. You should see a preview panel like the one in the picure:
As you can see the SugarCRM panel is displaying the right record.
TIP: the first time you call the page, SugarCRM might ask you to log in. Do it and refresh the page.
If you look at the Live page on WombatDialer, the call should appear as “Reserved”. When the agent clicks on Dial, the call should start. Once the agent answers, your dialer will try and connect the other extension.
When dialing, the Live page will show what is going on:
And the same thing will happen on the Agent’s page:
Nice work, isnt’t it? :)
We have been quite busy working on a number of themes that will make WombatDialer better and more useful, so we thought we’d better share them with you.
The first theme we have addressed is improved flexibility in dialing to agents. A number of users asked for ways for agents to be already connected when the callee is rung. This led to the developement of Reverse Dialing and Reverse Stepwise Dialing. With Reverse Dialing, the agent is rung first and then the call is attempted. This makes sure that when the callee answers, the agent is already on-line and ready to talk. The agent must be a member of an Asterisk queue, so that we get presence information (log in, log out, pauses and current status) right out of Asterisk. This also lets you share an agent on multiple queues with different dialing policies.
With Reverse Stepwise Dialing, we go a bit further - we use an API so that an agent can reserve a call, preview it and decide whether to actually dial it or to mark it as processed without dialing. If the agent does not want the call processed, you can reschedule it or mark it as not to be processed. If the agent does not make a decision within 10 minutes from reserving, the call is put back into the dialing pool. All call variables are passed to the agent, so you can display them or link to an external CRM.
The second theme is security - we are adding a security model that matches the one used by QueueMetrics, so that you can make different trunks, end-points, campaigns and list visible to some users only. This also affects Live viewing and campaign reporting and will make WombatDialer completely multi-tenant (like QueueMetrics is).
After this, we plan to address two major themes - AMD/Fax detection and Black lists / Robinson lists. For AMD/Fax, we plan to use the facilities Asterisk offers in order to detect whether the call is answered by an Answering Machine or by a fax machine. This has the major advantage of not tying you to a specific solution, but lets you use a plethora of third party modules that are available for Asterisk in case you should find the default ones not good enough for you. WombatDialer will run the channel detection scripts and will react by sending either a pre-recorded message (for AMD) or a fax page in case no human caller is detected.
As per black lists, we plan to offer both a way to check numbers against a set of internal lists or against an external server using an API. A number will be checked against all lists for a campaign and will be processed only if all call lists allow it.
We plan to release the first two features - Reverse and Reverse Stepwise - in about one week. Work is already ongoing for security, so this should be available in 0.7.0 by the end of June. AMD/Fax and black lists will be implemented by the end of the summer - as they in the planning stage, we would like to hear from you about what you would need. We have a Sugegstions forum on UserEcho at http://wombatdialer.userecho.com where you can propose new improvements and vote on what other people proposed, so make sure your voice is heard.
(Source: wombatdialer.com)
We have a new version of WombatDialer available on the public repo. This version adds a few interesting things to WombatDialer and should make your life easier when running it in production.
First, WombatDialer has a better status view of queues: it now prints out the agents present on a queue and their current state, plus the calls (if any) currently queued.
This way it is easier to understand what is going on in real-time. Also, when a call is connected to an agent, the agent being used is shown on the Live page. WombatDialer also tries to sync the queue as soon as it is brought up, so you always see all queues for your running campaigns even if you restart the dialer.
The second major change is that call lists are now dynamic. You can pause and add lists on running campaigns, and WombatDialer will immediately respond to the changes you make.
You can even add lists to idle campaigns, and they will start dialing immediately. For each list, the current high-water mark is displayed. The Live page also includes a check so that you cannot send commands to the dialer if the dialer is currently down.
One last important change is that the infamous DTSC bug was fixed, so you do not need to restart the dialer multiple times. This will make installation of the system easier.
We look forward to your comments - we have a feedback system available at http://wombatdialer.userecho.com so the community can propose new features and discuss them before we implement them. And do not forget to follow us on Twitter or Facebook so you can be updated when we have something new for you!
It is quite easy to install WombatDialer on PBX-in-a-Flash in order to give it autodialer, voice broadcasting and progressive dialing capabilities. This was tested on PIAF 1.7.5.6.1
Before we start, it is important to notice that there is no need to run WD on the same box your PBX is running. As WombatDialer relies exclusively on AMI, you would be likely better off (at least when experimenting) to set up a virtual box based on CentOS 6, install WombatDialer there and connect remotely to PIAF (or any other PBX). You will just need to create a special AMI user on your PBX allowing remote connection (see below).
If you want to install it on the PIAF system, here is what you would do:
Add the Loway repos
wget -P /etc/yum.repos.d http://yum.loway.ch/loway.repo
Install WombatDialer automatically using yum
yum install wombat
For the moment, stop iptables, or you won’t be able to connect remotely
/etc/init.d/iptables stop
Of course you would not want to run a production system with iptables off, so just add a rule allowing access to port 8080 from your workstations.
Now open your browser and go to:
http://server:8080/wombat/
It will get you to a page that will prompt for database creation. This will create a db called “wombat” and will fill it in with initial data.
When asked, remember that the default MySQL root password for PIAF is “passw0rd”.
After this, it may need to update the database. Will take only a few seconds (this step might not be necessary - depends on the version of WD you are installing).
Then, you will be shown the license agreement. Approve it (but read it first!)
Now you can log in as “demoadmin” password “demo”.
As a first thing, you’ll have to tell WombatDialer to which server to connect to. If you connect via AMI to the local system, you can use default AMI user “admin” password “amp111”. If you installed WD on a different system, you need to create a AMI user that will allow remote connection - edit /etc/asterisk/manager_custom.conf to add it. At this point you should really have a look at the Getting Started Guide.
Now that WombatDialer is installed, you should look around on this blog to see many different things you can do with it. If you’d like to try automated queue call-backs, see http://blog.wombatdialer.com/post/41774590472/autorecall - the source script can be found at https://github.com/Loway/WombatDialerExamples.
Happy hacking!
We originally started working on the WombatDialer as a “sidekick” of QueueMetrics for a couple of clients who were interested in having ways to automatically feed Quality Assessment data into QM. The idea was to recall callers and offer them a short IVR quality assessment menu, in order to gather information on how well their call-centre was behaving.
So we needed something to do that, in a way that was basically turn-key. By designing the requirements, we found out that you could have Asterisk do a lot of things that all had in common the dialing logic - see Why was WombatDialer created for a longer explanation. The name came from the son of our lead engineer, who was three at the time and heavily into wombats and furry animals in general.
Our point with WD was not replacing common Asterisk predictive-dialer solutions (there are a number of them, and they work well) but offering declarative dialing primitives - you tell WD what you need and it performs as if it was one single call on one single server, though it may be hundreds of calls on multiple servers. The idea was that you would install it on an existing system - that had its own dialplan and GUI - and it would interface. That it would work along whatever telephony traffic you had on the box. So we did not initially target predictive, agent-heavy systems, but thought about telecasting, and moved on to power-dialer when used together with queues. And we added a free usage license so that people like you could download it and use it to create something new on their own PBX - no questions asked, but please share!
We found a lot of interest so far - we already have a number of systems installed worldwide and many more in testing phase that we are following up. People keep coming up with ideas on things one could build - recalling queue hangups is really interesting, and so are reverse IVRs in general. We are learning a lot and try to make the product better.
What would you like to build next to improve your call-center (or your PBX) by adding easy to use, scriptable outbound iteractions? Just let us know.
If you run a call center, serving clients in a timely way is often very complex, as it requires having enough people available to handle traffic spikes. The number of callers that disconnect because they have been waiting too long in a queue is then an important driver of the quality of your work, and these frustrated callers are the focus of much attention and scheduling/planning efforts in all call centers. This is because in a traditional setting doing inbound calling you basically had no other way of servicing the client but waiting for the person to call in.
With an Asterisk-based PBX and using digital lines, this scenario changes a bit, as:
So it is now a conceivable scenario to improve the services you are offering by adding an automated call-back option, so that you search the logs of lost calls and you actively schedule recalls on them in order to get back to people who hung up in frustration.
The plan: automatic queue recalls
In this article, we explain how to implement a basic call-back scenario using QueueMetrics and WombatDialer. What we do is very easy, as in:
As our dialing schedule happens on a WombatDialer campaign, we can control the flow of calls through it by adding and removing agents supposed to handle outbound traffic, or pausing it completely during periods of high inbound traffic.
Step 1. Configuring QueueMetrics
In order to gather information from QueueMetrics to an external script, we need to enable XML-RPC access credentials. This is usually very easy to do, as QueueMetrics ships with a (disabled) ROBOT login that allows external access.
Enabling it is very easy: log in as an administrator, click on “Edit users”, edit the “robot” user and set “Enabled” to yes. While you are at it, take a second to change the default password.
Step 2. Configuring WombatDialer
Set up WombatDialer with a queue end-point (as described for example in “Elastix Queue call-backs with WombatDialer”) and make sure everything is working.
Create a new campaign for calling back people - set its “Idles on termination” property to yes and make the logging QueueMetrics-compatible. This way the campaign can run until needed, waiting for more numbers to be added when idle. Do not add any call list as we will load numbers to be called through the WombatDialer APIs.
Before you start scheduling recalls, your campaign should look like the following one:
You might also want to pause it, so you can decide when to run it.
Step 3. The script
Scripting QueueMetrics and WombatDialer is really easy. It can be done in any language - we chose PHP as it is well known, has good XML-RPC support to query QueueMetrics and is very simple to edit and customize.
We created a sample script that can easily be downloaded from GitHub - as you will likely edit this to suit your needs, feel free to fork a new project and work on that. Our script is available from https://github.com/Loway/WombatDialerExamples in a folder named “AutoRecall”.
The following parameters should be edited in the script:
$qm_server = "10.10.5.11";
$qm_port = 8080;
$qm_webapp = "queuemetrics";
$qm_login ="robot";
$qm_pass = "robot";
These parameters specify the XML-RPC connector of your QueueMetrics instance.
$wbt_url = "http://10.10.5.18:8080/wombat";
$wbt_cmp = "c1";
These parameters specify the URL of WombatDialer and the campaign that calls should be added to. The dialer must be running when the calls are added and the campaign should be active (usually IDLE). Note that the campaign you use for call-back might be paused so that call-backs are actually deferred during periods of high activity.
$queue = "300";
$lookback = 3600 * 8 ; // in seconds
$allowedPatterns = array(
"/^555..../",
"/^0041.+/"
);
These parameters decide which set of queue(s) should be scanned and how long is to look back for the current day. Multiple queues can be used, separated by the pipe character.
The last parameter is a set of regexps that will be used to check the numbers read from QueueMetrics. At least one regexp must match for the number to be queued. This is used to avoid queueing invalid numbers or - worse - malicious numbers.
Step 4. Putting it all together
In order to run the script periodically, you could crete a cron jub that runs it every 20 minutes. As number are never recalled more than once and the script keeps an history files of numbers already dialed, you can safely run it over and over again.
Once tested, a crontab entry like the following one will automate the running:
*/20 * * * * /usr/bin/php /root/WombatDialerExamples/AutoRecall/autoRecall.php
This is how a simple run looks like - the scripts logs its activity to STDOUT, so you may want to redirect it to some log file for the keeping.
$>php autoRecall.php
Finding applicable period
Loading call log file for 2013-01-24
Looking for data between 2013-01-24.07:54:33 and 2013-01-24.15:54:33
on server '10.10.5.25' - queues '300'
Query took 0 seconds.
# 201 - Last call lost @ 2013-01-24.15:46:39 - Scheduling.
Adding 201 to campaign c1 on WombatDialer.
Saving call log
After running this, you should see that new numbers are added to an AUTO call list like the one shown in the following screenshot; and if the campaign is not paused and agents are availble on the recall queue, calls will be dialed as needed.
Improving the solution
In order to run this solution in a real-life scenario, you should edit the campaign in order to:
A new version of WombatDialer is out. The major changes implemented have to do with what happens when a campaign run terminates abnormally - e.g. if the system is shut down in the middle of a call. In general WombatDialer is supposed to recover gracefully when it gets back up, but there were a couple of possible cases where calls would linger on in the live screen (“ghost calls”). This version introduces a sanity check at the beginning of each run so that the database is purged of possible unwanted entries.
As a side effect of this job, we came across a set of cases where database access was sub-optimal and optimized those. This will make dialer startups quicker and will impose less load on the server when performing Live monitoring of calls.
The Live page was also improved - the details on which run is placing a particular call are easier to see, and the status of the dialer is also always visible from the Live page.
As a last note, we are trying a new form of collaborative support system - you will find it at http://wombatdialer.userecho.com. It is supposed to make it easier for a community to be heard on what is important and should make our life easier when pushing for new features. We suggest you stop by and say hi, so we can test how it is.
Today we released version 0.6.5 of WombatDialer - this version contains a few minor fixes for the UI, most noticeably a complete reworking of the security system with locks and keys.
Together with version 0.6.5, we release a new version of the User Manual that is now complete and covers all topics, including full documentation for the APIs, system administration and a Cookbook section that presents some real-life scenarios, plus a Getting Started section that shows a basic installation on Elastix.
We have a new video tutorial displaying WombatDialer installation and how to set up a simple telecasting campaign to run on an existing Elastix system in less than 10 minutes. It also shows how to set up basic rescheduling rules and how to analyze what went on during the campaign.
[video]