QueueMetrics integration

QueueMetrics is a powerful call-center reporting suite that can be used together with WD for extensive and accurate reporting of the whole call-center activity (inbound and outbound).

QueueMetrics offers:

  • strong analytic capabilities, with over 150 elements computed

  • live monitoring of agent status

  • quality review and assessment of calls

  • access to call recordings

  • a powerful agent panel

  • …​and many more features.

QueueMetrics can be found at https://www.queuemetrics.com

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

Installation

Both QueueMetrics and WD can be installed on the same server, that may or may not be the same server running the PBX. If installed automatically through yum, they will share the same Tomcat instance.

As QueueMetrics is a CPU- and memory-intensive application (as you could run reports on millions of calls at once) it might be better to put each application on its own virtual or physical machine in order to avoid slowing down WD - for which timely responses to what is happening on the PBX are paramount.

Understanding QueueMetrics integration

In order to turn on QueueMetrics integration, you simply need to enable the "QM_COMPATIBLE" logging option for WD campaigns. This will tell WD to produce a log on each Asterisk system that closely resembles the one created by inbound calls on queues.

This log will be created with the following peculiarities:

  • the name of the queue is the name of the campaign - that is the name that needs to be configured in QueueMetrics

  • the "agent" name answering the call corresponds to the end-point being used to place the call

  • the extended call status reported to WD will be logged

  • attributes will be logged (see below)

  • all calls have the TAG set as their list

The most common case of QueueMetrics integration happens when you use an end-point of type QUEUE to have outbound calls routed to agents through a queue. In this case, you will have two different queue entities producing data for QueueMetrics:

  • The queue that matches the campaign: here you will see all calls that WD attempted - the successful as well as the unsuccessful ones. This is basically the activity that WD 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 the physical queue used, you will see information about calls that were successfully connected and were actually queued. 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 the campaign versus the total number of calls in the physical queue is due to calls that were hung-up before reaching the queue, e.g. during an initial IVR phase.

When you use a queue for inbound, it is often better to avoid playing music-on-hold and to offer ringing instead.

Logging of attributes

Attributes can be logged to QueueMetrics as IVRs, FEATURES and VARIABLES.

  • Features are ideal to track specific yes/no actions in the call

  • IVRs are perfect to track IVR sequences, and will be extensively reported by QueueMetrics

  • VARs are perfect for unstructured data you want to see associated to a call.

As you generally do not want all available attributes to be sent to QueueMetrics, you have to cherry-pick the ones you want logged by entering them in the Attributes to be logged as QM variables field in the Campaign definition.

In order to determine how an attribute is to be logged, you will prepend the name of the attribute with a sigil specifying the way it is to be logged.

  • No sigil: the attribute is a VAR

  • Dollar ($) sigil: the attribute is a feature

  • Bang (!) sigil: the attribute is an IVR

So in the following set of attributes:

NAME $MYLIST OPTION !MYIVR

The attributes NAME and OPTION will be sent as vars, MYLIST will be a feature and MYIVR will be an IVR.

All call attributes can be logged; so everything that comes from the current list, plus campaign attributes, plus incoming attributes read from Asterisk. Attributes are logged at the beginning of the call and when the call is disposed (if changed). The call tag is automatically logged and matches the list name.

Logging of attributes on direct queue end-points

If WD is working with a queue in direct mode (that is, when calls are sent to agents by the queue and not by WD itself), and QM integration is turned on:

  • As soon as the "synthetic" call is started, or when attributes are set, then they will be logged on the synthetic call. This works for reporting, but is not useful if you have agents using QueueMetrics who are working on the queue.

  • As soon as an agent is connected (but no sooner), all previous attributes are logged on the queue as well. So in QueueMetrics, they will be available for screen pops or in general on the agent page. This happens automatically.

Any attributes set after an agent is connected will be logged to both calls.

Real-time monitoring

You will be mostly interested in monitoring only the physical queue - here actual agent activity is displayed, and agent presence information (log-ins, log-offs and pauses) is immediately available.

As all calls have their TAG set as the originating call list, it is easy to see the relative efficiency of lists.

Reporting

You might be interested in running reports on both the campaign and the physical queue in order to gather information on actual PBX usage times versus agent activity.

Using the agent’s page

QueueMetrics offers an interesting Agent’s page, from where the agent can get a screen pop to an external application (e.g. a CRM) when they receive an inbound call.

If you use the telephone number as the main key that is used to connect to an external CRM, then this will work natively with the basic WD integration, as the caller-id is usually preserved.

You may want to have finer control on the CRM pop-up by tracing not only the number dialed, but also the campaign ID or some of the variables that WD sends along the call. This can be achieved by rewriting the caller-id field in Asterisk and using a decoder script that will in turn launch the actual CRM application. An example can be found in the Cookbook.

Using the agent’s page for preview dialing

WombatDialer includes an HTML preview panel that lets your agents preview, process or skip calls.

Previewing number

It can be reached at the URL 'http://myserver:8080/wombat/agents/rd_pop.jsp' and accepts the following parameters:

  • agent: the channel being used, as present on the queue. It must match exactly the Asterisk id.

  • url: an URL that can be opened for this call. Note that special characters must be quoted, e.g. "?" must be written as %3F and "&" will appear as %26. Any variables will be quoted when written like "<NUMBER>"

  • inset: if 0, the page will display a list of known variables for this call and a link to the URL. If 1, the URL will be opened within an IFRAME right in the page.

  • baseUrl: if Wombat displays a timeout trying to display this page, then you must set this parameter to the default URL for Wombat as seen from Wombat itself, e.g. 'http://127.0.0.1:8080/wombat'

For example, to have calls opened from the agents' page in QM, you would use one of the programmable buttons to link to WD, like in:

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/sugarcrm/index.php%3faction=UnifiedSearch
                       %26module=Home<%26query_string=<NUMBER>%26name=<NAME>
                  &inset=1

The code above will link to WombatDialer on 10.10.5.30, will replace the agent code in the URL and will link to an embedded instance of SugarCRM running on server 10.10.5.31 passing along the number to be called.

Using the agent’s page for regular dialing

WombatDialer includes an HTML panel to inquire/display the status of a live call. This integrates nicely with QueueMetrics, as QueueMetrics allows for recalls to be scheduled right from the Agent’s page.

…​

It can be reached at the URL http://myserver:8080/wombat/agents/rd_pop.jsp and accepts the following parameters:

  • agent: the Agent’s identifier.

  • wid: the WombatID. It can be written with a prefix (as it appears in QM logs) or without them.

  • unqid: the Asterisk UniqueID for the call.

For example, you could use a Queue URL like the following:

http://myserver:8080/wombat/agents/live_call.jsp?agent=[A]&wid=[U]

To have the page opened in Icon. If you are taking the ID from an entry that is logged by Wombat you should use the "wid" code; if instead you are reading from a genuine app_queue entry you should use "unqid" instead.

WombatDialer to QueueMetrics ephemeral-data bridge

wd_qm_bridge.py is a small Python 3 daemon that periodically scrapes campaign and queue progress attributes from a WombatDialer instance via its /api/campaigns/vars endpoint and pushes them to QueueMetrics as ephemeral data via insertEphemeralData.do. The values then become available to the QueueMetrics wallboard (and to anything else that reads ephemeral data) as live, expiring key/value pairs.

The bridge fetches the configured list of queues at a fixed cadence, maps each WombatDialer row (attribute, queue, agent, value) straight into a QueueMetrics attribute (the campaign field is dropped; the deployment is assumed not to produce collisions on (attr, queue, agent)), and pushes the batch with a validity of three times the polling interval. If a poll cycle fails for any reason — network error, HTTP error, malformed response, authentication failure — the script prints a full stack trace to stderr and exits with a non-zero status. systemd is expected to restart it.

It can be found within WombatDialer, under WEB-INF/misc/wd_qm_bridge.

System requirements

  • Python 3.6 or later

  • Standard library only — no third-party packages required

  • systemd

Configuration

Every option can be supplied as a command-line flag or as an environment variable. The flag wins if both are set.

Flag Environment variable Meaning

--wd-url

WD_URL

WombatDialer base URL, e.g. http://127.0.0.1:8080/wombat. Required.

--wd-token

WD_TOKEN

WombatDialer auth_token_id. Optional; leave blank if WombatDialer is not configured with auth tokens.

--qm-url

QM_URL

QueueMetrics base URL, e.g. https://my.queuemetrics-live/somecustomer. Required.

--qm-user

QM_USER

QueueMetrics login. The user must hold the ROBOT and EPHEMERAL_WRITE keys. Required.

--qm-password

QM_PASSWORD

QueueMetrics password. Required.

--queues

QUEUES

Comma-separated list of queue names to scrape, e.g. 200,300,500. Required.

--interval

INTERVAL

Polling interval in seconds. Default 30. The bridge sleeps this many seconds after each successful push, so a slow upstream is not hammered. QueueMetrics validity is set to 3 × interval.

Installing manually with systemd

The example below assumes the script lives at /opt/loway/wombatdialer/wd_qm_bridge and configuration is read from /etc/defaut/wd_qm_bridge. Adjust paths to taste.

If you installed WombatDialer via RPM, you can copy the script from /usr/local/queuemetrics/wd-current/WEB-INF/misc/wd_qm_bridge/.

  1. Copy the script into place:

    sudo mkdir -p /opt/loway/wombatdialer/wd_qm_bridge
sudo cp wd_qm_bridge.py /opt/loway/wombatdialer/wd_qm_bridge/
sudo chmod 0755 /opt/loway/wombatdialer/wd_qm_bridge/wd_qm_bridge.py

  2. Create the environment file with your settings:

    sudo tee /etc/default/wd_qm_bridge > /dev/null <<'EOF'
WD_URL=http://127.0.0.1:8080/wombat
WD_TOKEN=
QM_URL=https://my.queuemetrics-live/somecustomer
QM_USER=robot
QM_PASSWORD=robotpwd
QUEUES=200,300,500
INTERVAL=30
EOF
sudo chmod 0600 /etc/default/wd_qm_bridge

  3. Install the systemd unit (the wd_qm_bridge.service file shipped alongside the script):

    sudo cp wd_qm_bridge.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now wd_qm_bridge.service

  4. Check that it is running and look at recent logs:

    sudo systemctl status wd_qm_bridge.service
sudo journalctl -u wd_qm_bridge.service -f

On any error the bridge exits with status 1; Restart=always and RestartSec=5s in the shipped unit will bring it back five seconds later.

Running it manually for a test

Before letting systemd manage the bridge, it is usually worth running it by hand from a shell to confirm credentials and connectivity.

python3 wd_qm_bridge.py \
  --wd-url http://127.0.0.1:8080/wombat \
  --qm-url https://my.queuemetrics-live/somecustomer \
  --qm-user robot \
  --qm-password robotpwd \
  --queues 200,300,500 \
  --interval 30

Add --wd-token <your-token> if WombatDialer is configured with auth tokens.

You should see lines like:

[2026-05-11T10:42:00+0000] Starting WD->QM bridge: queues=['200','300','500'] interval=30s validity=90s
[2026-05-11T10:42:00+0000] WD URL: http://127.0.0.1:8080/wombat  (token=unset)
[2026-05-11T10:42:00+0000] QM URL: https://my.queuemetrics-live/somecustomer  user=robot
[2026-05-11T10:42:01+0000] Pushed 12 attribute(s) from 12 WD row(s)

Press Ctrl+C to stop. If anything goes wrong — wrong URL, bad credentials, network unreachable — the script will print a stack trace and exit non-zero, which is exactly what systemd will see in production.