Dans cet article, nous allons vous expliquer le transfert et la restitution des conversations de messagerie, les actions qui permettent de changer le premier intervenant dans une conversation d’un bot à un agent, puis vice versa.
- Le transfert permet de supprimer le bot en tant que premier intervenant dans une conversation et de faire d’un agent le premier intervenant.
- La restitution supprime l’agent en tant que premier intervenant dans une conversation, pour faire du bot le premier intervenant quand le client commence une nouvelle conversation. La restitution d’une conversation à un bot met fin à la conversation, ce qui permet de commencer une nouvelle conversation afin de traiter un nouveau problème ou une nouvelle demande d’assistance.
Cet article aborde les sujets suivants :
Utilisation des événements de transfert
La seule action qui initie le transfert du statut de premier intervenant d’un bot à un agent est l’étape Transférer à un agent d’un bot automatisé. Quand la conversation est transférée, les agents sont notifiés de la demande d’assistance en attente en fonction du workflow de routage établi du compte et le bot ne peut plus répondre à la conversation.
Un agent reste le premier intervenant jusqu’à la clôture du ticket associé à la conversation.
Utilisation et gestion des événements de restitution
La restitution de la conversation est initiée quand le statut du ticket associé à la conversation est modifié de Résolu à Clos. Ensuite, quand le client commence une nouvelle conversation, le bot redevient le premier intervenant. Il est cependant important de noter que le bot n’envoie pas automatiquement le premier message dans une conversation subséquente. Le client qui revient dans le canal de messagerie doit envoyer un message pour initier une réponse du bot qui essaie alors de trouver un raccourci conversationnel. S’il n’en trouve pas, le bot répond normalement en suivant un comportement de saisie de texte libre normal. Consultez Raccourcis conversationnels et suggestions d’articles pour en savoir plus.
Jusqu’à ce que le statut du ticket soit défini sur Clos, si un client revient dans le canal de messagerie alors que le ticket est encore marqué comme Résolu, la conversation s’affiche comme toujours active et l’agent est encore le premier intervenant. Le client ne peut pas commencer une nouvelle conversation portant sur une nouvelle demande d’assistance. Par défaut, le délai entre la résolution et la clôture d’un ticket est de quatre jours, ce qui peut parfois être une source de confusion pour les clients qui reviennent dans votre canal de messagerie.
Pour éviter ce scénario, vous avez deux solutions :
Ajuster l’automatisme par défaut
La mise à jour automatique du statut d’un ticket de Résolu à Clos est gérée via un automatisme Support par défaut, Clore le ticket 4 jours après la définition du statut sur Résolu.
Vous pouvez modifier cet automatisme pour gérer le délai qui doit s’écouler avant que le statut du ticket ne soit modifié et défini sur Clos. Vous pouvez choisir que le ticket soit clos dans un délai de 1 heure ou au contraire prolonger le délai jusqu’à 28 jours après la résolution du ticket. Pour clore un ticket immédiatement, consultez la recette de déclencheur dans la section suivante.
Créer un déclencheur pour gérer la clôture du ticket
Vous pouvez aussi créer un déclencheur pour clore les tickets résolus automatiquement, ce qui revient plus ou moins à ignorer l’automatisme par défaut.
Pour ce faire, vous devez ajouter un marqueur (comme clore) à tout ticket dont le statut est modifié et défini sur Résolu.
Vous devez ensuite créer un déclencheur qui s’exécute pour tous les tickets avec ce marqueur et les clôt. Ce déclencheur doit avoir les propriétés suivantes :
- Condition : Marqueurs | Contient au moins l’une des valeurs suivantes | clore
- Action : Statut | Clos
Si vous utilisez la CSAT pour évaluer la satisfaction client dans la messagerie, il est important de noter que l’enquête est envoyée dès que le statut du ticket est défini sur Clos. Si vous utilisez les enquêtes CSAT, nous vous conseillons de maintenir un court délai entre la résolution et la clôture d’un ticket, afin d’éviter tout conflit. Consultez À propos de l’expérience utilisateur de la satisfaction client (CSAT) pour l’e-mail et la messagerie pour en savoir plus.
Autres paramètres à prendre en compte
Plusieurs paramètres, même s’ils ne sont pas directement liés aux actions de transfert et de restitution des conversations de messagerie, peuvent impacter leurs performances et l’expérience des utilisateurs finaux.
- Avec les déclencheurs Absent du bureau, les clients peuvent se faire une idée du moment où un agent sera disponible pour reprendre la conversation. Consultez Création d’un message d’absence du bureau dans un Web Widget ou Mobile SDK pour en savoir plus. Les déclencheurs Absent du bureau s’exécutent uniquement après un transfert.
- Les conversations ininterrompues vous permettent d’envoyer automatiquement des notifications par e-mail aux utilisateurs finaux qui ont quitté une conversation dans un Web Widget avant qu’elle ne soit terminée. Consultez Comment permettre aux clients de continuer leur conversation par e-mail pour en savoir plus.
- Les paramètres de routage gèrent la façon dont une conversation de messagerie et le ticket qui y est associé sont transférés du bot à un agent ou un groupe après un événement de transfert. Pour en savoir plus, consultez À propos du routage dans la messagerie.