Un client demande à parler à une personne. Le bot annonce que quelqu'un va rejoindre la conversation, mais personne n'arrive. Pour corriger cette expérience, il faut d'abord décider où envoyer la demande et qui y répondra.
Ce guide distingue le transfert en direct du ticket de support. Il s'appuie sur le fonctionnement actuel de l'escalade dans Agentkit pour expliquer les limites de configuration, puis propose une politique et des vérifications à adapter à votre équipe de support. Les détails du produit ont été vérifiés le 6 octobre 2026. Les exemples sont illustratifs et ne sont pas des résultats clients.
Comment définir les déclencheurs du transfert du bot vers un humain pour le support ?
Définissez des déclencheurs pour les demandes explicites d'un interlocuteur humain, les réponses inutiles répétées et les tâches hors périmètre, puis testez chacun avant le lancement. Agentkit peut créer un dossier de support dans six systèmes externes de helpdesk ou de CRM connectés, mais son action générique Escalate to Human ne fait pas rejoindre le chat à une personne en direct.
Choisissez une destination, recueillez les coordonnées qu'elle exige et expliquez au client la suite du processus. La création réussie d'un ticket confirme que la demande a été enregistrée. Elle ne confirme pas qu'une personne l'a lue ni qu'elle répondra dans un délai donné.
Choisissez un transfert que votre équipe peut assurer
Un transfert en direct nécessite un canal avec du personnel disponible et une intégration qui permet à une personne de poursuivre la conversation. Un transfert par ticket enregistre la demande pour un suivi ultérieur. Les clients doivent savoir lequel ils obtiennent.
L'action générique Escalate to Human d'Agentkit prend en charge Zendesk, Freshdesk, Help Scout, Intercom, HubSpot et Salesforce. La destination reçoit un ticket, un dossier ou une conversation selon le fournisseur. Salesforce Live Chat est une action distincte. Choisir Salesforce comme destination de l'escalade générique crée un dossier, pas une session de chat en direct.
Agentkit Help Desk est une autre destination, native. Elle exige une conversation enregistrée, un forfait donnant accès au Help Desk et l'activation du Help Desk pour cet agent. Une adresse e-mail valide du demandeur est également nécessaire. Les tickets issus du chat du site n'ont pas de champ de rédaction de réponse dans la boîte du Help Desk et n'ajoutent pas au widget un canal de réponse humaine en direct. Votre équipe doit prévoir un autre moyen de suivi, comme sa propre adresse e-mail de support, avant d'activer ce processus.
Pour une destination externe, connectez le fournisseur et confirmez que votre forfait prend en charge l'action. Ajoutez ensuite l'action à l'agent et activez-la. Vérifiez ses autorisations et la boîte de réception de l'équipe destinataire avec une demande de test sans risque.
Définissez les déclencheurs à partir des décisions de support
Commencez par des décisions que votre équipe peut expliquer. Ne traitez pas chaque mention d'un "humain" ou chaque formulation négative comme une demande identique.
| Déclencheur | Exemple | Politique à tester |
|---|---|---|
| Demande explicite | "Je voudrais parler à une personne." | Proposez le parcours de support pris en charge et recueillez les coordonnées nécessaires. |
| Échec répété | "Cette réponse ne résout toujours pas mon problème." | Arrêtez de répéter le même conseil et proposez une escalade. |
| Hors des pouvoirs du bot | Une facturation contestée ou une demande de modification des accès au compte | Orientez vers l'équipe responsable au lieu d'inventer une décision ou de confirmer une modification non autorisée. |
| Urgence ou frustration | "Mon compte est bloqué et je ne peux pas travailler." | Proposez de l'aide rapidement en décrivant le véritable canal de suivi. Ne promettez pas une réponse d'urgence sans personnel disponible. |
| Règle client vérifiée | Un compte connu est éligible à un autre parcours de support | Utilisez des données clients fiables et un parcours configuré. Un visiteur qui se déclare VIP n'a pas vérifié son identité. |
Il s'agit de politiques recommandées, pas de déclencheurs déterministes intégrés que l'on active avec un bouton. L'action d'Agentkit possède des instructions When to use qui guident le modèle. Les instructions en langage naturel doivent être testées avec différentes formulations et dans les langues prises en charge. Elles ne fournissent pas à elles seules une évaluation fiable du sentiment, une vérification du statut VIP ou un compteur fixe de réponses rejetées.
La documentation d'Intercom sur l'escalade distingue les consignes en langage naturel, les règles fondées sur les données et le routage après escalade. Ces distinctions aident à évaluer un processus. Elles ne signifient pas qu'Agentkit implémente le système de règles d'Intercom.
Transmettez un contexte utile à la personne
Pour un fournisseur externe connecté, l'escalade d'Agentkit recueille un objet, un résumé du problème, une adresse e-mail valide et un nom lorsqu'il est disponible. Le contexte du ticket comprend jusqu'aux 50 derniers messages enregistrés qui ne sont pas des messages d'outil. Chaque message affiché est limité à 2 000 caractères. La demande actuelle est incluse lorsqu'elle est disponible.
Ce contexte est limité et ne garantit pas la transcription complète. Le résumé est limité à 2 000 caractères et l'objet à 150 caractères. La transcription affichée contient le texte des messages, pas les fichiers joints. Le fournisseur destinataire peut imposer des limites supplémentaires. Dans un long chat, un numéro de commande mentionné au début peut devoir être rappelé dans le résumé. Vérifiez ce que votre destination affiche réellement. Le ticket natif du Help Desk renvoie à sa conversation enregistrée. Ne supposez pas que son affichage est identique au corps d'un ticket chez un fournisseur externe.
Ne demandez que les informations dont l'équipe a besoin. Une adresse e-mail saisie permet un suivi, mais ne prouve pas que le client possède un compte. Ne demandez pas aux visiteurs de coller des mots de passe, des données de carte de paiement ou des identifiants privés dans le chat.
Un résumé utile indique ce dont le client a besoin, ce que le bot a déjà essayé et ce qui reste à résoudre. Si votre équipe exige un motif d'escalade identifié ou une file particulière, configurez et vérifiez ce processus. Ne supposez pas que l'action générique le fournit automatiquement.
Annoncez le suivi sans inventer de disponibilité
Dans un processus par ticket, dites au client que le support le recontactera via le canal convenu. N'annoncez un délai de réponse que si l'équipe destinataire en est responsable et peut le respecter. Ne dites pas "un conseiller rejoint la conversation" simplement parce qu'un ticket a été créé.
Pour les demandes reçues en dehors des heures de service, recueillez l'adresse e-mail requise et le résumé du problème, puis indiquez le résultat réel de la création. Si la connexion a expiré ou si la création du ticket échoue, proposez au client un autre moyen de contact fonctionnel. Un message rassurant ne remplace pas un dossier de support absent.
L'annonce de l'intégration Zendesk par Chatbase explicite la même distinction entre les canaux. Son processus par ticket prévoit un suivi par e-mail. Son intégration Sunshine est un parcours distinct pour le chat en temps réel. Vérifiez l'intégration réelle avant de promettre un transfert en direct.
Un exemple d'instruction à adapter
Le modèle suivant, en anglais, constitue une politique de départ pour un processus par ticket. Ce n'est ni un classificateur testé ni une règle de routage exécutable.
Use the support-ticket action when the visitor clearly asks for a person, says the suggested answer did not help, or needs a decision outside your authority. Before calling it, collect or confirm a valid follow-up email and summarize the unresolved issue. Do not ask for passwords or payment-card details. After a successful result, explain that the request was recorded for follow-up. Do not claim a human has joined or promise a reply time unless the business has supplied a supported commitment. If creation fails, explain the problem and provide the business's alternative support contact. Do not say a ticket was created when the action failed.
Placez les consignes de déclenchement dans les instructions When to use de l'action. Gardez les attentes annoncées aux clients cohérentes avec vos instructions d'agent. Testez le processus complet, y compris la boîte de réception destinataire, au lieu de vérifier seulement les formulations du bot.
Vérifiez le processus avant le lancement
Utilisez des demandes fictives et une adresse de support que vous contrôlez. Les cas ci-dessous sont une grille de validation, pas des résultats de tests déjà effectués.
| Cas de test | Points à vérifier |
|---|---|
| Demande claire d'une personne | La bonne action activée est proposée ou appelée après la collecte des informations requises. |
| Deux réponses infructueuses | Le bot propose une escalade au lieu de répéter le même conseil. Ce seuil est votre politique de test, pas un compteur intégré. |
| Aucune adresse e-mail connue dans la conversation ou la fiche du contact | Le bot demande une adresse e-mail valide avant de tenter la création. |
| Longue conversation | Le dossier reçu contient un contexte récent utile. Les détails importants plus anciens sont conservés dans le résumé. |
| Fournisseur déconnecté | Le bot signale l'échec et indique le parcours de support alternatif configuré. |
| Help Desk désactivé | Le bot n'annonce pas la création réussie d'un ticket natif. |
| Demande hors horaires | Le bot décrit correctement le suivi sans inventer de file en direct ni de délai de réponse. |
| Demande d'escalade répétée | Vérifiez si le dossier existant est réutilisé et si le client reçoit un statut exact. |
Notez l'identifiant du dossier reçu et vérifiez qu'une équipe désignée peut le retrouver. Répétez les cas de déclenchement dans chaque langue que vous proposez. Un message qui paraît correct dans le chat ne constitue qu'une partie de la validation.
Mesurez séparément la création et la réponse
Suivez les tentatives d'escalade, les créations de dossiers réussies, les échecs de transmission et le délai avant la première réponse humaine. Utilisez les horodatages du helpdesk destinataire ou votre propre instrumentation pour mesurer ce délai. Les journaux de conversation d'Agentkit seuls ne constituent pas un tableau de bord complet du temps de transfert ou de la satisfaction après transfert.
Examinez un échantillon de cas escaladés pour repérer le contexte manquant et les questions répétées. Si vous mesurez la satisfaction, conservez le nombre de réponses et le canal à côté du score. Le guide des KPI de chatbot explique pourquoi le traitement sans escalade et la résolution doivent avoir des définitions distinctes.
Commencez avec une destination prise en charge et une équipe responsable du suivi. Configurez l'action d'escalade, exécutez les cas de validation et confirmez la réception avant d'inviter les clients à l'utiliser.
À lire également :
