1. Introducing QueueWiz

    For the Astricon 2013, we created a little tool that lets you easily model Asterisk-based call centres.

    QueueWiz is the first free web app for interactive, quick and accurate call center sizing, cost and revenue simulation. Insert your data with the intuitive interface, measure traffic intensity, expected wait times, agents’ engagement, revenue per call and per agent and even hourly margins. Save your simulation and share it via email or social media.

    Completely free of charge at http://queuewiz.queuemetrics.com.

     
  2. WombatDialer 0.7.3: Black lists, CSV uploads and more

    After a few months of work, we are proud to release WombatDialer 0.7.3. This is a major release that adds a number of features that have been on the wish list for quite a bit of time.

    Namely:

    • Black lists. It is now possible to filter call lists dynamically when dialing out using one or more Black Lists. Black Lists are lists like any other in WombatDialer that can be used to collect numbers that are not to be called anymore. They can be updated through the HTTP API, so you can control this feature externally and while a campaign is running.
    • CSV import / export of lists. You can now prepare lists of numbers to be dialed (with all their attributes) using your favourite spreadsheet and upload them to the dialer through and easy-to-use drag and drop interface. You can also export lists of numbers with attributes as CSV files.
    • Separate Agent CLID. A number of times, you want your agents to receive a call which caller-id contains information on the call being made (e.g. the name of the person called, or their CRM id - you choose). You can now have separate caller-ids for the external versus the internal side of a call.
    • Attributes substitution. You can now use call attributes in caller-id’s, caller presentation and logging code.
    • Sortable campaign runs. In the Live page, you can now decide the sort order of campaigns and runs
    • Number generator. The number generator can now create correctly set of numbers to be dialed whatever their prefixes
    • Better security. On all user-created records, you can now see who created them and who modified them last
    • Live dialer status. The dialer box on the main page can be set to refresh automatically

    Plus a large number of fixes, usability tweaks and minor redesigns meant to make the experience smoother and better.

    You can try the latest version with the free license included or you can upgrade an existing systems through the yum installer. Get started from our Dialer Installation page. We are sure you will like the new release.

    PS. We’ll be exhibiting WombatDialer and QueueMetrics at the Astricon in Atlanta, booth 33 - come and say hi.

     
  3. WombatDialer 0.7.0 available today

    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:

    • Reverse dialing lets you have outbound agents immediately connected when the callee picks up, without the minimal delay of waiting on a queue for dispatching. On top of this we implemented preview dialing, where agents can check the number to dial and approve or skip it - we have a tutorial for this, showing the integration of the default preview panel into the QueueMetrics agent’s page at http://blog.wombatdialer.com/post/52639475437/preview . As with most things in WombatDialer, we included all-powerful APIs to roll your own.
    • A complete security model that closely mimics the one used in QueueMetrics will let you define multiple, separate “tenants” having their own campaigns while sharing the physical Asterisk infrastructure
    • Dynamic Campaigns: runs can now have lists of numbers added (or paused) while they are running. Working fine with “idle” campaigns as well.
    • The Live page was improved to display the dialer status and - when using queue end-points - who is the agent currently connected to a call. Also a number of usability tweaks were implemented to make the experience smoother.
    • The dialer controls now show extensive queue and agent details to make monitoring easier. Also the dialer supports better syncing to live queues when restarted.
    • A number of performance changes will make processing larger campaigns a breeze.

    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.

     
  4. Tutorial: Reverse preview dialing made easy

    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:

    • The agent logs on to a queue. WombatDialer uses the queue (as it usually does in Reverse dialing modes) to know which agents are available. This makes integration with QueueMetrics very easy.
    • The agent asks WombatDialer for a number to call. WombatDialer gets the next number out - considering all its dialing and reschedule rules - and reserves it for the agent.
    • The agent uses a GUI where they can see the number to be dialed and typically embeds, or links to, an external CRM app so that they can review the call
    • When the agent is ready, they ask for the call to be either placed or skipped.
    • If the call is to be placed, the agent is connected immediatately and listens to Music on Hold until the callee is on line
    • If the call is not to be placed, it is maked with a special code
    • Reschedule rules apply - so error states are handled correctly

    Step 1: Installing Elastix

    In order to run this tutorial, we install a brand-new Elastix 2.4 system. On it we create:

    • Three SIP extensions: 300, 301 and 302. We will use 302 as the agent extension while 301 and 300 will be used as sample end-points
    • One queue, called “400”, to hold our agent. Note that calls will NOT be processed through the queue but we will use the queue to keep track of which agents are available. When defining it, we make sure that we set: “Ring Strategy: rrmemory” - “Event when called: yes” - “Member status: yes” so that WombatDialer can fully observe it.

    Step 2: Installing WombatDialer

    We install WombatDialer on the Elastix system using yum. When we log in, we create:

    • An Asterisk server that can talk to Elastix. We can use the AMI user “admin” with the default password you gave during the system installation.
    • A trunk named named “Trunk”, which dial string will be Local/${num}@from-internal
    • An end-point of type QUEUE, which name is “400” (so that it observes queue 400), located at extension “400” context “from-internal” (this is not really needed if you run only reverse campaigns), setting both “Reverse dialing: yes” and “Manual preview: yes”
    • We create a list called “Numbers” and leave it blank for now
    • We create a campaign called “Reverse”, which has logging set as “QM_COMPATIBLE” and which logging code is “400”. We add to it the trunk, the EP and the list we just created.

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

    Step 3: Installing and configuring QueueMetrics

    Install QueueMetrics on the same machine as the Elastix system by typing:

    yum install queuemetrics-espresso
    

    Now log in into QM and configure:

    • An agent called agent/302
    • A user for agent 302 called “agent/302” password “999” class “AGENTS”
    • A general monitoring queue called “400”. Set agent/302 in the MAIN level of that queue.

    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.

    Making it all work together

    • Log “agent/302” into QueueMetrics and have him join queue 400 on extension “302”. Note that we are using Hotdesking - the agent logs into Asterisk with their SIP extension.
    • Start the dialer. From the Live page, start the campaign “Reverse”. No calls will be placed.
    • Check the dialer status. You should see WombatDialer observing queue 400 and finding “SIP/302” logged on. Try pausing and unpausing the agent and refreshing the dialer: the status of SIP/302 should change accordingly.

    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? :)

    Improving the solution

    • You can add PSTN numbers to your lists and the will be dialed as if the had been entered on a local extension.
    • If you want WombatDialer to dial without waiting for an agent decision, just remove the “Manual preview” check and restart the dialer.
    • If you want a customized preview panel, you can create one by using the WombatDialer API.
     
  5. A WombatDialer roadmap - reverse dialing, AMD/fax detection and more

    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.

    Busy Wombat

    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)

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

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

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

    $&gt;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.
     
  9. 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.

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