1. WombatDialer and QueueMetrics

    The WombatDialer can be used as a stand-alone product for message broadcating, but it was built to integrate easily with QueueMetrics, the premier call-center monitoring and reporting tool for the Asterisk PBX. WombatDialer and QueueMetrics do different things, but together can be a very powerful call-center solution.

    • WombatDialer is able to use a Queue as and end-point in order to connect calls to a set of agents
    • QueueMetrics is able to monitor extensively the queue and provides a convenient agent interface that works well with WombatDialer

    In this example, we improve the scenario described in Feeding Wombats, one carrot at a time imagining that the want to:

    • use a custom CRM interface so that agents can immediately see the name of the person being called and can open up an external CRM application for each client so they can gather donation data
    • monitor each agent’s performance
    • use a dynamic list of people to be called so that as soon as you know of an interesting lead, you can add it to the list of persons to be called.

    You can have WombatDialer and QueueMetrics installed on the same server, unless you have a very high load or a very high number of lines.

    As a first step, we’ll have to create a small interface script that will be our CRM application. We will call it wombatPopup.php and will store it on one of our servers as http://10.10.5.10/lenz/wombatPopup.php

      Plain Wombat Agent Panel<hr>
      <?
      $number = $_REQUEST["caller"];
      $agent  = $_REQUEST["agent"];
      $unique = $_REQUEST["unique"];
    
      preg_match('/#(\d+)\s(.+)/', $number, $matches);
      $id = $matches[1];
      $name = $matches[2];
      ?>
    
      Person is: <?= $name ?> (ID #<?= $id ?>)<p>
      Agent is: <?= $agent ?> <p>
      Call unique is: <?= $unique ?>
    

    This page basically displays the person’s name and ID, so we can display it immediately - or this could redirect to an external CRM application.

    At the Asterisk level, if you have not already done so, create a queue “999” with the correct parameters to be monitored by Wombat - see Queue end-points in Wombat . Then edit your extensions_custom.conf file so that you have an extension “1235” that leads to the queue:

       [from-internal-custom]
       ….
       exten => 1235,1,Answer
       exten => 1235,n,Set(CALLERID(num)=#${ID} ${PERS})
       exten => 1235,n,Goto(from-internal,999,1)
    

    This rewrites the incoming caller-id for the queue to e.g. “#1234 John_Doe”, so this is what the agent sees - even before the agent pop-up is opened. This also is recorded in QueueMetrics, so this is what you will see when you run call reports. Note that if you run FreePBX you cannot call the queue directly using the Queue() command but you’ll have to go through its dialplan in order to have all parameters correctly set.

    In QueueMetrics, set the following properties in configuration.properties:

        realtime.agent_autoopenurl=true
        default.crmapp=
    

    Then create a queue “999” and set its Queue URL to:

        http://10.10.5.10/lenz/wombatPopup.php?caller=[C]&unique=[U]&agent=[A]
    

    This tells QueueMetrics that it has to enable a screen-pop for calls coming in through that queue.

    Now log on to WombatDialer; create an EndPoint of type Queue set for queue 999, and its entry point in the dialplan to 1235@from-internal-custom. Do not forget to set the “Boost factor” to 1 and the “maximum queue length” to 2.

    Then create a campaign called “QmSample” that idles on termination.

    Set the trunks, the EP we just created, add no lists and define any reschedule rules you need. The end result should look like the following:

    Now start the campaign. It will go in status IDLE immediately, as it has no numbers to dial, and you will see it all yellow in the Live page of WombatDialer.

    At this point, it is time for your agents to log in in QueueMetrics. Have them log-in to their Agent’s page, and from there log them on to queue 999. At this point, make sure that each agent’s browser allows QueueMetrics to open pop-up windows (this is usually disabled in modern browsers).

    Now, for each call you’d like to be started, send an HTTP request to WombatDialer that looks like the following one (we do this through the Linux shell, but there is nothing preventing you to script this in some other way:

     curl "http://10.10.5.18:8080/wombat/api/calls/index.jsp
           ?op=addcall
           &campaign=QmSample
           &number=2000136
           &attrs=ID:2301,PERS:John_Doe"
    

    Note that you associate two parameters: ID that is a unique id used by your CRM and PERS that is the called person’s name. You could also add additional parameters you may need, e.g. a person’s class or their thelephone number.

    What happens now is that when the call goes through, its caller-id is rewritten as “#2301 John_Doe” as soon as it reaches Asterisk. When your agent receives the call, they will reload the agent’s page and the pop-up will be immediately opened.

    In the pop-up, you parse the caller field and extract your CRM id, so you can use this for your external application to display the correct data.

    From the agent’s page you can also manually open other forms for recent calls. The agent will also see the person’s name in QueueMetrics, so this makes their life easier. The agent may also set a manual status code for each call through QueueMetrics, e.g. if the sale was successful or not, and this lets you measure your agent’s performance. You may also use QueueMetrics’s extensive QA monitoring features to analyze calls and improve the process.

    Analyzing outbound campaigns

    If you set your campaign to have QM_COMPATIBLE logging, you will find data abpout two different queues on QueueMetrics:

    • If you run a report for queue “QmSample”, you will see all calls that Wombat attempted - the successful as well as the unsuccessful ones. This is basicall the activity that WombatDialer performed and the actual telephone usage durations. In a real-life scenario, the vast majority of calls will be unanswered.
    • If you run a report for queue “999”, you will see activty about calls that were successfully connected and were actually queued to be answred by agents, You would expect to have a very low unanswered rate here - if it is high, it means something is not working as expected. You will of course have some lost calls, e.g. because the called person hung up before the agent was connected.
    • The difference between the number of successful calls in “QmSample” and the total number of calls in “999” are calls that were hung-up before reaching the queue, e.g. during an initial IVR phase.