This report shows which agents have been available for the given queue, how many calls each one handled and the percentage of all calls that each one handled.

If calls are connected directly to a phone terminal, QM tries its best to show the corresponding terminal, usually in the format used by Asterisk, like "SIP/303" to signify a SIP phone whose number is 303.

If you connect to H.323 telephones via the OH323 module, the recorded channel names have no meaning and do not refer to a specific terminal; that’s why all OH323 calls are grouped together under the label "OH323/-".

This report shows the distribution of call waiting times. It shows how many calls were answered within a given time frame, usually 120 seconds in 10 second increments (the time frame and increment can be modified by the administrator, if needed - see Configuring system preferences ).

It is also possible to have two time frames in order to have a higher granularity for shorter time periods - e.g. having SLA computed in intervals of 5 seconds up to 20 seconds, and in intervals of 10 seconds up to 120 seconds.

You get a percentage of how many calls were answered within X seconds; the percentage includes calls answered in a shorter time frame and therefore grows with time.

The "delta" value you see is the absolute increment, expressed in number of calls, between each time frame.

This metric is computed only on answered calls, i.e. ignoring lost calls . If your SLA is defined in terms of taken and lost calls, see the corresponding metrics "Inclusive SLA" on Inclusive Service Level Agreement.

This report shows the reason why calls were terminated; this means that:

This graph shows how many calls were transferred to each extension in the given time frame. This lets you know who is handling exception calls.

If more than one queue is in use for the report, this graph shows the relative magnitude of each queue.

If more than one queue is in use for the report, this graph shows the relative magnitude of inbound versus outbound calls made.

This graph counts the distribution of multi-stint calls on selected queues. If multi-stint mode is not enable, all calls will have only one stint.

This graph shows the initial queue position that the calls had when they joined the queue. For example, a queue position of 1 means that a call was first in line, of 5 means that a call had four other calls in line before being answered. As the logging of queue positions is a bit inconsistent, some calls might be missing it ("Untracked")

This graph shows the distribution of IVR selections available in the calls processed.

This must be tracked manually in Asterisk - See "Configuring Asterisk for QueueMetrics" below.

This graph shows the distribution of DNIS lines available in the calls processed.

This must be tracked manually in Asterisk - See "Configuring Asterisk for QueueMetrics" below.

This page shows the detail of answered calls. See Showing call details.

This report shows the relative magnitude of disconnection causes, that are:

If more than one queue is in use for the report, this graph shows the relative magnitude of each queue.

This report is functionally equivalent to "Service level agreement" in the Answered calls section (see Service level agreement), but is computed on lost calls. It shows how many calls were hung up within a given time frame, usually 120 seconds in 10 second increments (the time frame and increment can be modified by the administrator, if needed - see Configuring system preferences).

You get a percentage of how many calls were lost within X seconds; the percentage includes calls lost in a shorter time frame and therefore grows with time.

The "delta" value you see is the absolute increment, expressed in number of calls, between each time frame.

The inclusive SLA corresponds to the Service Level Agreement metrics shown on Service level agreement, with the difference that it is computed taking into consideration both answered and unanswered calls.

If there are any calls that are were set unanswered because the caller pressed a key to exit the queue, this graph shows which keys were pressed and how many calls were terminated for that reason.

This graph tells the stint distribution of unanswered calls. It corresponds to the graph called "Answered calls, by stints".

This graph tells the stint distribution of all processed calls. It corresponds to the sum of the graphs called "Answered calls, by stints" and "Unanswered calls, by stints"

This graph shows the initial queue position that the calls had when they joined the queue. For example, a queue position of 1 means that a call was first in line, of 5 means that a call had four other calls in line before being answered. As the logging of queue positions is a bit inconsistent, some calls might be missing it ("Untracked")

This graph shows the initial queue positions for both answered and unanswered calls.

This graph shows the distribution of IVR selections available for lost calls.

This must be tracked manually in Asterisk - See "Configuring Asterisk for QueueMetrics" below.

This graph shows the distribution of IVR selections for all calls (taken and lost) available in the report.

This graph shows the distribution of DNIS lines that lead to lost calls.

This must be tracked manually in Asterisk - See "Configuring Asterisk for QueueMetrics" below.

This graph shows the distribution of DNIS lines for all calls (taken and lost) available in the report.

This page shows full details of unanswered calls Detail of unanswered calls.

This graph breaks down agent attempts by the agent that was called. The following pieces of information are extracted for each agent:

The following metrics are extracted and broken down by queue:

Calls, both taken and lost, are shown per specific day. Days with no events are not shown. The total numbers of call lengths, wait time for answered calls and wait time for unanswered calls are plotted for each day. Sales and contacts are also shown on a daily basis.

The Schedule Adherence report shows the number of distinct agents that were detected during the given period. This makes it possible to detect the number of different people that had been working on a given moment.

The Queue Length report shows the average length of the queue for each period, giving minimums and maximums. The Steps computation shows how fast each queue progresses during the period, expresses in steps per hour. Note: giving a meaning to the Queue Length reports may be hard in the case of composite queues.

Events are shown on a 24-hour distribution.

The total numbers of call lengths, wait time for answered calls and wait time for unanswered calls, together with sales and contacts, are plotted for each hourly interval. The size of hourly intervals can be controlled by the default.hourly_slot configuration property, making it possible to run this reports based on 30-minute, 20-minute or 15-minute intervals.

This report shows the weekly behaviour of your queues. The longer the analysis period, the more significant its results will be.

The total numbers of call lengths, wait time for answered calls and wait time for unanswered calls are plotted for each day of the week.

This graph shows which agents were available during the specified time frame and the percentage of agents' available time each one cumulated.

This time is calculated per all queues any agent is a member of, as the act of logging on is in general for the whole system and not specific to one single queue.

For each agent, the total time on pause - if any - is computed and broken down as "Billable" or "Not billable" - see the section on Pause Codes.

The "overlapping" is the amount of time that an agent was paused BUT taking calls. As you can pause in the middle of a call (maybe your system doesn’t allow this, but it is conceivable) you could have a period where you are paused BUT on conversation as well.

The '%' written next to the graph is the percentage of the pause time.

For each agent, the total number of sessions and pauses is computed (session time is already deducted of pause time). For both sessions and pauses, an average length is computed.

The "Pause percentage" is how much time an agent was on pause compared to available time.

The "Pauses per session" computes how many pauses - on average - each agent makes for each log-in session.

These metrics should be considered according to your call center rules on pauses and time-out.

This graph shows who of your agents answered calls for the queues you selected. The number of calls, together with total and average call durations are computed accordingly.

This graph show which priority levels handled calls for your queue. This shows whether your main line is staffed enough to handle the load of incoming calls.

For each agent session, the start and end times are recorded, together with the total duration in seconds.

If the agent logs on via the call back function, the designated call back extension is shown.

The number of pauses and the total pause time in seconds is shown.

The "Srv" column tells you on which server an agent was working in case you set up a cluster of Asterisk servers.

It is possible to sort the table for each title, in either descending and ascending order. To do this, click once on the desired title for descending sort, and twice for ascending sort. Once the table is sorted, an arrow symbol will appear close to the title, so you know on which column it was sorted last. As the sorting is done on the client machine, it may take a while with very large tables.

This table shows the specific pauses that each agent took and the pause code that was entered for each pause. It also shows whether the pause taken was considered to be billable or non-billable.

If you click on an agent’s name, a new popup will appear with full history for that agent. You can scroll in it as needed by using arrow keys or the wheel of your mouse.

A complete description of the popup is available in the Report Details: Popup of agent activity .

The idea is that a call can be a Contact, or a specialized contact that is a Qualified Contact, or a specialized Qualified Contact that is a Sale

This is needed because all the SPH, CPH and QCPH are calculated not on the totals of each class, but on sums of that class and generic types, like:

Conversion indexes are calculated as:

Multi-stint calls aren’t for everyone. There are a number of limitations and side effects you should be aware of before attempting to run QueueMetrics in this mode:

If you run calls with multi-stint mode enabled, the string "Multi-stint calls joined together" will appear on the top panel, and the number of joined together calls will be shown.

The distribution of taken calls by stints will be shown in the "Answered calls" tab:

The distribution of lost calls by stints will be shown in the "Lost calls" tab; aggregate calls by stints will also be shown in the "Lost Calls" page:

Details of multi-stints calls are displayed in the call details pop-up, in a separate tab. See Showing call details.

In order to export calls, an administrator must first create a batch. To do this, they go to the Home Page → Import/Export calls:

From here you select List Export Jobs.

You can then create a new job.

When configuring the job, you have to specify:

These properties can be changed through the lifetime of the job.

From now on, users accessing the Detail of Taken Calls will see a gadget by the end of the page like the one shown here:

This basically lets you add all the calls above to the export job you select. If the export gadget should not be visible, you have to add it manually to the current report (its code is OD02 - see Block OD02 ).

After you add sone calls to a job, the import transaction will confirm the add through a popup screen that displays the number of calls imported and the number of calls rejected (because they were already a member of this job). Only jobs in state Open will be availble for adding calls.

You can now see a list of calls from the Export Jobs page:

You can search calls within the current job and toggle their inclusion in the exported list by clicking on the reload icon next to each call.

When the job is ready for shipment, the administrator first has to Close it and then to Export it. This will take a while. Audio files will be retrieved through the curremtly configured Pluggable Module for audio records and will be saved in the job folder.

Thought the actual attributes used are based on the Implementor module used, the following are common attributes.

Batch attributes

Each call in the batch has the following attributes:

Batch disk format

A call batch appears on disk as a folder under the system call batch folder. The folder is created if not present (it must be in a Java-writable location). When the batch is in status "Ready to send", the audio files are copied to this folder; at the end of it all, a manifest file that includes the details is written. Each downloaded audio file is renamed in order to be unique and coherent, typical file names may be:

Both files are about the 123rd call, the first one being an audio recording and the second one a video recording.

When the batch is in status "Sent" QM no longer cares about the disk representation - it can be moved, sent as FTP, compressed and encrypted, whatever.

Manifest file format

The manifest file format should be chosen by the sysadmin - it is implemented as an abstract class for ease of change.

HTTP file transfer

This is the basic implementor and produces an XML file.

HTTP MP3 file transfer

This implementor does two things:

The following ID3 tags are created:

QueueMetrics lets you able to perform an external batch script call in order to convert call files to different format like, for example, wav files in mp3s. This feature is applied only for export jobs implemented with the "HTTP MP3 File Transfer" object. No external calls will be made for "HTTP File Transfer" enabled export jobs.

Assuming to have this type of export job parameters: Job name: MyJob Export folder (on server): /var/spool Implementor: HTTP MP3 File Transfer

the work flow followed by QueueMetrics, for HTTP MP3 File Transfer enabled jobs, will be like depicted below.

For each call in the job and for each file associated to a specific call:

When all files in the job are properly downloaded and converted, QueueMetrics will add all relevant QA information only to files with name ending with .mp3

Please note that:

To summarize the overall process, a simple example of working environment is provided:

In the configuration.properties is the key:

and in the /usr/local/apache-tomcat-5.5.25 is an executable testbatch script:

In this simple example, the batch script copies the original file in the temporary folder (with a not unique name in this example)

The resulting working folder will contain something like:

And the manifest something like: