Frequently Asked Questions on QueueMetrics Live (FAQs)

Here is a list of solutions to common problems encountered when running QueueMetrics Live.

QueueMetrics Live

QueueMetrics reports

QueueMetrics real-time page

Configuring Agents

QueueMetrics configuration

License-related issues

Can I remove or add agents to my QueueMetrics-Live instances?

You are always free to change the number of agents in a QueueMetrics Live instance - the total flexibility is one of its big advantages compared to on-prem solutions.

If you want to add (or remove) agents to QueueMetrics-Live, it can often be done without any payment, by adjusting the expiry date of the instance so that the same amount of agent-days will be left.

For example, say that you have an instance that has two months left on it and currently has 10 agents; if you want to increase that to 20 agents, we will simply adjust the expiry date to one month from now and set it to 20 agents.

If you are on a recurring subscription, we will update the number of agents immediately and change the amount charged on the next recurring payment. It is possible that the credit card processor will ask you for authorization if the number of agents is increased over 15-20%.

The only limit is that you cannot have less than 5 agents per instance, so you can't reduce an instance to less than 5 agents.

Please be aware that, in case of reduction, you won't be able to generate reports that include data for a number of agents that is higher than your current limit.

For example, if you downsize from 20 to 10 agents, you will not be able to run a monthly report that includes all of the previous 20 agents. So we usually suggest to wait a bit of time after when you decommission an agent and when you downsize the instance, as not to affect your current reporting cycle.

Permalink - Table of contents

How to configure outgoing emails with Gmail

In order to use your Gmail account in order to send automated email reports, configure QueueMetrics as follows:

default.smtphost=smtp.gmail.com
default.smtpport=465
default.smtpfrom=username@gmail.com
default.smtpuser=username@gmail.com
default.smtpassword=verysecret
default.smtpssl = true

Permalink - Table of contents

What's the difference between Agents and Users in QueueMetrics?

In QueueMetrics you define agents, every agent represent a person in your call center.
You want to define a new agent:

  • Asterisk agent code: agent/321 (this has to follow the pattern: agent/somenumber)
  • Agent description: John Doe (this is the human-readable translation; in your report you'll get the real name, not the agent code)

As well you'll need to define a new user:

  • Login: agent/321 (the same of the agent)
  • Password: password
  • Real name: John Doe
Why we created an user and an agent with the same name?

Users and agents are different in QueueMetrics: a user is an access credential to QueueMetrics, it doesn't have to be an agent, it could be just someone that can run reports or an admin user.
An agent, instead, doesn't need to be necessarily an user; if your agents are static in the queues and always use the same phones, you'd want to define the agents in QueueMetrics just to translate phone codes (e.g. SIP/3321) in a readable name in reports.

Permalink - Table of contents

Why do I see agents logged in twice - under their own name and as Agent/name?



If you see agent logged in twice, once under their correct name and a second one under the name "Agent/agent name", often with a difference of a few seconds. Sometimes you will see that the correct name will log off at the end of the agent session, while the "Agent/agent name" will linger on for a while.

This is caused by not having "Friendly names" set - see Why do agents on a call show up with a different name? to fix this.

Permalink - Table of contents

I use FreePBX - why do agents on a call show up with a different name?



When setting up FreePBX, you can tell it to either use the default Extension mode or use the "User & Device" mode. While in Extension mode the user (agent) code and thir extension match, in U&D mode they are independent.

When running in this mode, agents are logged in one way when they join a queue (usually with their extension code) and in a different way (using their user name) when they receive a call. So QueueMetrics sees the equivalent of "Extension 203 logged on at 9:30 and John received a call at 9:31" and cannot natively make sense of it, as it is never logged that extension 203 goes under the name John. That's why you see agents logged under one name and handling calls under a different one.

In order to handle this, QueueMetrics has the concept of "Friendly name", that is a name that you configure on the agent configuration page that will be mapped to the same agent code. So, if you set up a friendly name of "John" for Agent/203, whenever QueueMetrics finds a "John" it will silently rewrite it as Agent/203. This way, calls are attribuited correctly and agent sessions are counted correctly.

You can have multiple friendly names for the same extensions. Just enter them separated by a pipe character. This is needed in case you changed the User name during the period under analysis.

Please note that agent session statistics will be incorrect if you do not set Friendly Names when they are needed. In general, anyway, if you need to keep track of multipl epeople working from the same extension, QueueMetrics Hotdesking mode will be a better approach.

See also:

Permalink - Table of contents

I don't see agent sessions without calls

It is possible that when running a custom report, selecting the agents name, the queue and the date and navigating to the "Agents" tab, QueueMetrics shows no information.
This happens because QueueMetrics considers an agent session without activity a logging anomaly as it is very unusual for an agent not to take at least one call throughout a shift.

However, QueueMetrics can be configured in order display these agent sessions where no calls were taken by the agent, by setting the following property to TRUE:

default.useRawAgentSessions=true

If true, shows all agent sessions. If false, shows only agent sessions with at least one call handled. (The property defaults to false).

Permalink - Table of contents

Why do I get a message "The report exceeds the number of licensed agents"?

This error is displayed when QM senses that there are more than the maximum licensed number of agents in the dataset it is processing.

This may be caused by three reasons:
  1. You have more agents than your license is valid for (and in this case you should purchase an elargement), or
  2. You have less agents than your license is valid for, but agents appear under multiple distinct codes, or
  3. The report covers current and past agents, that in total are more than the licensed number of agents.
Cases #2 and #3 happen if you change your agent codes, or use new agent codes to supplement older ones. From the point of view of QM, each distinct agent code is a unique agent, so it is counted against the license limit.

You can easily check which one is your case by requesting an unlimited demo key and running the same report that displays the error; go to the "Agents on queue" report and count the number of distinct lines that appear there.

What you can do to mitigate this problem:
  • Purchase a larger license key
  • If you changed your agent numbering plan, avoid running reports that overlap both agent sets
  • Try and run reports that do not include more than the licensed agents
  • Edit the dataset manually to use the same code in case the same agent appeared under different codes (e.g. sometimes as Agent/101 other times as SIP/101).

Permalink - Table of contents

Why agents that do not logon are not a good idea

Many call-centers prefer to have agents always logged on, that is, the queue always rings the same set of phones 24/7. This is apparently easier to set up, as agents do not have to log on when they start working and off when they stop.

We advise against this method of managing agents, because:
  • Even if your phones are members of the queue 24/7, it is possible that some of them occasionally go unmanned. As Asterisk has no way of knowing which phones are to be used and which are not, it will simply try and ring them in sequence; if nobody answers, it will try a different one. This raises the wait-time for the callers without giving you any benefit. You may also have callers struck for long periods on queues where nobody answers, because there is nobody to answer but Asterisk is not aware of this!
  • As you have extensions and not people as end-points for your queue, it is very hard to tell who did what, whose performance was good and who answered the phone versus those who did a poor job. They all end up in the same statistics. By having people log on, it is easy to distinguish who did what. It is also easy to tell who is available at a given moment, even remotely.
  • As a result of both bullets above, agents know they are reponsible for what they do and know their behavior is monitored; so they have all the right incentives to do their best.
  • Agents that do not logon at every shift do not appear reliably on the RealTime monitoring in QM - see below.
If you still do not want to use agent logons, QueueMetrics will nevertheless monitor reliably your traffic; the Agents page and statitics that depend on agent sessions will be blank or may yeld meaningless results.

See also:

Permalink - Table of contents

What is the time period considered for real-time?

When QueueMetrics has to compute the Real-Time report, it tries to build the current situation based on what happened recently - normally since the last midnight. This usually works fine in the common case where all agents stop working at night and start working by logging on in the morning. On the other side, this produces incorrect results if your call-center works over the 24 hours, because at midnight by default all agents appear to be logged off.

This choice was made in order to minimize database searching for QueueMetrics, and it works just fine in the majority of call centers. There are a few cases where this choice may have to be changed:
  • If your call center stops daily, but not at midnight, you should tell QM the time when you expect all agents to be logged off. If e.g. at 4 AM you are sure all agents are logged off, you should set:
    realtime.startHour=4


  • If your call-center never stops, but agents work in shift of 6 hours, you should use a "sliding window" instead; this determines the maximum lookback based on a number of hours before now (make it 1.5x to 2x the length of the shift).
    realtime.startHour=s8 Of course, the larger the sliding window, the more data QM has to evaluate every time it produces a realtime report, so it will use more RAM and CPU.
  • If your agents are always logged on, you should ignore the statuses as reported by QM, as QM has no way to reliably know if they are available or not. QM will generally log them on as they take calls within the given time window. See below for a detailed explanation of why it is not a good idea to have permanent agents.
See also:

Permalink - Table of contents

Figures do not match when running hourly versus daily reports

Imagine you run a report for Aug 25th, queue A, between 7 and 8 - it says there are 150 answered calls.
You run it again, between 7 and 13 and look at the hourly statistics - now it says there are 154 answered calls between 7 and 8.
What happened? that's simple - between 7 and 8, some calls were queued but not yet answered - so you are going to find them, but on the "Lost" page and with status "Ongoing".
You run the report again between 7 and 9, and now you see that the call was answered - because it was answered after 8 am.

If you run a report between 7 and 8, QM only sees data that cam between 7 and 8 - not what happened before of afterwards. It's like being at 8am and asking for future data. If you want to see what happened when you have a full day of data, run a report for a full day and look at the hourly breakdowns.

Permalink - Table of contents

Transfers from the queue are not reported in QM

If your agents on a queue use to transfer calls out to other callers or to other queues, you may notice that this is not reported correctly by QueueMetrics. You may also notice that if you use agent channels, an agent stays idle after the transfer until the transferred call is over.

Unfortunately this is "by design"; this is because when you use the Attended transfer button on the agent's phone, the main PBX is not notified that the call is "handed-over", so it still thinks it's connected to the original agent. The official documentation says that "transfers performed by SIP UA's by way of a reinvite may not always be caught by Asterisk [...] The only way to be 100% sure that you will get this event when a transfer is performed by a queue member is to use the built-in transfer functionality of Asterisk".

So the only way there is to handle this case is then to use so-called "Unattended transfer", that is, setting the t option in the queue and then having your agent press # to start a transfer to a different extension. Unfortunately, this does not give you Attended transfer, that is, speaking to the receiver before handing over the call.

Our real-life workaround is to use the "#" unattended transfers of Asterisk to transfer calls only after having opened up a parallel conversation to negotiate with the receiver. We know it's sub-optimal, but this has been shown to work.

Permalink - Table of contents

Using multi-stint mode in reports

When QueueMetrics run an activity report, its basic "unit of measurement" is the queue; that is the activity that your call made on a specific queue. This may lead to a situation that is harder to understand if you have spill-over queues in place, that is, if a call is not handled in one queue it is moved to a different one.

In order to address this problem, queueMetrics implements a multi-stint analysis mode, where mutiple passages on different queues are "joined together", like in the following example. Imagine this call:
h 10.00.00 enters queue 1
h 10.00.59 exits queue 1
h 10.01.00 enters queue 2
h 10.01.59 exits queue 2
h 10.02.00 enters queue 3
h 10.02.30 answered on queue 3
h 10.03.00 caller hangs up
With single stint mode you would see:
h 10.00.00 lost call on "queue 1", waited for 59 seconds
h 10.01.00 lost call on "queue 2", waited for 59 seconds
h 10.02.00 answered call on "queue 3", waited for 30 seconds, duration 30 seconds
With multi-stint mode you would see:
h 10.00.00 call enters on queue 3, waits for 2:30, duration 30 seconds
and by clicking on the call detail, you get the whole history.

In order to have multi-stint work correctly, you should include ALL the queues that the call was handled upon in the same report - otherwise it will not find out where the call passed.

Of course, in real-life you can run both multi-stint and single-stint analyses when querying the performance of your call-center; you use multi-stint to see the performance from the point of view of the caller, and single-stint to see what happended from the point of view of the providers, e.g. service groups.

Permalink - Table of contents

How do I make some queues visible by some users only?

In order to make sure that some users (e.g. supervisors) can only see their queues, you should use QM's security model. When you protect something with a key, this means that you protect it (physically speaking) with a lock that opens if the user holds that key in his keyring. You know that eash user has a keyring, that is the sum of the keys that belong to his current class plus the keys that he individually has.

So, if you have a number of supervisors and a number of queues, you could protect each queue individually with a different key, and then give each supervisor individually the required key.

For example, you can do this:
  • queueA -> key KA
  • queueB -> key KB
  • queueC -> no key
  • queueD -> key KD
  • queueE -> key KE

  • supervisor Alice -> keys KA and KD
  • supervisor Bob -> keys KB and KE
When they log on, Alice sees queue A, queue C and queue D. Bob instead will see queue B, queue C and queue E.

Please note that if you have an aggregate queue, only the key protecting the aggregate queue will be ckecked, i.e. the checks on the members will NOT be performed (so you can have an aggregate queue that behaves differently in security terms from the set of its members, if you need it).

Permalink - Table of contents

Why does the Agent report show all Agent levels as "Undefined"?

The reason is usually pretty simple - because they are undefined. Whenever QueueMetrics runs a report on a queue, it loads the "agent level" information from that very queue definition that is being run - this means that if you use the same queue multiple times, e.g. once by itself, once as a member of an aggregate queue, you'll have to set the agent priority for all cases.

In order to assign agents to a queue, you follow the following procedure:
  • Go to the queue editor and select the queue you're reporting upon (from the main page, click on "Edit queue")
  • Click on the agents icon for the queue you intend to work on (that's the middle icon on the right with little people showing) - you should be driven to a page with "Main", "Wrap" and "Spill" columns
  • Click who is who for each level - "Main" is the first line level, "Wrap" is a backup for Main, and "Spill" is the backup for Wrap.
Of course, in order for this to produce meaningful results, you should set up penalities accordingly in the queue definition for Asterisk.

Permalink - Table of contents

How to monitor multiple queues at once

To monitor multiple queues at just create a composite queue, that is a queue which definition is a set of other queues; they can be inbound, outbound or mixed. To do this, log on as an administration, click on "Edit queues", then fill in the form on the bottom of the page called "Add new queue".

Fill-in the following form fields:
  • Alias is the name you want your composite queue to be shown as in QueueMetrics
  • Queue(s) must be filled with a set of Asterisk queue names separated by the pipe symbol (like A|B|C to monitor queues A, B and C at once)
Save and go back to the home page. Now you are ready to test your composite queue on both historical and real-time reports.

In this way you can run a report for a composite queue and see the details of a number of queues at once (this is very useful e.g. for real-time monitoring).

We also suggest creating a queue named "00 All" that will always appear as the first in the drop-down queue selection box and will allow easy access to the overall monitoring.

Permalink - Table of contents

Logged-on agents disappear at midnight

If your agents work in shifts around midnight, with a plain QueueMetrics installation you will see that they will "disappear" at midnight from the Realtime screen, as if they logged off, though they will continue receiving calls (and calls they receive will be reported correctly). Calls handled over the midnight (i.e. started before the midnight and ending after the midnight) may seem to have been dropped as well from the realtime screen.

This is because QueueMetrics will consider agent logon information starting from the last midnight, and this arrangement works great for call centers working during the classical 9-to-5 office hours. If you need a different arrangement, you can use a "sliding window" model, where QM will look for information during a time period you define. For example, to set a sliding window of 12 hours, you would set the following property:

#The hour of the day to start real-time monitoring or sXX: sliding window of XX hours
realtime.startHour=s12

You could also set it to "s18" or "s24" to look back 18 or 24 hours respectively - of course, the longest this period, the more data QM has to process each time.

Permalink - Table of contents

What do the fields named UNK and BSY mean?

In the realtime view, there are two fields that may look puzzling: BSY and UNK.
  • BSY is the number of agents that are currently busy on a different queue.
    Like, if you have an agent that is active on queue A and queue B, when he is on conversation in queue A will be counted as BSY on queue B, as he is not actually ready to take calls in queue B.

  • UNK are unknown agents that are speaking on the queue.
    When QueueMetrics tries to determine how many agents are ready for a queue, it takes the total number of known agents and subtracts those who are speaking, those who are on pause and those who are BSY. If an agent shows up in a queue and QM does not know that the agent is working on that queue, the agent is counted in the UNK field.
    If you want to avoid having UNK agents, make sure that your QM agents-on-queue configuration actually matches the underlying Asterisk configuration.

Permalink - Table of contents

QueueMetrics Training

 Useful Links

Try & Buy!

More Questions ? Contact Us!

Attend the next Free Webinar

Looking for an on-premise solution?

FAQs

Facebook Twitter Linkedin Pinterest Youtube Slideshare RSS

Loway Logo

Copyright ©Loway 2024 · all rights reserved · Terms of service · Privacy policy

All trademarks, service marks, trade names, product names and logos appearing on the site are the property of their respective owners, including in some instances Loway. Any rights not expressly granted herein are reserved.

Facebook Twitter Linkedin Youtube RSS

Network Status: