The answered calls section deals with calls that were correctly handled by agents.

The top panel shows:

The answered completed calls section deals with calls that were correctly handled by agents. This is similar to what’s reported on previous panel but may exclude calls that were started before or terminated after the given time frame.

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/-".

The pie graph shows which agents have been available for the given queue representing the percentage of all calls that each one handled.

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 below).

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, while the "Offered" column displays the result of the taken calls divided by the total taken plus the total lost.

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.

The graph reports the percentage of how many calls were answered within X seconds, as reported in the table.

Since 1.6.2, it is possible to configure the time frame and increment separately for an initial period and the rest of the interesting period; in this way it is possible to have different breakdowns, e.g. every 5 seconds up to 20 seconds and every 10 seconds up to 120 seconds. See Configuring system preferences.

For example, by setting:

You get the following cutoff points: 5, 10, 15, 20, 30, 40, 50, 60 seconds

By setting:

You get the following cutoff points: 3, 5, 10, 15, 20, 25,…​ seconds

By setting

You get the default cutoff points: 10, 20, 30, 40, 50 , 60, 70, 80, 90, 100, 110 and 120 seconds

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

The graph reports the percentage values associated to the reason of why calls were terminated, as calculated in the table.

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 table shows the relative magnitude of each queue.

The graph reports the percentage associated to each queue in the table.

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

Inbound queues are marked with the symbol while outbound queues use the symbol .

The graph reports the percentage associated to each queue in the table.

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. We can also see the IVR duration values, which is related to the time that the call was within the IVR before entering the queue.

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 allows to see the total number of Music on Hold (MOH) events per agent, how many MOH instances took place throughout a call, the average and total duration of MOH events.

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

This is the report header and will be added automatically on each tab on the screen and at the beginning of each session in the PDF and Excel report export.

This data block displays the skills that were required for taken calls in the current reports.

As multiple skills may be required for the same call, or some calls may have no required skill, the sum of all skills may be significantly different from the number of calls.

For each skill, the average wait and talk duration of all calls having that specific skill is computed. Plus, the minimum, average and maximum level at which this skill was requested for the specific set of calls is displayed.

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

This is a pseudo-block that is used to display a button for call export. The button may not be displayed if the user does not have the correct grants. As it does not actually contain data, it cannot be queried over XML-RPC.

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

The details of calls are paged - so you can move back and forth - and you can control which columns will appear on screen. The paged mode uses way less memory and is quicker to use than the full list as in OD01 - Queue details.

When accessing the data source though XML-RPC or printing a report, it is mandatory to use the OD01 block, as this block is interactive and will not render correctly.

This block shows the paged detail of IVR calls. These are calls that did not hit a queue in the current report and thererfore are reported as neither answered nor unanswered.

The details of calls are paged - so you can move back and forth - and you can control which columns will appear on screen. The paged mode uses way less memory and is quicker to use than the full list as in OD05 - IVR details (full list).

When accessing the data source though XML-RPC or printing a report, it is mandatory to use the OD05 block, as this block is interactive and will not render correctly.

This block shows the paged detail of IVR calls. These are calls that did not hit a queue in the current report and thererfore are reported as neither answered nor unanswered.

This block prints a complete list and should be used only for printing and XML-RPC querying.

This report provides a wealth of information regarding the situation in general. With a final focus on lost calls and disconnection reasons. The information is the following:

General Statistics

Caller Statistics

Lost Calls Statistics A list of disconnection reasons and the number of lost calls with each disconnection reason

Notes:

The report shows:

The unanswered completed calls section deals with calls that were lost. This is similar to what’s reported on previous panel but may exclude calls that were started before or terminated after the given time frame.

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, either in a numerical than in a graphical form.

This graph shows the relative magnitude of unanswered outbound calls, grouped by agent.

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 OK04 - Service level agreement).

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, while the "Offered" column displays the result of the taken calls divided by the total taken plus the total lost.

The graph reports the percentage of how many calls were not answered within X seconds, as reported in the table.

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.

The difference between UN07 and UN18 is that the number of calls in UN18 is only the number of taken calls within the given answer period, while in UN07 it is the total number of taken and lost calls within the time period.

The graph reports the same information found in the table, but in a graphical way.

The time frame and increment can be modified by the administrator, if needed - see OK04 - Service level agreement.

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.

We can also see the IVR duration values, which is related to the time that the call was within the IVR before entering the queue.

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.

The answered calls section deals with calls that were correctly handled by agents.

For each queue included in the report, the following data will be shown:

In the first line, there is a "Total" line, that sums up the values shown in previous lines.

The following lines are sorted according to the number of offered calls.

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.

The difference between UN07 and UN18 is that the number of calls in UN18 is only the number of taken calls within the given answer period, while in UN07 it is the total number of taken and lost calls within the time period.

The graph reports the same information found in the table, but in a way that is easier to read.

The time frame and increment can be modified by the administrator, if needed - see OK04 - Service level agreement.

This data block displays the skills that were required for lost calls in the current reports.

As multiple skills may be required for the same call, or some calls may have no required skill, the sum of all skills may be significantly different from the number of calls.

For each skill, the average wait duration of all calls having that specific skill is computed. As lost calls never have any talk time, it always appears as 0:00 and is displayed for symmetry with blocks OK15 and UN20.

The minimum, average and maximum level at which this skill was requested for the specific set of calls is displayed.

This data block displays the skills that were required for all calls in the current reports.

As multiple skills may be required for the same call, or some calls may have no required skill, the sum of all skills may be significantly different from the number of calls.

For each skill, the average wait and talk duration of all calls having that specific skill is computed. Plus, the minimum, average and maximum level at which this skill was requested for the specific set of calls is displayed.

This data block displays the calling numbers that are to be recalled. A number is considered to be recalled if it matches the following criteria:

So we can say that a number is to be recalled if the last call from that number was unsuccessful. In this data block we display a list of calls, by default sorted with the most recent attempt on top, where such calls are in states Not yet recalled (when there is no succesful call at all) or Needs further recall (when there is a lost call after a succesful call).

Available columns:

When embedded in a wallboard, this block displays the current recall activity to be implemented and is a simple but effective way of keeping tab of missed contacts.

This data block displays callers that were recalled, that is, that had short or lost calls, but also had a subsequent complete call. SO the number of Successful calls will always be at least one.

Columns and the way they are computed are the same as block UN21.

This block displays a quick at-a-glance state of how many calls were:

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

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

The details of calls are paged - so you can move back and forth - and you can control which columns will appear on screen. The paged mode uses way less memory and is quicker to use than the full list as in UD01 - Detail of unanswered calls.

When accessing the data source though XML-RPC or printing a report, it is mandatory to use the UD01 block, as this block is interactive and will not render correctly.

If the Caller*ID is present, it is possible to break down both answered and unanswered calls to specific area codes by clicking on the "Area code analysis" button.

By selecting a number of caller id digits to search upon and a starting digit position, you get a number of statistics grouped by area codes.

This report gives an immediate check of the geographical origin of calls handled by your call center.

This report shows the answered calls grouped following the rules defined in AC01 - Area code report.

This report shows the unanswered calls grouped following the rules defined in AC01 - Area code report.

This report shows detailed information regarding different Area Codes. We take into account the quantity and quality of calls related to different areas, by calculating the following information:

This page shows the following pieces of information:

The following metrics are extracted and broken down by queue:

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

Taken calls are shown per specific day. Days with no events are not shown.

The total numbers of call wait time for answered calls are plotted for each day.

The total numbers of lost wait time for lost calls are plotted for each day.

Sales and contacts are 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.

The inclusive SLA corresponds to the Service Level Agreement metrics shown on Service level agreement, grouped by day.

This report shows aggregate inbound/outbound activity per day.

The Service Level is measured against a time period that is specidfied in the 'default.secondsServiceLevel' parameter (default is 20, as to say "percentage of calls answered within 20 seconds").

Short calls are defined as being shorter than the 'default.shortCallsLimit' parameter - default is 5 seconds.

This reports shows the unique sets of skills during a specified time period.

The report is computed out of all calls in the current analysis. Time bands are set as for the current report (system property that can be overridden and is "remembered" across sessions; can be reset through the Custom Reports page). The SLA is set for a queue (or set of queues to be reported on at once) though the parameter "Service Level Agreement" on the Queue configuration page; if missing, the default value is taken from the property sla.max_initial_delay.

Each call is grouped into a "bucket" based on skills found; skills are sorted by Skill Sort Weight in order to create unique buckets for each permutation. Only buckets with at least one call are added to the report. Buckets are displayed with codes correctly decoded. To change the order of how the skills appear inside each bucket, make sure to adjust the Skill Sort Weight field in the Agents Skill editor. Skills with a lower sort weight are positioned before skills with higher sort weight. If two skills have the same sort weight, they are sorted alphabetically based on their description.

For example, a call with skills “inv en fix” is set to a bucket “en fix inv”, that is a separate bucket from e.g. “en fix” but is is the same as “en inv fix” . Such a call is displayed in a column named “English Fix Invoice”, where the names are based on the descripitions used for skills, sorted by the skills' sort weight.

The report shows the following columns:

This reports shows the number of taken and lost call by day.

This report comes in three version, that show the number of calls in different time slices. The available period of times are:

The information is the following

The total numbers of call lengths for answered calls 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.

The total numbers of call wait time for answered calls 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.

The total numbers of call lengths for unanswered calls 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.

The total numbers 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.

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.

The inclusive SLA corresponds to the Service Level Agreement metrics shown on Service level agreement, grouped each hour.

Distribution of calls and agent availability per hour (or interval you specified). The whole 24h are mapped out for ease of comparison.

For a complete description of parameters, see DD08 - Traffic Analysis by period - per day

This reports shows the unique sets of skills during a specified time period.

For a complete description of parameters and behavior, see DD09 - Skill sets per day

This reports shows the number of taken and lost call by hour.

For a complete description of parameters and behavior, see DD10 - Detail Summary by day

The total numbers of call lengths for answered calls are plotted for each day of the week.

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

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

The total numbers sales and contacts, are plotted for each day of the week.

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.

The inclusive SLA corresponds to the Service Level Agreement metrics shown on Service level agreement, grouped for each day of week.

Distribution of calls and agent availability per day of week.

For a complete description of parameters, see DD08 - Traffic Analysis by period - per day

This reports shows the unique sets of skills during a specified time period.

For a complete description of parameters and behavior, see DD09 - Skill sets per day

This reports shows the number of taken and lost call by day of the week.

For a complete description of parameters and behavior, see DD10 - Detail Summary by day

This report shows:

This report shows:

This report shows:

In the latest release a new column has been added (Paused on Conversation), which displays occupancy values.

This report shows:

This report shows:

The report displays separately the following cases:

This report shows:

This report shows:

One entry is presented for each agent session. What makes this report different from most is that inbound and outbound activity for the agent is aggregated.

Items are computed as:

The report details the occupancy rate for each and all agents in the current analysis.

In the latest release a new column has been added (Paused Conversation) which is subtracted from the total pauses time; this way Occupancy will never be able to be over 100%.

The first line is labeled "All agents" and is computed according to the following rules:

The Occupancy report allows you to define custom calculations by entering one or more custom formulas in the Parameters field when editing your report.

For example, if you add the formula:

A new column "Productivity" will be computed based on the formula supplied. At the moment, the formula will always be displayed as a percentage.

New columns can be programmed as explained in User-Programmable reports

The report details the total presence time of each agent over the 24h for which you are running the current analysis.

The report details the payable presence time of each agent over the 24h for which you are running the current analysis.

The report details the billable presence time of each agent over the 24h for which you are running the current analysis.

This report shows a set of calls aggregated by agents. It reports session information and shows, for each agent, the main figures for aggregated calls related to that agent. The first row reports the overall aggregated values.

Each row in the report shows:

This report shows a set of calls aggregated by queue. It reports queue information and shows, for each queue, the main figures for aggregated calls related to that queue. The first row reports the overall aggregated values.

Each row in the report shows:

The report details the number of agents available on the selected queues each hour for each day in the report.

This report shows a set of calls aggregated by tag. It reports tags information and shows, for each tag, the main figures for aggregated calls related to that tag. The first row reports the overall aggregated values.

Each row in the report shows:

This report shows a set of calls aggregated by queue and tag. It reports queue and tags information and shows, for each queue/tag pair, the main figures for aggregated calls related to that pair. The first row reports the overall aggregated values.

Each row in the report shows:

This block just includes the first two columns: Level and Agent. All other columns are to be programmed by the user as explained in User-Programmable reports .

This block is meant as a completyl configurable version of block AG09.

This block shows detailed information about agent pauses, including total pause time, average duration, maximum duration, minimum duration and number of pauses. This information is aggregated by agent and pause. For each agent/pause pair the agent’s name and the pause code are displayed, together with the information described above.

The last two columns show the percentage of such pauses out of the the total session time for the given agent, and out of the total pause time for the given agent. For example, if an agent was logged in for four hours, two of which were on pause, and the current pause code has a total of one hour, it would show as 50% of all pauses and 25% of all session time for the agent.

This block breaks down all the agents' talk times in one-hour long timeslots. This information is aggregated by agent, so you can keep track of how many minutes or hours of conversation your agents are having during the course of the day, across a given period of time. The name of the agent and the agent’s level are displayed as well as the information listed above.

This block counts calls linked to an agent (both taken and lost); it is meant for outbound queues, though you can use it whenever it makes sense.:

Call numbers are computed lexicographically with no further processing, as they appear on the queue_log table. If a call has an empty number, then it counted in the number of calls and total call time but not in unique calls.

The report is sorted by talk time (descending) but can be sorted by name or any other value by clicking on its column header.

The threshold for including calls into Unique Effective is the configuration parameter default.effectiveCallThresold; default is 150 seconds.

This report shows, for all of the pauses within the current report, given each pause code:

If the pause code is unset, it is shown as "-"

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.

This is not a normal data block but it is the popup that is displayed whenever you click on an agent’s name.

In the latest release a new "Conversation" column has been added on, to the right of the "On Pause" column, which displays the pause time there may have been while actually in conversation.

You can close the popup by clicking on the Close button.

This report shows:

This report shows:

In this report you can find details explaining Billable activities, with average, minimum and maximum session durations, and a percentage on all activities of the same kind.

In this report you can find details explaining Non billable activities, with average, minimum and maximum session durations, and a percentage on all activities of the same kind.

The Detailed Agent Report will show, for each agent:

This data block displays all the status codes for each call handled by each agent within the current reporting selection.

If a call has no associated status code, then it is counted under a special status code called "-".

The columns show:

All columns are client-sortable.

This data block displays calls aggregated by tag code. The first line reports the figures for all aggregated call. The second row, marked with the dash code as tag, counts aggregates for all calls with no tag code assigned.

The columns show:

All columns are client-sortable. Clicking on the lens icons present in the report will open a popup with call details (taken, lost and IVR) counted in the aggregation.

This data block displays calls aggregated by feature code. The first line reports the figures for all aggregated call. The second row, marked with the dash code as feature, counts aggregates for all calls with no feature code assigned.

The columns show:

All columns are client-sortable.

This block shows:

For each path, the following information is computed:

This block shows:

For each path, the following information is computed:

This block shows:

This report aims at letting you know how many calls were clustered.

This report is built to have a “shape” that is familiar for users used to SLAs, and is completed by a similar graph.

In detail:

This report shows the total number of FCRs, clusters and calls with an empty IDs.

It has a pie chart showing FCRs vs clusters.

This block is a list of all clusters, sorted by the number of attempts and showing the cluster’s first and last call. Only clustered calls are included.

For all clusters including "taken" calls, the "Taken" column appears showing how many of those calls were counted and offering a link to a pop-up from which you can access the calls. The same goes for "Lost" calls. If both are counted, both columns are present.

Notes:

This report shows information about customers retry behaviour. We can see how many calls are registered as being the n-th attempt, based on the Customer Attempt number in the first column. The information is the following:

Notes:

This report shows aggregated data by caller/called number. We can deduce by looking at this report, the most frequent callers and the duration of their calls. A special icon is also present to inspect the signular calls that make up the aggregated data.

The information is the following:

Notes:

This block show all cases referenced within the current report.

For each case, we show:

This block show all clients referenced within the current report.

For each client, we show:

This data block includes a block of HTML right into the QueueMetrics report page.

For example, in order to include an HTML fragment generated by a server located at http://server/page.php you would set:

in the data block’s parameter field.

This data block includes a formatted table of data into the QueueMetrics report page. The data must be generated in a specified format by an XML-RPC server, as described on the 'XML-RPC Manual'.

This data block includes a formatted table of data into the QueueMetrics report page. The data must be generated in a given format by a JSON server, as described on the 'XML-RPC Manual'.

The following variables are automatically bound and therefore usable in formulas:

The following custom functions are implemented:

All times are expressed in seconds.

As Programmable blocks often do not include much interesting information by themselves, when referenced though their own block code will only return fixed columns.

It is still possible to access them as they are configured in a report by referencing their direct code; this will be displayed by the Reports editor as soon as you enter parameters for an existing data block. The format will usually be "DRI.num", where 'num' depends on your QueueMetrics install (different QueueMetrics systems will report different DRI codes for a block defined in the same way).