Utilisez un ticket lorsque le travail doit se poursuivre au-delà de la conversation en direct ou nécessite un type, un état, un responsable ou un parcours de résolution explicite. Un ticket complète la chronologie de la conversation, il ne doit pas dupliquer chaque message client ni remplacer une réponse nécessaire.

Ce guide explique quand créer un ticket, comment capturer un contexte exploitable, comment le ticket principal apparaît dans Inbox, et comment les actions d’envoi et fermeture ou d’état peuvent affecter à la fois le ticket et l’état de transfert.

Comment cela s’intègre dans Humind

Inbox est le registre opérationnel des conversations client. Il combine l’historique des messages, le contexte de l’acheteur et du produit, la collaboration interne, l’état de transfert humain, les étiquettes et les tickets. Les réponses client et les notes internes ont volontairement une visibilité différente.

Une routine d’équipe cohérente compte davantage que n’importe quel filtre individuel. Convenez du moment où prendre en charge, où laisser une note interne, où créer un ticket, et où renvoyer une conversation à l’IA afin que la responsabilité reste claire pour chaque opérateur.

Avant de commencer

Accès : L’accès à Inbox est requis pour travailler à partir d’une conversation. Les actions de lecture ou d’écriture sur les tickets suivent les autorisations et la configuration de ticketing de l’entreprise, les paramètres du fournisseur sont contrôlés par l’administrateur.

• Confirmez que le ticketing est activé et que le type de ticket visé ainsi que les statuts existent.
• Lisez la conversation, les notes internes, les étiquettes et le ticket principal existant.
• Sachez si l’équipe utilise le système de ticketing Humind ou un fournisseur externe testé.

Procédure étape par étape

1. Décider si un ticket est nécessaire

   Créez un ticket pour un travail qui nécessite un suivi, une autre équipe, un cycle de vie structuré, ou une résolution après le départ de l’acheteur. Conservez une question simple dans la conversation lorsque l’opérateur peut y répondre et la traiter immédiatement.

   Vérifiez d’abord s’il existe déjà un ticket client principal. Plusieurs tickets pour un même problème créent un statut et une responsabilité peu clairs.

2. Créer un contexte de ticket exploitable

   Utilisez l’action de ticket de la conversation et choisissez le type pertinent ou l’état initial proposé par la configuration de l’entreprise. Résumez la demande, les faits vérifiés, le travail déjà effectué, l’attente du client et l’action suivante.

   Liez ou exploitez le contexte de la conversation plutôt que de copier des données personnelles inutiles dans le texte libre. Utilisez des notes internes pour le raisonnement entre coéquipiers qui n’a pas sa place dans un champ de ticket.

3. Maintenir le statut et la responsabilité

   Examinez le ticket principal dans les détails de la conversation. Mettez à jour les propriétés à mesure que l’enquête évolue et utilisez de manière cohérente les catégories de statut de l’entreprise. Humind associe les statuts configurés à des catégories telles que résolu pour le flux d’envoi.

   Un ticket laissé ouvert sans responsable ni action suivante n’est pas un transfert fiable. Utilisez les mentions ou le processus d’attribution de l’équipe lorsqu’une autre personne doit intervenir.

4. Répondre et fermer de manière intentionnelle

   Lorsqu’un ticket principal existe, le menu d’envoi de la réponse peut afficher une action d’envoi et fermeture. Cette action envoie la réponse au client, déplace le ticket vers le statut configuré de la catégorie résolu, et renvoie la conversation à l’IA. D’autres actions du menu d’envoi peuvent mettre à jour l’état d’un ticket.

   Lisez l’étiquette du menu et le statut actuels avant de cliquer. La fermeture du ticket et le renvoi à l’IA sont des résultats liés mais distincts qui se produisent ensemble dans ce parcours.

5. Vérifier le résultat côté client et côté opérateur

   Confirmez que l’acheteur a reçu le message prévu, que le ticket affiche le bon état, que la propriété du fil est correcte et que les notes internes restent privées. Rouvrez ou mettez à jour le ticket conformément à la politique si de nouvelles informations arrivent.

   Pour les fournisseurs externes, vérifiez l’enregistrement correspondant chez le fournisseur lors du déploiement initial. Ne supposez pas qu’un interrupteur d’identifiants garantit une synchronisation de bout en bout des tickets.

Autorisations et mises en garde importantes

• Les types de ticket et les noms de statut relèvent de la configuration de l’entreprise, utilisez les libellés actuels affichés dans l’espace de travail.
• L’action d’envoi et fermeture peut modifier à la fois l’état du ticket et celui de la conversation en une seule action.
• Le comportement externe de Gorgias ou Zendesk doit être configuré et testé séparément.
• Un ticket est un travail opérationnel interne et ne notifie pas en soi l’acheteur de l’avancement.

Vérifier le résultat

Utilisez cette liste de contrôle avant de considérer le travail comme terminé :

• Le ticket représente un besoin réel de suivi et ne duplique pas un ticket principal existant.
• Le résumé, le type, l’état, le responsable et l’action suivante sont compréhensibles pour un autre coéquipier.
• La réponse finale au client, le statut du ticket et la responsabilité de l’IA ou d’un humain correspondent au résultat prévu.
• Les enregistrements du fournisseur externe sont vérifiés lorsque ce fournisseur fait partie du flux de travail.

Dépannage

Les actions de ticket sont indisponibles

Confirmez que le ticketing est activé, que l’entreprise dispose de types de ticket et de statuts, et que votre rôle a l’accès requis. Demandez à un administrateur de vérifier la configuration du fournisseur et de Inbox.

L’action d’envoi et fermeture a utilisé le mauvais statut

Vérifiez quel statut configuré est associé à la catégorie résolu. Corrigez l’état du ticket et demandez à un administrateur de corriger la configuration des statuts avant que les opérateurs n’utilisent à nouveau l’action combinée.

Un fournisseur externe n’a pas reçu le ticket

Vérifiez le fournisseur sélectionné, les identifiants administrateur, le contexte de l’entreprise, et le propre enregistrement du fournisseur. Considérez l’intégration comme non vérifiée tant qu’un test complet n’a pas réussi.

Guides associés

• Travailler dans Inbox
• Prendre en charge une conversation et la rendre à l’IA
• Configurer l’escalade et l’assistance humaine
• Utiliser les notes, les mentions, les tags et les réponses enregistrées