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

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. 

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