Call Concepts #
The following concepts apply to call analytics and have an effect on how call data can be analyzed. It is important to understand these concepts to help with configuration and to ensure the system is used to its full potential.
The following table outlines terms used in the context of communications platforms and analytics.
|A communication server/PBX instance
|Automatic Call Distribution, a way of distributing incoming calls to agents
|A user that can log in to receive calls from Queues that provide ACD features
|A telephone call between two or more parties. A call can have multiple segments
|Call flows existing on the PBX and can be used to route calls or interact with them to ensure they go to the correct place.
|The external caller ID or telephone number presented when a telephone call is received
|A call segment can have multiple connections to different device/trunks on the communications platform
|An device that is used to make or received calls
|Direct Inward Dial, a telephone number used to bring incoming external calls into the communications platform
|A simple group that can be configured to deliver a call to multiple devices
|An internal call between two devices on the communications platform
|A state a call can be placed in while it is waiting for a user to pick it up. Calls can be parked at devices or park locations
|Public switched telephone network. The network of telecommunication service providers to link regional, national and international infrastructure
|An advanced queue that provides ACD features, queuing incoming calls and distributing them to agents when they are available
|A call can be made up of multiple segments as it gets transferred or overflows to different devices/queue on the communications platform
|The service number is populated with the DID on incoming calls and the Outgoing Caller ID on outgoing calls. This allows a single report to show the usage of a particular number
|An external line used to connect the communications platform to a PSTN
|A user of the communications platform. A user may have one or more devices on the platform
|Time provided to an agent after an ACD call which they require to complete tasks relating to the call
Call Types #
Internal (Intercom) & External Calls #
Information about all telephone calls that take place are stored for call reporting purposes. This includes all external calls (calls involving a trunk line) and internal calls (intercom calls between internal devices of the business).
When analyzing call data, it is important to know that internal calls are included in some statistics and they can skew figures if the wrong statistics are used.
Statistics on the system will include only external calls unless the name specifically includes mentions internal calls. For example, the 'Total Calls' statistic includes only external calls, whereas 'Total Calls (inc. IC)' will include all external and internal calls on the system.
For more information on the fields available, please refer to the Statistics section.
Call Direction (Incoming & Outgoing, Both) #
The direction indicates which party initiated the telephone call (which party dialed the number). All calls modeled by the system have a direction, but depending on the tile/report being run, the direction may not be relevant.
External calls always have a direction no matter what tile or report is displayed the data. Trunk to trunk calls will have a direction of 'Both' due them having a incoming and outgoing leg.
Internal calls only have a direction when the tile/report is showing data which has been grouped by a device (Agent ID, Device, Queue or User) on the telephone system. When viewed on a wallboard tile, internal calls have no direction.
If calls are forwarded by a user to an external number, the call will become a trunk to trunk call and will have a direction of 'Both'. Use an external device instead of a call forward to track these calls as incoming on reports.
Answered / Unanswered Calls #
An answered call is one where a caller is connected to a device/agent/user or voicemail. Consequently, an unanswered call is one which has not been answered by a device/agent/user or voicemail.
The concept of whether a call is answered or not varies depending on whether you are looking at Segmented or Non-Segmented call reports.
When looking at a Non-Segmented report, the call will show as answered if it was answered on any segment. If looking at a Segmented report, the call will only show as answered if that particular segment was answered.
Abandoned Calls (Lost) #
An abandoned call is an incoming external call where the last segment was not answered. Abandoned call statistics can be added to real-time tiles and historical reports.
An abandoned call is any call where the last segment was not answered, even if it has been answered on a previous segment (internal calls are not included in abandoned call statistics). On segmented call list reports, only the last segment will be marked as Abandoned.
E.g. If a call is answered by 'User A', but then gets transferred to 'User B' but ends before 'User B' answers the call, this would be marked as an Abandoned Call.
It is not always possible to detect when a call has gone to voicemail. Due to this, calls that have gone to voicemail may be included in the Abandoned call statistics.
Unreturned Abandoned Calls #
Unreturned abandoned calls statistics are available for real-time tiles only, not historical. These statistics track incoming (external) calls which were abandoned and that haven't subsequently:
- Dialed in again and been answered
- Had an outgoing return call which has been answered
These statistics provide a good way of tracking how many customers have tried to make contact, but have not yet spoken to someone.
There are two different unreturned abandoned call statistics which can be used, Unreturned Abandoned Calls & Unreturned Abandoned Calls (no filter). The difference between these two statistics is down to how filters are applied to them.
Unreturned Abandoned Calls When using this statistic, any filter applied will be applied to both the incoming calls and the return calls. E.g. If a filter for a certain DID is being applied, only a subsequent call from the same number which is answered on the same DID would remove the call from the unreturned abandoned calls statistic.
Unreturned Abandoned Calls (no filter) When using this statistic, any filter applied will only be applied to the abandoned call element. E.g. Any call incoming or outgoing call to the same number would cause the unreturned abandoned call to be removed from the statistic.
If the same number rings in twice and both calls are abandoned, although there are two separate abandoned calls, it will only be counted as a single unreturned abandoned call.
An outgoing return call that has been answered will remove an Unreturned Abandoned Call.
Refused Calls #
The refused call property relates to a call segment that has been offered to a user through a queue/group which they have not answered. The call itself may be offered to a different users after a set period of time or overflow to a different queue/group.
The call will be logged as refused against the user who did not answer the call. This statistic allows user performance to be compared to see who is routinely ignoring calls (they may be forgetting to set their availability correctly resulting in a poor customer experience).
Transferred Calls #
Transferred calls are calls that have been answered and then have been moved by the user to another device. This includes calls transferred by any of the following methods:
- Announced/Blind Transfer
- Pickup/Reverse Transfer1
The systems provides specific fields for tracking calls which have been transferred to or from a device.
For example, if device 1001 transfers a call to device 1002, the call will be classed as 'Transferred Out' for device 1001 and 'Transferred In' for device 1002.
Overflowed Calls #
Overflowed calls are unanswered calls which have moved from one device to another. This can be because the call was deflected by the user or the call was moved automatically due to one of the following reasons:
- Forward Timer
- Group/Queue Timer
- Pickup/Reverse Transfer1
For example, a call that rings device 1001 and follows a 'Forward - No Answer' timer to device 1002 will appears as 'Overflowed Out' against device 1001 and 'Overflowed In' against device 1002.
Hang-up Causes #
Where applicable, call segments will be attributed with a hang-up cause which can help to indicate why the call cleared down. The table outlines some of the possible hang-up causes which are displayed:
|The side sending this hangup isn't going to route the call.
|This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility, high layer compatibility or other compatibility attributes (e.g. data rate) which cannot be accommodated.
|This cause indicates that an inter-working call (usually a call to SW56 service) has ended.
|This cause is used to report an invalid message event only when no other cause in the invalid message class applies.
|This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete.
|This might be because the leg was challenged for authentication and was unable to comply. Another cause could be no codec was negotiated between the two sides. Check the SDP codec listings for both sides.
|This cause is used when the called party has been alerted but does not respond with a connect indication within a prescribed period of time. Note - This cause is not necessarily generated by Q.931 procedures but may be generated by internal network timers.
|This could mean there is no callflow defined for the number, or the number is unassigned to a PBX in PBX Connector. You'll have to figure out which side of the dialog is hanging up first though.
|This cause is used when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated.
|This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared. Under normal situations, the source of this cause is not the network.
|This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g. the user may wish to try another call attempt almost immediately.
|This cause is used to report a normal event only when no other cause in the normal class applies.
|This cause indicates that although the calling party is a member of the CUG for the outgoing CUG call, outgoing calls are not allowed for this member of the CUG.
|This cause means the call was picked up by intercepting it from another extension (i.e. dialing **ext_number from another extension).
|The endpoint (carrier or device) failed to progress to early media, ringing, or answering the call within the allotted time. May be indicative of errors on the endpoint's side. If a carrier, consider removing them from the off-net/account routing until you can discover the issue. These hangups impact PDD (post-dial delay) and are quite noticeable to the caller.
|Often seen when NAT is interfering with receiving responses from the endpoint. Check the firewall at the customer's site for SIP ALG (and turn it off), try port 7000 or TCP as necessary.
|This cause is used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies.
|This cause indicates that the called party cannot be reached because, although the called party number is in a valid format, it is not currently allocated (assigned).
|This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determined user busy it is noted that the user equipment is compatible with the call.
|This means you tried to originate a call to a SIP user who forgot to register.
|This cause is used sometimes when ACLs are out of sorts
Service Level Statistics #
Service Level #
Service levels are a target of how quickly incoming calls should be answered. The service level statistics use a configured target service level to display the percentage of calls that were answered within the desired time. This can be viewed in historical reports and real-time tiles.
Service level settings are configured for the system but can be overridden at Workspace level if required.
Short Answered Calls #
These are incoming calls that have been answered but have an extremely short talk time (default set to less than 10 seconds). Calls that are classed as short answered can be removed from service level reports so as not to skew statistics.
Please refer to the Reporting Settings section for information on changing the Short Answered Call Threshold
Short Ringing Calls #
These are incoming calls that have not been answered and have an extremely short ring duration (default set to less than 10 seconds). Calls that are classed as short ringing can be removed from service level reports so as not to skew statistics.
Please refer to the Reporting Settings section for information on changing the Short Ringing Call Threshold
Route Path #
The route path name/number properties can be used to identify the route an incoming call has taken through the system. This helps when monitoring customer experience and helps to identify inefficient call flow programming.
The route path properties are initially populated with the caller id and caller name of the incoming call. As the call passes through Call Flows, the route path can be prefixed with additional information about the Queues or Groups it is being routed to.
When the call gets presented to a user, the caller id or name may have been prefixed with information of the call's route. This additionally helps the user know more information about the call, allowing them to answer the call in a specific way.
On an outgoing call, the route path name/number properties are populated with the caller name and number that was presented when making the call.
If using ACDC, incoming Route Path prefixes can not be correctly modeled due to a lack of events linking the original call to the ACDC user call.
Route path information can be viewed on segmented and non-segmented call lists. A segmented call list will show the progression of the route path properties for a call. A non-segmented call list will show the route paths for the last segment which does not have a blank route path.
Dedicated route path summary reports are available to see a breakdown of the number of calls following each path through the PBX. Summarized route path reports work off non-segmented call data, so will look at the final route path of a call.
Please refer to the Route Path Reports section for more information on the summarized route path reports.
If the route path of a call is reset or wiped out by a call flow, the summarized reports will not correctly show the path a call has taken.
Call Segmentation #
Call segmentation refers to how data about calls is modeled and stored for reporting. As a call is connected to different users or queues, it is tracked in different call segments. This allows reports to provide in-depth information on how calls have routed where they have been transferred or picked up.
Understanding call segmentation is an important step in being able to analyze call data correctly.
For more information on how call segmentation affects statistics, please refer to the dedicated Call Segmentation section.
Summarized & Aggregated Data #
On reports that show grouped data (Calls by User, DID etc), individual calls (or call segments) are grouped together and data from each call is summarized into totals, averages, percentages etc.
The Summarized Data section provides information on how this data can be interpreted and how aggregating call segments affects the data displayed.
Real-Time Data #
Active calls and user/agent status are modeled by the system and can be viewed through the Wallboard interface. The sections below outline each of the states available and provide examples of how these apply in the different call scenarios.
Call States #
When viewing statistics based on active calls, each call being modeled is classed as being in one of the states outlined on the table below. These call states are then used to build up the Active Call statistics (Calls On Hold, Calls Queuing etc).
|A call that has at least two connected devices
|A call that has at least one held device and less than two connected devices
|A call that is parked at a device or park location
|A call that has at least one queued device
|A call that has at least one ringing device
Call waiting statistics are based on the combined total of calls in the Queuing or Ringing state.
|Incoming external call ringing at a device
|The call is connected at a trunk but not yet connected at a device so is classed as ringing.
|Incoming external call connected at a device
|The call has two connected devices, the trunk and the device.
|Outgoing external call ringing at the remote location
|The call is connected at the device but not at the trunk device so is classed as ringing.
|Three party conference with two connected devices and one held
|Even though one connection to the call is on hold, there are two connected devices so that call is classed as connected.
|Internal/external call on hold at a device
|The call is only connected at one device, the other is on hold so the call is classed as on hold.
Device States #
The following table outlines the different states a device on the communications platform can be in.
|The phone is on line with no connected calls.
|The phone is not currently online
|The phone is busy on a call.
Agent States #
The following table outlines the different states an agent on the communications platform can be in.
|There user is not currently logged on as an agent.
|The user is logged on and is available to be presented with calls.
|Busy on ACD Call
|The user is logged on and is currently busy on an ACD call.
|Busy on Non-ACD Call
|The user is logged on and is currently busy on a non-ACD call.
|The user is logged on and is currently in wrap up after an ACD call.
|The user is logged on and is currently not available to take calls.
User States #
User presence/status is not directly tracked other then by the calls they make/receive. When running user summary reports (e.g. Calls by User), the call states can be used to see how long people are busy on calls etc.
In addition, a Total Idle Duration can be shown for a user. This is the time of the report duration that the user has not spent on a call (Ringing, Talking or On Hold).
Calls picked up from a queue are included in 'Calls Answered' statistics not 'Overflowed Out' or 'Transferred Out' statistics. ↩︎
Any call that is in call flow that is not currently alerting a device on the system is classed as being in the Queued state. ↩︎
Where supported, Away State Reasons are stored along side away state changes and accessible to review in Agent Status Detail and Agent Away Reason Summary reports. ↩︎