1. Version 0.6.13 - A taste of things to come

    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.

    New dialer status

    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.

    List manager

    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!

     
  2. Tutorial: WombatDialer and PIAF

    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.

    • Finish the installation using your browser

    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!

     
  3. A bit of history of WombatDialer (with furry picture)

    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.

    A likewise wombat

    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.

     
  4. Automatic queue recalls with WombatDialer and QueueMetrics

    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:

    • Your average caller has an associated caller-id that often matches a physical phone in their proximity
    • Telephone traffic is very cheap compared to the cost of agent time for call handling
    • You have ample means of programming the PBX to suit your exact needs

    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:

    • We periodically run a script to gather the caller-ids of lost calls that were handled on a queue
    • We check each caller-id as to be sure is a valid number
    • We check that there is no subsequent successful call on the queue from the same caller-id (as to prevent recalling people who already retried themselves)
    • We schedule those calls for dialing no more than once per number per day

    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:

    • set up a time window that matches your agents’ presence and when it is customarily allowed to recall. For example, even if a call is queued at 11 PM on a Saturday night, a recall might be acceptable only on Monday morning. This of course depends on what you are doing and the local customs.
    • set up reschedule rules in order to handle calls unanswered and busy lines correctly. It would be too bad not to be able to recall just because the caller’s phone was busy at the moment
    • it could also be useful to connect the caller to a reverse-IVR first, so that they get a message like “Hello, we are calling you back because of your call made at 10.30AM. If you’d like to talk to one of our agents, please press 1 now” before being routed to an agent
    • a simple addition that could be made to the script would be to set up a minimum wait time to qualify calls; that is, you would recall only people who waitied in queue for more than 10 seconds.
    • using a technique very similar to the one explained here, it would be trivial to set up campaigns for quality assessment or customer satisfaction, run as reverse IVRs.
     
  5. WombatDialer 0.6.7 released

    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.

     
  6. WombatDialer 0.6.5 released

    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.

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

    After getting to this point, it will be easy to create the more complex solutions detailed on the User Manual (BTW we are releasing a new version of the User Manual next week).

     
  8. WombatDialer 0.6.4 released

    We have just released WombatDialer 0.6.4 - this is the first version that does not expire but has a licensing model instead. So when you upgrade, it will contain a limited demo key and you can ask for a demo license in order to run a full test with a large number of lines. You should really upgrade as current versions will expire by the end of the current year.

    The licensing model used with WombatDialer is linked to the total number of lines it may use - does not matter how many campaigns you are running, how many calls you make and how many Asterisk servers it’s controlling. You can purchase multiple licenses at once, so for example to have 60 lines you may install a 50-line and a 10-line license together. And we believe you can create intresting and useful applications even with the 2-line free license included - enough for a doctor’s appointment reminders, for example. And pricing for license packs is really affordable.

    Licenses can be installed from the License page, after you log in, and are displayed on the dialer status.

    We look forward to your comments - WombatDialer is now a small community and it’s starting to be used worldwide.

     
  9. Small installation tutorial in Spanish

    We just found out that somebody from Voztovoice posted a short installation guide and review of WombatDialer, all in Spanish. It shows how easy it is to set up WombatDialer on a CentOS 6.3 system.

    You can find it on WombatDialer - Marcador autom√°tico para Asterisk.

     
  10. Elastix queue call-backs with WombatDialer

    You are called in to a client site; they seem to have a problem. They run a small (10 agents) inbound call centre, and when you join everybody else in the meeting room, there is a large and colourful graph in the middle of the table. The graph shows the call wait times during the week and boy, it’s not a good sight. Their main inbound activity is to offer client support for a company selling sport bikes, and everybody seems to be calling on Monday morning. It looks like people go riding on weekends and whatever problem they have, they call on Monday morning. Wait times peak, abandon rates spike, and nobody is happy. The call center manager is mostly concerned of having to hire and train some temp people in order to handle the load that only happens one day a week. They ask you if you have any better idea on what can be done. And yes, you have some.

    You can program an Asterisk queue so that when people tire of waiting, they press a digit and get to a menu where they can leave their number. Then the system queues their call and attempts to call them at a convenient time. This way:

    • your customer are happy; they don’t have to wait in queue for so long
    • your call center manager is twice happy: the first time because wait times and abandon rates go down, the second one because by placing calls at a convenient time they can smooth out the workload of their agents during the day

    This scenario requires some additional “glue” to what is basically supported by Asterisk - exiting a queue and reading a number are easy, but then starts the pain. You’ll have to create a database and write a script that reads back from it. You have to handle invalid numbers, busy numbers and the like (if we promised to call back the client, we cannot just try once and forget about it). You’ll have to have a GUI of some kind for the manager to start and stop dialing. You’ll have to adapt to the number of available agents. You’ll have to report on this activities. You’ll have to avoid flooding the trunks of your PBX with too many calls. In short, it’s the kind of thing that gets more complex the more you think about it. That’s what WombatDialer is for.

    What we plan to do is to use WombatDialer as the call-back engine. It can be controlled by an external HTTP API, so you can do that from the Asterisk dial-plan. It has a definite topology and call back rules, so you get the number of calls you expect on one or more Asterisk servers. It can work with an existing PBX and does not interfere with calls that are not its own. It keeps track of call completions and knows what to do in case of invalid and busy numbers. It has reports of its own and can work with QueueMetrics for powerful and detailed reports.

    The client uses Elastix as PBX system, so we’ll have to integrate it with WombatDialer. No problem!

    So what we do is:

    • First we create a normal queue, for inbound. We call it “400”.
    • Then we create a call-back queue. If our main queue is called “400”, then let’s call this second queue “401”. The idea is that WD will monitor this queue - when you have members on this queue, then WD will start placing calls. This way an inbound call-center with multiple queues will find it very natural to have some agents join and leave a call-back queue. When you creet this queue, make sure you set “Ring Strategy: rrmemory”, “Event When Called: Yes”, “Member Status: Yes”, “Autofill: yes” so that WD can use it effectively.
    • we create a piece of dialplan that will handle the exits from queue “400” and will gather the telephone number
    • we create a new “custom extension” (399) that will jump in the dialplan at “Local/1@queue-leavenumber”
    • In Elastix, we create an IVR menu and set it as a destination for queue “400”. This menu has only one option (1) that basically jumps to the custom extension “399” that we just created, in order to call our script
    • we go back to the queue “400” and set its “Fail Over Destination” as our IVR we just created

    We start by editing the extensions_custom.conf file in our system, adding a new stanza like:

    [queue-leavenumber]
    exten => 1,1,NoOp
    exten => 1,n(Start),agi(googletts.agi,"Please enter your telephone number and we will call you back.",en)
    exten => 1,n,agi(googletts.agi,"The number must be composed of 7 digits.",en)
    exten => 1,n,Read(CBNUM,beep,7,,2,5)
    exten => 1,n,NoOp( Num ${CBNUM} )
    exten => 1,n,GotoIf($["${LEN(${CBNUM})}"="7"]?lenOk)
    exten => 1,n,agi(googletts.agi,"The number you entered has the wrong number of digits.",en)
    exten => 1,n,GoTo(1)
    
    exten => 1,n(lenOk),agi(googletts.agi,"You entered the following number",en)
    exten => 1,n,SayDigits(${CBNUM})
    exten => 1,n,Wait(1)
    exten => 1,n,agi(googletts.agi,"Press 1 to confirm or any other digit to start again.",en)
    exten => 1,n,Read(CONF,beep,1,,2,5)
    exten => 1,n,GotoIf($["${CONF}"="1"]?Store:Start)
    
    exten => 1,n(Store),NoOp
    exten => 1,n,Set(WHEN=${STRFTIME(${EPOCH},,%y%m%d-%H%M%S )}
    exten => 1,n,Set(PARM=number=${CBNUM}&attrs=orgQ:400%2Cwhen:${WHEN})
    exten => 1,n,Set(foo=${CURL(http://10.10.5.18:8080/wombat/api/calls/? op=addcall&campaign=callback&${PARM})})
    exten => 1,n,agi(googletts.agi,"Thank you! we will call you back as soon as possible.",en)
    exten => 1,n,Hangup
    

    We use Google TTS as a voice synthesizer - you could use a different one or you could have the messages custom-recorded for you. What our dialplan does is first to collect a 7-digit number, then read it back asking for confirmation and when confirmed, it sends it over to WombatDialer on a campaign called “callback”. Together with the number, we also store the code of the queue that the call was on and the date and time this number was gathered. (Please note that in order to send multiple comma-separated parameters in the HTTP request, we have to use ‘%2C’ instead of the comma ‘,’).

    In order to configure WombatDialer:

    • We create a trunk called “Trunk” with a dial-string of Local/9${num}@from-internal and a capacity of 10 lines. This basically replies all numbers as if they were entered on a local extension prefixed by 9.
    • We create an End-Point of type Queue for monitoring queue 401; set extension to “401” and context to “from-internal”; max number of lines to 10; boost factor as 1 and max waiting calls to 2. This means that the number of calls placed will match the number of available agents on queue 401.
    • We create a campaign called “callback”; set it to Idle on termination and turn on QM_COMPATILE logging. We add the trunk and the EP we just created. We create a set of reschedule rules in order to handle REJECTED, BUSY, INVALID and NOANSWER calls, e.g. by retrying up to 5 times each waiting 10 minutes between each attempt. Note that we create no lists for this campaign.
    • We start the new campaign; having no numbers, it should immediately turn yellow on the Live page to tell you it’s idling.

    If we start sending calls to the queue and we try and leave any numbers, we will see that a new list will be created on WombatDialer under the name “callback/AUTO” and that will contain the numbers and attributes like:

     Number:     5551235
     Attributes: orgQ:400   when:121115-153402
    

    Those numbers are NOT immediately called, but WD will wait for some agent to be present and active on queue “401” so that they can be called back. This way, the call-center manager can monitor the current call backlog and decide who and when it is to join the callback queue.

    Further improvements

    • If there is a caller-id on the call, you could ask the caller whether to use it as the number to be called back
    • You could add time limits to the WD campaign so that you are sure that no calls are made otside acceptable periods

    See also