Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Sv translation
languageen

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

draw.io Diagram
bordertrue
diagramNameCall Flow - IVR Only
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1319
revision5

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. 

draw.io Diagram
bordertrue
diagramNameCall Flow - ACD Only
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1323
revision8

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.

draw.io Diagram
bordertrue
diagramNameCall Flow - IVR and ACD
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1323
revision2

Sv translation
languagede

Der folgende Abschnitt beschreibt die Beziehung zwischen den vom jtel System getätigten Anrufen (sowohl eingehende als auch ausgehende) und die Art und Weise, wie der Anruffluss gehandhabt wird.

Das Wissen, wie dies funktioniert, ist besonders wichtig, wenn Sie Statistiken im System ansehen (sowohl online als auch historisch).

Verarbeitung eingehender Anrufe

Wenn ein eingehender Anruf vom jtel System empfangen wird, hängt die Verarbeitung von der Einrichtung der Servicenummer und dem mit der Servicenummer verbundenen Anruffluss ab.

Es gibt im Wesentlichen drei Möglichkeiten, die Verarbeitung einzurichten.

IVR-Verarbeitung

In diesem Szenario wird nur eine IVR-Anwendung zur Bearbeitung des Anrufs verwendet.

Das System zeichnet Daten in den folgenden Tabellen auf

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

draw.io Diagram
bordertrue
diagramNameCall Flow - IVR Only
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1319
revision5

Things to noteBeachte:

  • 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.

  • und dtCallEnd werden im Normalbetrieb immer aufgezeichnet.
  • dtCallAlert kann NULL sein. Dies kann der Fall sein, wenn das System einen Connect ohne Klingeln ausgibt (z. B. um sofort einen Prompt abzuspielen), dann kann das Klingeln übersprungen werden. Dies kann auch der Fall sein, wenn der Anruf vom System abgewiesen wurde.
  • dtCallConnect kann NULL sein, wenn der Anruf nie beantwortet wurde.
  • CounterDetailStatistics sind spezifisch für eine bestimmte Version des IVR-Rufablaufs. Es wird empfohlen, IVR-Statistik-Marker zu verwenden, um Statistiken in der IVR aufzuzeichnen, wenn Sie allgemeine anwendungs (und versions)-basierte Statistiken benötigen.

Acd-Gruppen-Verarbeitung

In diesem Szenario wird der Anruf von der Servicenummer direkt in eine ACD-Gruppe geleitet.

Je nach den konfigurierten Regeln könnte die ACD zu weiteren ACD-Gruppen überlaufen. Das folgende Diagramm veranschaulicht dies und "explodiert" die relevanten DetailsThe ACD could overflow to further ACD groups, depending on the rules configured. The diagram below illustrates this, and "explodes" the relevant details

draw.io Diagram
bordertrue
diagramNameCall Flow - ACD Only
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1323
revision8

Things to noteBeachte:

  • 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
  • Pro Anruf wird ein StatisticsPartA-Datensatz erstellt.
  • Für jede Gruppe, die während des Anrufablaufs "besucht" wird, wird ein AcdStatisticsPartB-Datensatz erstellt.
  • Dazu können Gruppenüberläufe gehören, aber auch von Agenten vorgenommene Rufübergaben an Gruppen.
  • Für jeden Versuch, einen Agenten zu erreichen (ob erfolgreich oder nicht), wird ein StatisticsPartB-Datensatz erstellt.
  • Dies kann Agententransfers und Rückfragen von einem Agenten zu einem anderen beinhalten.
  • AcdStatisticsPartB - Jeder der folgenden Zeitstempel kann NULL sein - was bedeuten würde, dass die entsprechende Bedingung nie eingetreten ist:
    • dtAnnouncement1Start (keine Ansage 1 abgespielt oder keine konfiguriert)
    • dtAnnouncement2Start (keine Ansage 2 abgespielt oder keine konfiguriert)
    • dtQueueStart (der Anruf ist nicht in die ACD-Warteschlange gelangt)
    • dtDistributeStart (der Anruf wurde nie versucht, an einen Agenten verteilt zu werden)
    • dtAgentConnect (der Anruf wurde nie mit einem Agenten verbunden)
  • StatisticsPartB - Jeder der folgenden Zeitstempel kann NULL sein, was bedeuten würde, dass die entsprechende Bedingung nie aufgetreten ist:
    • dtCallAlert (der Anruf hat nie am Agententelefon geklingelt - z. B. bei Besetzt)
    • dtCallConnect (der Anruf wurde vom Agenten nicht angenommen)
    • dtWhisperEnd (der Anruf wurde vom Agenten nicht angenommen, oder wenn dtCallConnect gesetzt ist - hat der Agent während der Flüsteraufforderung aufgelegt oder es ist keine Flüsteraufforderung konfiguriert)

IVR- und ACD-Gruppenverarbeitung

Dieses Szenario ist eine Kombination aus den beiden oben genannten Szenarien:

  • Anrufe werden zunächst in die IVR geroutet
  • Eines der IVR-Objekte "ACD" wird zur Weiterleitung an eine ACD-Gruppe verwende

Aus Gründen der Übersichtlichkeit werden im folgenden Diagramm einige Details weggelassen. So wird z. B. der Fall, dass mehrere ACD-Objekte verwendet werden, nicht berücksichtigt (obwohl dies nur eine Erweiterung des unten gezeigten Falls ist), und auch der Fall, dass mehrere ACD-Gruppen über Regeln in der ACD-Gruppe kaskadiert werden (Überlaufszenario), ist nicht dargestelltFor 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.

draw.io Diagram
bordertrue
diagramNameCall Flow - IVR and ACD
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1323
revision2

Sv translation
languagefr

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

draw.io Diagram
bordertrue
diagramNameCall Flow - IVR Only
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1319
revision5

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. 

draw.io Diagram
bordertrue
diagramNameCall Flow - ACD Only
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1323
revision8

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.

draw.io Diagram
bordertrue
diagramNameCall Flow - IVR and ACD
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1323
revision2