In QueueMetrics, we define a multi-stint call as a call that was processed on more than one queue, with one or more queue terminating it for timeout, transfers or key exits.
In the standard QueueMetrics reporting mode, this call would be seen as a series of "lost calls" on one or more queues, possibly followed by a taken call if the call was answered at all; the system does not notice that those events happened on the same call.
Running QueueMetrics in multi-stint mode, calls will be grouped together based on the call’s Unique-ID, and a single call will be rebuilt as a multi-stint call so that:
- The call looks like it was handled on the first queue it was presented on; the queue enter time and queue position are those of the first queue.
- The call will be considered "answered" if the last stint is an answered call, "lost" in all other cases
- The wait time will be the sum of the wait times on different queues (if there are intermediate wait times, like those for IVR menus, they will not be counted)
- The talking time and agent taken the call will be taken from the last taken call
- All stats (number of call, call distribution, etc) will be counted on the new multi-stint calls.
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:
- Calls are grouped by the Asterisk Unique-ID code; this means that if different call stints happen on different servers in a cluster, they will not be grouped together
- All queues the call passed on must be included in the report. If you include only the master queue, stints on other queues will not be seen.
- Because of the previous bullet, it is usually better to configure separate "wrap up" or "timeout" queues, that is, instead of having both a Sales and a Support queue that will send people to the General queue on timeout, it would be better to have "Sales" → "General-sales" and "Support" → "General-support", even if "General-sales" and "General-support" are actually aliases of the same queue.
- All stints of all calls must be included between the starting and ending report times. Stints that start before the start data or end after it will be ignored.
- Run time and memory will be comparatively more than a standard analysis, as the grouping and additional data stored take their toll on the system
- Stint-grouping does not work for real-time analysis.
![[Note]](../images/icons/note.png){kind=icon} | Note |
|---|---|
On versions of QueueMetrics up to 1.6.3, calls are filtered by search criteria before being aggregated in multi-stint mode. This may lead to problems when you want to use filtering criteria in multi-stint mode, where only some stints match the critera while others does not. T To avoid this issue, on newer versions of QueueMetrics calls are joined together in multi-stint mode before criteria are applied to the aggregated results. |
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:
On the "Taken calls" list, multi-stint calls will have a blue icon next to the magnifying glass icon; by clicking on that icon it will be possible to access stint details for that call.
The same thing will be true for lost calls:
