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

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

     
  4. News and User Manual… at last

    We have been working for a while on improving the WombatDialer experience. So in versions 0.5.0 to 0.5.7 we fixed many glitches in the user interface and made the user experience way smoother to follow. We thank the many people who tested WombatDialer and posted error reports so we could improve (you know who you are!).

    WombatDialer has been in production use in three medium sites for a couple of months now (adding to our initial pilot site), having 50 to 100 agents each, and has been exensively used as a robodialer and a power dialer. So we expect it to be essentially stable and usable. No major issues have been found in the dialer itself so far. We welcome all comments and suggestions.

    As an added benefit, we now have an initial draft of the User Manual online - it should be enough to document the basic concepts and the APIs in a systematic fashion. You can find it in HTML or PDF formats on the manuals page.

    We had a lot of good feedback and suggestions at the Astricon 2012, so stay tuned!

     
  5. Helping wombats - one carrot at a time

    You know how it goes; so many good ideas in real-life end up being limited by the amount of funds you can raise to implement them. That’s why Vicky, the energetic new president of “Friends of the Wombat”, called you. “Friends of the Wombat” is a non-profit institution that helps wombats in need, but their activities are limited by the rising cost of carrots; so they decided to start a volunteer fund-raising campaign.

    What they would like to do is to call a list of known contacts that expressed an interest in wombats and ask them to make a donation. They started doing this manually with paper and pencil, but getting to a lead is really tiring and time-consuming – their volunteers spend most of the time dialling numbers and it is really hard for them to get through to somebody who is interested.

    After a good cup of green tea, what you propose to do is to use WombatDialer to automate the process by dividing it into multiple stages:

    • Create an electronic list of those leads
    • Leads from their list are dialled
    • If the call is answered, a message is played that explains what the campaign is for
    • If the callee is interested, they press 1 to be put in conversation with a volunteer that will explain how to send a donation.

    This setting leads to two huge efficiency boosters:

    • As numbers are dialled automatically and error conditions are handled behind the scenes, a lot of drudge work with paper and telephone keyboards is automated; no more post-it notes to recall a busy number!
    • As they noticed that about 50% of the calls made manually result in calls to busy numbers or numbers where nobody picks up, and that only 50% of the callees are actually interested after an initial interview, they expect that 75 calls out of every 100 they make can be screened out automatically. So if they have 4 volunteers on shift, WombatDialer could start 16 calls at once on average, and have all of our volunteers busy most of the time with people who are actually interested in contributing.

    In order to implement such a campaign with WombatDialer, we start by creating a call queue that will hold our agents and will send them calls. You can use any Asterisk GUI to do this - in the example below we use Elastix, but you can choose the one that suits you best.

    We go to Queues -> Create new, set the extension for the queue as 999, enter any name you want, and look on the settings below so that:

    • Strategy is set to “rrmemory”
    • Queue events: yes (this is very important – if you don’t do this Wombat won’t be able to observe your queue at all).
    • Autofill: yes (all free agents are assigned calls at the same time)

    If you create a queue manually without using a GUI, configure it with the parameters below so that WombatDialer can observe it.

    [999]
    autofill=yes
    eventmemberstatus=yes
    eventwhencalled=no
    maxlen=0
    strategy=rrmemory
    

    Now we create a custom piece of dialplan to be called as an end-point for calls that connect successfully.

    [friendscampaign]
    exten => 100,1,Answer
    exten => 100,n,Playback(campaign_message)
    exten => 100,n,Read(type,,1)
    exten => 100,n,GotoIf($["${type}" = "1"]?ok)
    exten => 100,n,Goto(1)
    
    exten => 100,n(ok),UserEvent(CALLSTATUS,Uniqueid:${UNIQUEID},V:1)
    exten => 100,n,Queue(999,,120)
    

    (In order to make this example shorter, we assume you have a baisc familiarity with WombatDialer concepts such as Campaigns, Servers, Trunks and End-points. If you don’t, see the tutorial at http://blog.wombatdialer.com/post/23597570852/tut-idle )

    Now log-in to WombatDialer and create a new End-Point:

    • Type: QUEUE
    • Queue: 999
    • Max channels: 10
    • Boost factor: 2.0
    • Max waiting callers: 2

    This means that WombatDialer will try and place two calls for each agent available, but never more than 10, and will stop placing calls if there are two or more people waiting in queue. We expected to use a boost factor of three to four given the previous statistics, but it is better to start with a small figure and grow it if needed.

    It is important to understand the impact of different boost factor settings; in general having more calls made than agents may result in calls waiting in queue when all of your agents are busy (in call-center parlance this is usually referred as “nuisance calls”). WombatDialer tries to minimize the impact of this case by continuously monitoring the number of calls waiting on the queue and avoiding placing new calls if there are too many. If you don’t want to have cases where calls are not immediately connected to an agent, you should leave the boost factor to 1, that is, place no more calls than available agents. The trade-off here is that agents end up being under-used, as they have to wait for a successful call to come in.

    We then create a test trunk, upload a list of test numbers and create a campaign called “friends” as in the previous examples; we now start the dialer and start the campaign from the Live page. When we start running it we notice that it does not seem to work – the campaign is running but no calls are placed. How comes?

    If we reload the current Dialer status, we see that it is saying that the queue has 0 channels available – this is because there are no agents on the queue.

    If we log an agent on (e.g. by entering 999* on Elastix), we will notice that WombatDialer starts dialing. If you pause an agent or log him off, WombatDialer will immediately react and adapt to the changed number of available end-point channels.

    Another thing that we do is to track (through a status code) which callers ask for being put in contact with a volunteer – this allows easy inspection of what goes where from the Campaign Report panel.

    Now all we have to do is to set our campaign to use an actual telephone trunk and upload the “real” list of numbers and we are ready to go – it’s time to buy some new carrots for our wombats!

    Understanding statistics

    If you run a report of our campaign with a queue analyzer like QueueMetrics, you will have two different views of the campaign:

    • if you analyze the queue “friends” (the one that matches the name of your WombatDialer campaign) you will see the total “external” system activity – all calls placed on the campaign are tracked, and the wait time matches the external wait time (that is, the time between the dial request and a successful connect). All calls appear to be connected on the end-point, as you could have multiple ones assigned to the same campaign.
    • if you analyze the queue “999”, you will see the human side of action – how many calls were queues for humans to interact with, how fast they were answered and by whom.

    Further expansion

    • You can use the same end-point in multiple parallel campaigns, if needed.
    • It is possible that your campaign reaches someone who is interested but is currently doing something else so does not have the time to speak to your volunteers. They could tell you by hitting 2 – you could add a Reschedule Rule that reschedules the call in a few hours.
    • You could easily generate personalized messages instead of one single rescorded message by using a Text-to-Speech synthesizer, as in example http://blog.wombatdialer.com/post/24187267017/drstrangelove

    Please note that outbound telemarketing, whether it is of the good or evil persuasion, is regulated by your local law, so be sure you comply to its terms before you start calling millions of people!