Priorité des rappels / enqueued callback

Priorité des rappels / enqueued callback

Concernant les rappels/callback, il est nécessaire de comprendre la fonctionnalité "enqueued callbacks" ou 'mise en file d'attente des rappels'
Comme son nom l'indique, ceci prévoit le positionnement des rappels en file d'attente.
Le souci vient lorsque l'on fait des rappels "classiques" et qu'il y a beaucoup de traffic entrant.
Comme le traffic entrant va toujours être traité en priorité, le dialer ne saura jamais au courant que l'agent est prêt et les callbacks ne seront donc jamais traités...
C'est pour cela que nous avons créé cette fonctionnalité : au moment où le rappel doit être réalisé, on positionne un appel "virtuel" en file d'attente et quand cet appel est distribué, on génère le callback au même moment... comme l'illustre le schéma suivant.



Dans celui-ci, on voit un "callback classique"
Un appel entrant, l'agent passe "prêt", immédiatement il prend l'appel, le dialer n'est pas informé, à ce moment (ligne verticale verte) le callback est programmé, l'agent étant occupé, rien ne se passe.. 
L'agent termine son traitement, passe prêt, rien à distribuer, l'ACD communique au dialer, le dialer execute le callback, il va vérouiller, et ceci est le callback qu'on avait demandé (ligne du bas en bleu).
Il n'a pas pu être traité directement mais il a tout de même été réalisé... 
Ensuite, vient un autre appel (sur la partie droite)...

Ci-dessous, même cas de figure.



Vous voyez juste un appel entrant qui s'est intercalé là (1ère ligne) par rapport à cette situation (exemple précédent).. ce qui veut dire que quand l'agent passe prêt, il va prendre l'appel entrant positionné en file d'attente...
Le callback, comme celui illustré à ce niveau ci (montrer sur le schéma) dans l'exemple précédent, ne sera ici pas généré, et pour le peu qu'il y ait du traffic entrant intense, le callback ne sera jamais généré...

La résolution est donc la mise en file d'attente de ce callback comme expliqué plus tôt.



Au moment où il est l'heure de rappeler, on génère un appel virtuel dans la file d'attente; quand l'agent passe prêt, l'appel est distribué à l'agent et ça génère la numérotation rappel.

En revanche, et l'exemple est fait exprès, si on compare par rapport au précédent (exemple précédent), au niveau de la 1ere ligne entre brique "En ligne" et "Attente"), l'agent traite l'appel en attente, c'était un appel entrant.
A ce niveau ci (dans cet exemple), quand l'agent est passé prêt, on a généré le callback, parcequ'on l'a fait passé devant volontairement, la personne qui est en attente est peut-être restée en attente et elle a peut-être bien généré un abandon donc ici on a priorisé le rappel quitte à créer de l'abandon en entrant..
Il faut savoir que l'option existe "enqueued callback au niveau de l'admin" et des activités sortantes.