The following section describes the relation between calls made by the jtel system (both incoming and outgoing) and the way the call flow is handled.

Knowledge of how this works is particularly important when viewing statistics in the system (both online and historical).

Incoming Call Processing

When an incoming call is received by the jtel system, how it is processed depends on the setup of the service number, and the call flow associated with the service number.

There are three main ways the processing can be setup.

IVR Only Processing

In this scenario, only an IVR application is used to process the call.

The system will record data in the following tables:

  • StatisticsPartA
  • CounterDetailStatistics

Things to note:

  • dtCallStart and dtCallEnd are always recorded in normal operation
  • dtCallAlert may be NULL. This can be the case if the system issues a connect without ringing (for example to immediately play a prompt) then ringing may be skipped. Also this can be the case if the call was refused by the system.
  • dtCallConnect may be NULL if the call was never answered.
  • CounterDetailStatistics are specific to a particular version of the IVR call flow. It is recommended to use IVR Statistics Markers to record statistics in the IVR if you require overall application (and version) based statistics.

Acd Group Only Processing

In this scenario, the call is routed directly into an ACD group from the service number.

The ACD could overflow to further ACD groups, depending on the rules configured. The diagram below illustrates this, and "explodes" the relevant details. 

Things to note:

  • One StatisticsPartA record is created per call.
  • One AcdStatisticsPartB record is created for each group "visited" during the call flow.
  • This can include group overflows, but also call transfers to groups made by agents.
  • One StatisticsPartB record is created for each attempt to reach an agent (whether successful or not).
  • This can include agent transfers and enquiry calls made by one agent to another.
  • AcdStatisticsPartB - Any of the following timestamps may be NULL - which would indicate that the corresponding condition never occurred:
    • dtAnnouncement1Start (no announcement 1 played or none configured)
    • dtAnnouncement2Start (no announcement 2 played or none configured)
    • dtQueueStart (the call did not enter the ACD queue)
    • dtDistributeStart (the call was never tried to be distributed to an agent)
    • dtAgentConnect (the call was never connected to an agent)
  • StatisticsPartB - Any of the following timestamps may be NULL, which would indicate that the corresponding condition never occurred:
    • dtCallAlert (the call never rang at the agent phone - for example when busy)
    • dtCallConnect (the call was not answered by the agent)
    • dtWhisperEnd (the call was not answered by the agent, or if dtCallConnect is set - the agent hungup during the whisper prompt or no whisper prompt is configured)

IVR and ACD Group Processing

This scenario is a combination of the above two scenarios:

  • Calls are first routed into the IVR
  • One of the IVR Objects "ACD" is used to route to an ACD group

For clarity, some details are omitted from the diagram below. For example, the case when several ACD objects are used is not considered (though this is just an extension of the case shown below), and also the case when several ACD groups are cascaded (overflow scenario) using rules in the ACD group is not depicted.

  • No labels