Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://docs.fanifyai.com/llms.txt

Use this file to discover all available pages before exploring further.

L’action “Réserver la conversation à un opérateur” s’utilise dans une règle de stratégie pour attribuer automatiquement un utilisateur à un opérateur dès que la règle matche. Quand une stratégie qualifie un fan de “prospect chaud” (par exemple via l’IA), cette action sélectionne un opérateur selon vos critères et lui réserve la conversation, exactement comme une réservation manuelle.

​
Cas d’usage typiques

  • Répartition du chatting manuel : Répartir la charge de travail de vos chatteurs automatiquement.
  • Prospect chaud détecté par l’IA : l’utilisateur est immédiatement attribué à un chatteur senior qui prendra le relais.
  • Gros dépensier identifié : un utilisateur qui dépasse un certain montant cumulé est confié à un chatteur expert.
  • Langue ou région spécifique : un utilisateur francophone est attribué uniquement aux chatteurs francophones de votre équipe.
  • Onboarding d’un nouveau chatteur : un curseur “favoriser le moins chargé” envoie automatiquement les nouveaux utilisateurs au chatteur en cours de montée en charge.

​
Sélection de l’opérateur

L’action détermine l’opérateur à attribuer en deux étapes : d’abord elle construit un pool éligible, puis elle sélectionne un opérateur dans ce pool selon le mode choisi.

​
Pool éligible

Le pool est l’ensemble des opérateurs candidats à l’attribution.

​
Allow list — qui peut recevoir des attributions

Deux modes :
  • Uniquement les chatteurs (défaut) : tous les opérateurs ayant le rôle Chatter. Les administrateurs et autres rôles sont exclus.
  • Spécifique : vous choisissez explicitement la liste des opérateurs candidats (par exemple “Sophie, Pierre, Marie”). Le rôle n’est pas filtré ; tout opérateur listé est éligible.

​
Deny list — qui ne doit jamais recevoir

Indépendamment de l’allow list, vous pouvez toujours exclure des opérateurs. Pratique pour mettre quelqu’un en formation hors-pool sans changer son rôle, ou pour mettre un chatteur en pause sans le supprimer.
La deny list est prioritaire sur l’allow list : un opérateur listé dans les deux ne sera jamais sélectionné.

​
Privilégier les opérateurs connectés (activé par défaut)

Si activé, la sélection se fait en priorité parmi les opérateurs en ligne (les opérateurs connectés).
  • Si au moins un opérateur du pool est en ligne, seuls les opérateurs en ligne sont considérés.
  • Si aucun n’est en ligne, l’action sélectionne dans le pool hors-ligne. La conversation est attribuée même en dehors des heures de service, et l’opérateur la verra à sa prochaine connexion.
Si désactivé, l’état en ligne / hors-ligne n’est pas pris en compte (tous les opérateurs éligibles sont candidats à parts égales).

​
Mode de répartition

Une fois le pool établi, deux modes de tirage sont disponibles :

​
Aléatoire (défaut)

Tirage uniforme parmi le pool éligible. Sur la durée, chaque opérateur reçoit globalement le même nombre d’attributions. C’est le mode le plus simple et le plus prévisible.

​
Selon la charge de travail

Tirage pondéré par la charge actuelle de chaque opérateur. La charge est calculée en comptant les utilisateurs actuellement réservés à l’opérateur. Un curseur vous permet de doser l’orientation de la répartition :
Position du curseurEffet
100 / 0 — Toujours le moins chargéLe moins chargé reçoit systématiquement la prochaine attribution. Idéal pour faire monter en charge un nouvel opérateur.
~70 / 30 — Favoriser le moins chargé (défaut)Équilibre doux qui privilégie le moins chargé tout en laissant des attributions régulières aux autres.
50 / 50 — Répartition équilibréeÉquivalent au mode “Aléatoire”.
~30 / 70 — Favoriser le plus chargéEnvoie davantage aux opérateurs déjà engagés. Utile pour maximiser l’expertise sur les profils existants.
0 / 100 — Toujours le plus chargéExtrême inverse, généralement peu utilisé en production.
Fenêtre temporelle
La charge peut être mesurée sur une fenêtre récente plutôt que sur l’historique complet. Vous configurez une durée en jours (par défaut 1 jour) ou cochez “Illimité” pour ne pas filtrer.
  • Avec une fenêtre courte (1 à 7 jours), le calcul reflète la charge récente : un opérateur qui n’a rien reçu cette semaine sera prioritaire même s’il a beaucoup d’utilisateurs réservés historiquement.
  • Avec “Illimité”, le calcul reflète la charge totale actuellement détenue par chaque opérateur.
La fenêtre temporelle est basée sur la date de création de l’utilisateur (CreatedDate) parmi ceux actuellement réservés. L’attribution étant généralement déclenchée peu après la création de l’utilisateur, une fenêtre de 1 jour reflète bien la charge récente. Pour une mesure historique complète, cochez “Illimité”.

​
Comportement face aux conflits

​
Utilisateur déjà réservé

Par défaut, si l’utilisateur est déjà réservé à un autre opérateur quand l’action s’exécute, rien ne se passe (skip silencieux). Cela évite qu’une stratégie récurrente ne change l’opérateur de l’utilisateur à chaque évaluation. L’option “Forcer la réassignation” (désactivée par défaut) inverse ce comportement : l’utilisateur est systématiquement réattribué selon l’algorithme, remplaçant la réservation précédente.
Avec “Forcer la réassignation” activé, si l’opérateur précédent était en train de consulter la conversation au moment de la réassignation, il sera automatiquement déconnecté de celle-ci, exactement comme pour une réassignation manuelle.

​
Utilisateur en cours de consultation

Si la conversation est verrouillée par un opérateur autre que celui sélectionné par l’action, le verrou est libéré automatiquement et la nouvelle réservation prend effet. Cohérent avec le comportement d’une réservation manuelle. Si la conversation est déjà verrouillée par l’opérateur que l’action vient de sélectionner, le verrou est conservé tel quel — pas de déconnexion inutile.

​
Notification de l’opérateur attribué

L’option “Notifier l’opérateur ciblé” (activée par défaut) envoie une notification de type “Un utilisateur vous a été attribué” à l’opérateur choisi, avec un lien direct pour ouvrir la conversation. Chaque opérateur peut désactiver individuellement ce type de notification dans ses paramètres personnels (clé d’événement USER_RESERVED_TO_ME). Dans ce cas la réservation a tout de même lieu, seule la notification est silencieuse pour cet opérateur.
Que la notification soit envoyée ou non, la conversation apparaît immédiatement dans la liste de l’opérateur ciblé via la synchronisation temps réel. La notification sert d’alerte active (badge, push mobile, son) — pas à rendre la conversation visible.

​
Gestion automatique des cas limites

Quelques situations sont gérées de manière transparente :
  • Pool vide (aucun chatteur disponible, ou règles d’exclusion excluant tout le monde) : l’action n’effectue aucune opération, enregistre un avertissement dans les journaux, et la stratégie se poursuit normalement avec les actions suivantes. La conversation reste non attribuée.
  • Aucun opérateur en ligne (avec “Privilégier les connectés” activé) : bascule automatique sur le pool hors-ligne. L’opérateur découvrira la conversation à sa connexion.
  • Action déclenchée plusieurs fois sur le même utilisateur (stratégie multi-passes, évaluations répétées) : seule la première attribution prend effet ; les suivantes sont ignorées tant que l’utilisateur reste réservé (sauf si “Forcer la réassignation” est activé).
  • Sélection idempotente : si l’algorithme sélectionne l’opérateur déjà réservé à l’utilisateur, aucun changement n’est appliqué et aucune notification n’est ré-émise.
  • Opérateur supprimé entre-temps : l’action enregistre une erreur dans les journaux et la stratégie continue ; l’utilisateur reste non attribué.
  • Import de stratégie sur une autre instance : si certains opérateurs spécifiés dans l’allow list ou la deny list n’existent pas sur l’instance cible, la carte d’action affiche un indicateur d’erreur dans l’éditeur, et les identifiants invalides sont ignorés silencieusement lors de l’exécution.

​
Scénarios concrets

Quelques exemples pour visualiser le comportement de l’action selon la configuration. Chaque scénario décrit l’équipe en place, la configuration choisie, et ce que vous observerez.
Équipe : votre équipe est globalement équilibrée sur le long terme, mais sur les dernières 24 heures, les aléas de la journée ont créé un déséquilibre : Sophie a déjà reçu 8 nouveaux utilisateurs (matinée chargée), Pierre 3 (en réunion une partie de la journée), et Marie 1 (vient de prendre son shift).Configuration
  • Mode : Selon la charge de travail
  • Curseur : ~70 / 30 — Favoriser le moins chargé (défaut)
  • Fenêtre : 1 jour (défaut)
Observation : Marie reçoit la majorité des nouveaux utilisateurs (~44 %), Pierre une part intermédiaire (~37 %), Sophie continue à recevoir mais en moindre proportion (~19 %). Au fil des heures, les attributions reçues par Sophie en début de matinée sortent du calcul dès qu’elles dépassent 24 h — son poids remonte alors naturellement et le système se rééquilibre en continu, sans intervention.
Équipe : tous historiques confondus, Sophie est votre chatteuse senior avec 50 utilisateurs réservés, Pierre 35, et Marie sort tout juste de formation avec 5 utilisateurs déjà réservés. Vous souhaitez que Marie commence à recevoir des conversations pour pratiquer, sans la noyer, et que Sophie continue à porter le gros du flux le temps que Marie monte progressivement en compétence.Configuration
  • Mode : Selon la charge de travail
  • Curseur : ~30 / 70 — Favoriser le plus chargé
  • Fenêtre : Illimité
  • Allow list : Uniquement les chatteurs
Observation : pour chaque nouvelle attribution, Sophie a environ 45 % de chance d’être choisie, Pierre ~35 %, et Marie ~20 % — assez pour pratiquer sans être débordée. Une fois que Marie aura gagné en confiance, ramenez le curseur vers 40 / 60 puis remettre en mode alétoire une fois qu’elle sera qualifiée, pour diminuez la charge des autres chatteurs (compte tenu d’un traffic équivalent).
Équipe : tous historiques confondus, Sophie a 60 utilisateurs réservés, Pierre 45, et Marie 3 (elle vient d’arriver dans l’équipe).Configuration
  • Mode : Selon la charge de travail
  • Curseur : 100 / 0 — Toujours le moins chargé
  • Fenêtre : Illimité
  • Allow list : Uniquement les chatteurs
Observation : Marie reçoit la très grande majorité des nouvelles attributions (~80 % de chance), Pierre garde un flux résiduel (~20 %), et Sophie est quasi totalement écartée tant qu’elle reste la plus chargée. À mesure que Marie rattrape Pierre, leur écart se resserre et la répartition se rééquilibre progressivement.
Équipe : Sophie est votre chatteuse senior la plus expérimentée. La règle de stratégie ne déclenche que sur les utilisateurs qualifiés “VIP” par l’IA (par exemple ayant dépensé plus de 500 €).Configuration
  • Mode : Aléatoire (le mode importe peu, il n’y a qu’une candidate)
  • Allow list : Spécifique = [Sophie]
  • Privilégier les connectés : activé
Observation : tous les VIP détectés sont systématiquement attribués à Sophie. Si elle est en ligne au moment de l’attribution, elle reçoit immédiatement la notification. Si elle est hors-ligne, la conversation lui est tout de même réservée et l’attendra à sa prochaine connexion (le pool ne contenant qu’elle, le fallback hors-ligne s’applique automatiquement).
Équipe : Sophie, Pierre et Marie sont vos trois chatteurs. À 3 h du matin, personne n’est connecté. La stratégie tourne 24/7 et qualifie un nouveau prospect.Configuration
  • Mode : Aléatoire
  • Allow list : Uniquement les chatteurs
  • Privilégier les connectés : activé
  • Notifier l’opérateur ciblé : activé
Observation : aucun opérateur n’étant en ligne, l’action bascule automatiquement sur le pool hors-ligne et tire au hasard parmi les trois (par exemple Pierre). La conversation est attribuée à Pierre immédiatement, et une notification push est envoyée à ses appareils (téléphone, navigateur). Si Pierre a activé les notifications push et que son téléphone est allumé, il peut être réveillé sur-le-champ et prendre la main. Sinon, à sa connexion le matin, il découvre la conversation déjà attribuée ainsi que la notification ”📥 Un utilisateur vous a été attribué” dans sa liste.
Équipe : sur les 7 derniers jours, parmi les nouveaux utilisateurs entrés dans Fanify, 40 sont actuellement attribués à Sophie, 28 à Pierre, et 12 à Marie. Vous voulez que Marie monte en charge sans que Sophie ne reçoive plus rien.Configuration
  • Mode : Selon la charge de travail
  • Curseur : ~70 / 30 — Favoriser le moins chargé (défaut)
  • Fenêtre : 7 jours
Observation : Marie reçoit la majorité des attributions (environ 50 %), Pierre une part intermédiaire (~30 %), Sophie continue à recevoir occasionnellement (~20 %). Personne n’est totalement coupé du flux, et l’écart se résorbe progressivement sans à-coups.

​
Bonnes pratiques

  • Démarrez en mode “Aléatoire” pour observer la répartition naturelle, puis passez en “Selon la charge” si vous constatez un déséquilibre.
  • Combinez avec une condition d’évaluation forte (température de chat élevée, score d’intention, dépense cumulée) pour ne réserver que les utilisateurs qui en valent la peine. Réserver tous les utilisateurs sans filtre sature les chatteurs sous les réservations et complique la libération.
  • Laissez “Forcer la réassignation” désactivée dans la majorité des cas. Activez-la uniquement pour des stratégies de rééquilibrage manuel que vous déclenchez ponctuellement.
  • Vérifiez les notifications : avant de déployer une stratégie qui attribue beaucoup, assurez-vous que les chatteurs concernés ont bien activé USER_RESERVED_TO_ME dans leurs paramètres pour ne rien manquer.

​
Voir aussi