Routage et notifications

Routing Editor

À quoi il sert. Il définit les règles d’acheminement (domaine/type → file/équipe). C’est la source unique du routage.

Quand l’utiliser. Pour décider où arrivent les tickets selon leur type et leur domaine.

Comment l’ouvrir. Depuis le lanceur Configurations, Routing.

Ce qu’il affiche et comment l’utiliser. Les règles de routage avec leurs conditions et la file/l’équipe de destination.

Ce qui se passe ensuite. Les tickets sont acheminés selon les règles.

Remarques. C’est la source unique des règles de routage.

Routing Triage

À quoi il sert. Il gère le tri des demandes entrantes avant leur acheminement.

Quand l’utiliser. Pour configurer/vérifier la phase de tri.

Comment l’ouvrir. Depuis le lanceur Configurations, Routing Triage.

Ce qu’il affiche et comment l’utiliser. Les règles/priorités de tri à l’entrée.

Ce qui se passe ensuite. Les demandes triées poursuivent dans le routage.

Remarques. Complémentaire du Routing Editor.

Routing Log

À quoi il sert. C’est le journal des décisions de routage (pour le diagnostic).

Quand l’utiliser. Pour comprendre pourquoi un ticket a abouti dans une file donnée.

Comment l’ouvrir. Depuis le lanceur Configurations, Routing Log.

Ce qu’il affiche et comment l’utiliser. Les décisions de routage avec la règle appliquée et le résultat.

Ce qui se passe ensuite. Il aide à corriger les règles.

Remarques. Outil de diagnostic.

Notify Matrix & Templates

À quoi elle sert. Elle configure la matrice de notification et les modèles : qui reçoit quelles notifications pour quels événements.

Quand l’utiliser. Pour définir les notifications (visibles dans la cloche, Notifications).

Comment l’ouvrir. Depuis le lanceur Configurations, Notify Matrix.

Ce qu’elle affiche et comment l’utiliser. La matrice événements→destinataires et les modèles de messages.

Ce qui se passe ensuite. Les événements génèrent les notifications configurées.

Remarques. C’est la source unique des règles de notification.