Call Segmentation #
Call segmentation is the name given to how the system models telephone calls. Understanding how calls are modeled is important in understanding the data which is displayed on reports and wallboards.
The following section explains how the system models calls, the difference between single/multi segment calls and what effect they have on the data displayed.
What is Call Segmentation? #
Telephone calls can range from being relatively simple with just two connections involved, to increasingly complex cases such as multiple transfers or conference calls. The system tracks all information about a telephone call using a model of Sessions, Segments and Connections.
Session: A session is an entire call, it can be made up of one or more call segments.
Segment: A specific part of a session where the call has been answered at multiple devices, or rang multiple groups/queues.
Connection: A connection between a device (device, user, agent etc) and a call segment. The system will store information about how long each connection was involved in the call and the states that the connection was in (connected, ringing, held etc.).
Using the model of sessions, segments and connections, information on every device that is involved in a call is modeled and can be provide both historically and in real-time through the reports and wallboard interfaces.
The image above shows an example session containing two segments. Each segment has a minimum of two connections. The sections below outline how single and multi-segment calls might look and how segmentation affects reports.
Single Segment Calls #
A single segment telephone call is a call that involves no more than one connected state and has been through no more than one group/queue.
The images below outline a single segment internal and external call.
These are simple calls with only two devices involved.
Multi Segment Calls #
A multi segment call is a call that has been connected to multiple devices at different time (like a transfer) or a call that has routed through one or more groups/queues on the telephone system.
The images below outline a couple of multi-segment calls.
The image above shows a call that was answered on Device 1001, then transferred to Device 1002. This call (session) has two segments. Each segment has a connection to the device that was involved in the call.
The image above shows a call which rang at Queue 2000 but did not get answered, it then recalled to Queue 2001 where it was answered by Device 1005. Even though this call was only answered at one device, a new segment was created when the call moved to a new queue so that the ring time and sequence of queues can be properly tracked.
How does this affect Reporting? #
Each report in the system displays data based on either call sessions (Non-segmented data) or call segments (segmented data). The statistics displayed will vary depending on which view of the data is chosen.
For example, using the queue example from the previous section, the table below shows how many times the call will be counted in 3 different reports:
|Report Name||Call Model||Calls|
|Calls by DID||Session||1|
|Calls by Queue||Segment||2|
|Calls by Users||Segment||6|
The Calls by DID report (based on session data) will only show one call. When analyzing DID traffic, the information displayed is about how many actual calls came in, and how long in total they took to answer.
The Calls by Queue report (based on segment data) will count the call twice - once for each of the queues involved. This allows the call to be tracked between the queues and to see how long it was waiting at each one.
The Calls by User report (also based on segment data) will count the call 6 times, once for each user that was involved in the call. This allows user performance to be monitored and to see how many calls users refused or answered.
All these views of the call are valid and meaningful. It is important to understand why they differ so that when comparing reports, the differences in totals are understood.
How does this affect Real-Time Statistics? #
Statistics added to a tile will by default display 'Non-segmented' data, that is to say, session data is used to calculate the statistic (as in the Calls by DID report). If an agent/user-based filter is added to the tile, the statistic would then be calculated using 'Segmented' data, because there agent/user filter applies context.
For example, a tile which displays abandoned calls may show different statistics depending on the filter applied. If a single incoming call rang 3 users before hanging up:
|Filter Type||Call Model||Calls|
|User Filter (Including all 3 users)||Segment||3|
In this final example, because the filter is providing a 'user' context, the statistic would display 3 abandoned calls, because each of the users in the filter had an abandoned call.
Segmentation & Common Call Scenarios #
The scenarios below outline how the segmentation of calls works in common call scenarios other than the transfer and queue scenarios already mentioned.
Conference Calls #
A conference call is a call that involves more than two devices at a time. When calls with more than two devices are active, conference resources on the telephone system are used to merge the audio streams from each device.
When conferences occur on a call, a new connection is added to the call, the segment doesn't change.
In the image above, there are 4 internal and 2 external parties involved in a conference call. This still only generates a single call segment on the system.
Trunk to Trunk Calls #
Trunk to trunk calls are calls between two trunks on the telephone system that do not involve any internal devices.
The image below shows a trunk to trunk call:
A trunk to trunk call will involve a minimum of two segments. The initial segment will include the device internally that setup the trunk to trunk call.
More often than not, these scenarios will be combined in a single session. So a call that comes through a queue then gets transferred will have more segments than a call that just comes through a queue.