Sv translation

language	en

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

border	true

diagramName	Call Flow - IVR Only
simpleViewer	false
width
links	auto
tbstyle	top
lbox	true
diagramWidth	1319
revision	5

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

border	true

diagramName	Call Flow - ACD Only
simpleViewer	false
width
links	auto
tbstyle	top
lbox	true
diagramWidth	1323
revision	8

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

border	true

diagramName	Call Flow - IVR and ACD
simpleViewer	false
width
links	auto
tbstyle	top
lbox	true
diagramWidth	1323
revision	2

Sv translation

language	de

Der folgende Abschnitt beschreibt die Beziehung zwischen

Anrufen, die vom Jtel-System getätigt werden

den vom jtel System getätigten Anrufen (sowohl eingehende als auch ausgehende)

,

und die Art und Weise, wie der Anruffluss gehandhabt wird.

Kenntnisse darüber

Das Wissen, wie dies funktioniert,

sind

ist besonders wichtig, wenn Sie Statistiken im System ansehen (sowohl online als auch historisch)

angezeigt werden

.

Verarbeitung eingehender Anrufe

Wenn ein eingehender Anruf vom

Jtel-

jtel System empfangen wird, hängt die

Art und Weise, wie er verarbeitet wird,

Verarbeitung von der Einrichtung der Servicenummer und dem mit der Servicenummer

assoziierten Call-FLow

verbundenen Anruffluss ab.

Es gibt im Wesentlichen drei

Hauptmöglichkeiten

Möglichkeiten,

wie

die Verarbeitung

eingerichtet werden kann

einzurichten.

IVR

-Only

-Verarbeitung

In diesem Szenario wird nur

ein

eine IVR-

Antrag

Anwendung zur Bearbeitung des

Aufrufs verwendet.

Acd Group Only Verarbeitung

IVR und ACD Group Verarbeitung

Anrufs verwendet.

Das System zeichnet Daten in den folgenden Tabellen auf:

StatisticsPartA
CounterDetailStatistics

draw.io Diagram

border	true

diagramName	Call Flow - IVR Only
simpleViewer	false
width
links	auto
tbstyle	top
lbox	true
diagramWidth	1319
revision	5

Beachte:

dtCallStart 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 Details.

draw.io Diagram

border	true

diagramName	Call Flow - ACD Only
simpleViewer	false
width
links	auto
tbstyle	top
lbox	true
diagramWidth	1323
revision	8

Beachte:

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

draw.io Diagram

border	true

diagramName	Call Flow - IVR and ACD
simpleViewer	false
width
links	auto
tbstyle	top
lbox	true
diagramWidth	1323
revision	2

Sv translation

language	fr

La section suivante décrit la relation entre les appels effectués par le système jtel (tant entrants que sortants) et la manière dont le flux d'appels est traité.

Il est particulièrement important de savoir comment cela fonctionne lorsque l'on consulte des statistiques dans le système (à la fois en ligne et historiques).

Traitement des appels entrants

Lorsqu'un appel entrant est reçu par le système jtel, la manière dont il est traité dépend de la configuration du numéro de service, et du flux d'appels associé au numéro de service.

Le traitement peut être mis en place de trois manières principales.

Traitement RVI uniquement

Dans ce scénario, seule une application IVR est utilisée pour traiter l'appel.

Le système enregistrera les données dans les tableaux suivants:

StatisticsPartA
CounterDetailStatistics

draw.io Diagram

border	true

diagramName	Flux d'appels - IVR uniquement
simpleViewer	false
width
links	auto
tbstyle	haut
lbox	true
diagramWidth	1319
revision	5

Choses à noter:

dtCallStart et dtCallEnd sont toujours enregistrés en fonctionnement normal
dtCallAlert peut être NULL. Cela peut être le cas si le système émet une connexion sans sonnerie (par exemple pour lire immédiatement une invite), la sonnerie peut être ignorée. Cela peut également être le cas si l'appel a été refusé par le système.
dtCallConnect peut être NULL si l'appel n'a jamais reçu de réponse.
CounterDetailStatistics est spécifique à une version particulière du flux d'appels IVR. Il est recommandé d'utiliser des marqueurs de statistiques IVR pour enregistrer des statistiques dans l'IVR si vous avez besoin de statistiques globales basées sur l'application (et la version).

Traitement du groupe Acd uniquement

Dans ce scénario, l'appel est acheminé directement dans un groupe ACD à partir du numéro de service.

L'ACD pourrait déborder vers d'autres groupes ACD, selon les règles configurées. Le diagramme ci-dessous illustre cela et «explose» les détails pertinents.

draw.io Diagram

border	true

diagramName	Flux d'appels - ACD uniquement
simpleViewer	false
width
links	auto
tbstyle	haut
lbox	true
diagramWidth	1323
revision	8

Choses à noter:

Un enregistrement StatisticsPartA est créé par appel.
Un enregistrement AcdStatisticsPartB est créé pour chaque groupe «visité» pendant le flux d'appels.
Cela peut inclure des débordements de groupe, mais également des transferts d'appels vers des groupes effectués par des agents.
Un enregistrement StatisticsPartB est créé pour chaque tentative d'atteindre un agent (réussie ou non).
Cela peut inclure les transferts d'agents et les appels de demande d'un agent à un autre.
AcdStatisticsPartB - L'un des horodatages suivants peut être NULL - ce qui indiquerait que la condition correspondante ne s'est jamais produite:
- dtAnnouncement1Start (aucune annonce 1 jouée ou aucune configurée)
- dtAnnouncement2Start (aucune annonce 2 jouée ou aucune configurée)
- dtQueueStart (l'appel n'est pas entré dans la file d'attente ACD)
- dtDistributeStart (l'appel n'a jamais été tenté d'être distribué à un agent)
- dtAgentConnect (l'appel n'a jamais été connecté à un agent)
StatisticsPartB - L'un des horodatages suivants peut être NULL, ce qui indiquerait que la condition correspondante ne s'est jamais produite:
- dtCallAlert (l'appel n'a jamais sonné sur le téléphone de l'agent - par exemple lorsqu'il est occupé)
- dtCallConnect (l'appel n'a pas été répondu par l'agent)
- dtWhisperEnd (l'appel n'a pas été répondu par l'agent, ou si dtCallConnect est défini - l'agent a raccroché pendant l'invite de chuchotement ou aucune invite de chuchotement n'est configurée)

Traitement des groupes RVI et ACD

Ce scénario est une combinaison des deux scénarios ci-dessus:

Les appels sont d'abord acheminés vers l'IVR
L'un des objets IVR "ACD" est utilisé pour acheminer vers un groupe ACD

Pour plus de clarté, certains détails sont omis du diagramme ci-dessous. Par exemple, le cas où plusieurs objets ACD sont utilisés n'est pas pris en compte (bien qu'il ne s'agisse que d'une extension du cas présenté ci-dessous), ainsi que le cas où plusieurs groupes ACD sont en cascade (scénario de débordement) à l'aide de règles dans le groupe ACD n'est pas représenté.

draw.io Diagram

border	true

diagramName	Flux d'appels - IVR et ACD
simpleViewer	false
width
links	auto
tbstyle	haut
lbox	true
diagramWidth	1323
revision	2

Page tree

Versions Compared

Old Version 19

New Version Current

Key

Incoming Call Processing

IVR Only Processing

Acd Group Only Processing

IVR and ACD Group Processing

Verarbeitung eingehender Anrufe

IVR

-Verarbeitung

Acd Group Only Verarbeitung

Acd-Gruppen-Verarbeitung

IVR- und ACD-Gruppenverarbeitung

Traitement des appels entrants

Traitement RVI uniquement

Traitement du groupe Acd uniquement

Traitement des groupes RVI et ACD

Page tree

Page History

Versions Compared

Old Version 19

New Version Current

Key

Incoming Call Processing

IVR Only Processing

Acd Group Only Processing

IVR and ACD Group Processing

Verarbeitung eingehender Anrufe

IVR

-Verarbeitung

Acd Group Only Verarbeitung

Acd-Gruppen-Verarbeitung

IVR- und ACD-Gruppenverarbeitung

Traitement des appels entrants

Traitement RVI uniquement

Traitement du groupe Acd uniquement

Traitement des groupes RVI et ACD