Queue Manager Enterprise (QME) is the enhanced ACD (Automatic Call Distribution) application that allows effective management of incoming calls without the need of expensive and complex call center systems. It allows accepting and managing high volumes of incoming traffic, keeping the calls in queues and playing music while waiting for an operator to become available.
QME is the perfect product for inbound telephony services: front-end operators, help desks, assistants. QME is mainly focused on:
The web interface enables the administrator to design in a few steps either simple queuing services or more complex scenarios, including calendar schedules, backup routing, overflow treatments, leveraging the wide set of available features and the flexibility of the application.
Queue Manager Enterprise is a voice application leveraging its internal SIP/H.323 stack. Incoming calls are accepted, answered and kept in queue by the application that applies the scheduled treatments and replay the configured voice prompt/music to the callers.
Once an agent/target becomes available, the application transfers the call to the target, so that the voice resource is freed and a direct call between the caller and the agent is managed by CallManager.
Basically, QME interacts with CallManager in two ways:
The image below is a high level representation of the application architecture and interactions.
Incoming calls are routed by your PBX to the waiting queues depending on the called number (DNIS). In the case you need more complex rules, including interactive menu choices by the end user, you can use IVR Manager in front of QME, for example to provide a service or a language pre-selection.
An incoming queue is an entry point for incoming calls that need to be dispatched to one or more agents. Calls enter the queue and are dispatched to the first available agent or are held in queue while agents are busy.
Calls are managed in a FIFO fashion (first in, first out).
While waiting in queue, music on hold and other optional voice prompts are played to the callers.
Each queue is mainly associated to:
Basically, the usual call flow that is applied when the queue is in service is the following:
Welcome Message => Waiting Music (loop) and optional wait voice prompts => Transfer to the agent
The priority level is considered when an agent is serving multiple queues: calls in higher priority queues will be served first by the system.
A treatment is an action that can be applied to the incoming call in a particular time interval or in a specific situation. Available treatments include:
A behaviour is basically a time interval or a particular situation that triggers a specific treatment on the incoming call. Following behaviours can be defined for each queue, they are listed in the increasing priority order they do apply:
Programming the queue means defining the possible behaviours with the associated treatments and voice prompts.
Queue Manager Enterprise dispatch queued calls to the first available destination target. Two kinds of destination targets can be configured for each queue:
In both cases QME try to monitor the target phone number by the TAPI CTI link, in order to optimise the call distribution and save the conversation times for reporting scopes. Normally QME monitors the target phone and tries to transfer the call to a target when it sees it idle (not busy). Targets that cannot be monitored by TAPI (for example external numbers and CallManager hunt pilots) are engaged by the QME in a best-effort way, that is attempting to call them even if they are busy, eventually retrying later. Also notice, that some distribution algorithms don't work properly if one or more targets are not CTI-monitored (see the dedicated section for details).
Agents can login/logout in one of the following ways:
QME dispatches calls to the available targets using a distribution algorithm, that can be defined by the administrator specifically for each queue. This algorithms instructs the QME on how choosing the next agent do dispatch the next call in queue.
Destination targets are grouped into escalation levels. An escalation level is a group associated to a progressive number that is considered by some of the available algorithms in the case of no-answer escalation. Such algorithms try to engage an available target starting from the first escalation level; if nobody answers the call in the current escalation level, the algorithm raises to the next escalation level group, searching for another available target. Algorithms involving escalation levels also can have sub-selection variants, that are different policies used to choose the first agent when considering raising in the higher escalation level.,
Following, a table representing the available algorithms and their sub-selection variants, with the description of how they work. Please, notice how some algorithms require that all target phones are CTI-monitored (TAPI) to make them working properly. If one or more phones are not monitored, the call distribution of such algorithms may be different from the expected one.
Please note that the algorithms never take into account how much time the agent was logged into the system. If needed, they calculate the time the agent spent on a call.
|Algorithm type||Considers Escalation level||Requires CTI monitoring||Description||Sub-selections policies|
|Priority||Yes||Yes||Selects the available agent starting from the first escalation level. Escalates to next levels only when all agents in previous levels are not available or busy. This algorithm can be used to manage skill levels, balancing the load inside the skill group.||
|Sequential||Yes||no||Scans for an available agents/targets starting from the first level. If a call is not answered by the current level, it escalates to the next level (no-answer escalation).If the call is not answered by the next escalation level, it loops back to the first agent group.||
|Round Robin||No||No||Always selects the available agent with the oldest engagement. Escalation level and position in the group are not considered by this algorithm, that is focused only to load-balancing.||- None -|
|Idle Time||No||Yes||Selects the available agent that is idle for the longest time. Escalation level and position in the group are not considered by this algorithm, that is focused on the load-balancing.||- None -|
|Broadcast||No||No||All agents/destination phones are made ringing at the same time, the first of them answering will take in charge the call. Priority level is not considered by this algorithm.||- None -|
|On Demand ("pull")||No||No||This algorithm does not push the call to agents. By using their Blue’s Attendant console, they can manually pick and answer a call from the waiting queue. The call remains in the queue until it is picked up by an agent or the maximum waiting time is over.||- None -|
When a call enters a queue, QME evaluates a set of conditions in order to understand which is the right treatment to apply to the call.
Basically, it has to check if it has available resources (licensed channels) to manage the new call, understand the treatment scheduled for the current date/time and check if particular scenarios occur (overflow, no agents available, etc.).
The following schema depicts the decision tree that is evaluated by QME when a new call arrives to a queue number and the possible treatments that could be applied.
Once a call is enqueued for an agent, it can be:
QME can lookup caller numbers into Speedy Enterprise public directories content. If a match is found, two additional features are available:
Both these features will be available only if Speedy Enterprise is licensed on the same machine.
Technical note: since Queue Manager performs an anonymous query on Speedy directories, only the contacts stored in Public directories will be considered.