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 http://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 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 us 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.