Quand le chatbot doit s'arrêter et passer la main à une personne

Un assistant automatique se juge surtout à la façon dont il s'arrête. Répondre aux questions faciles est la partie simple ; les problèmes naissent quand le système continue à répondre dans des situations où il aurait dû passer la main. Le dommage n'est pas une réponse imprécise sur un horaire : c'est une réponse assurée sur une condition contractuelle, ou sur une panne qui aurait pu être dangereuse.

Les limites s'écrivent avant, avec ceux qui font le métier. Elles ne se découvrent pas en exploitation, en lisant les conversations qui ont mal tourné.

Les questions qu'il ne doit pas traiter

La première liste ne concerne pas ce que le système sait, mais ce qu'il ne doit pas faire même quand il saurait répondre.

• Engagements : prix hors tarif, délais promis, conditions contractuelles, dérogations. Ce sont des choses qui engagent l'entreprise.
• Sécurité et santé : tout soupçon de risque pour les personnes ou pour une installation doit être porté à un opérateur, pas géré avec des instructions.
• Données personnelles et dossiers : demandes qui concernent l'identité, les paiements ou les documents de quelqu'un.
• Réclamations : quelqu'un qui écrit fâché ne veut pas une procédure, il veut une personne. Insister aggrave une situation déjà tendue.
• Cas qui exigent un jugement : si pour répondre il faut voir, essayer ou décider, ce n'est pas une matière pour un assistant.

Cette liste est aussi le moyen le plus efficace de faire accepter le projet en entreprise : celui qui craint que le système ne dise des bêtises à sa place a besoin de voir par écrit ce qu'il ne touchera pas.

Les conditions de passage

Au-delà des cas exclus, il y a les situations où la conversation, selon la façon dont elle se déroule, doit être close et transférée.

La troisième ligne est celle qu'on oublie le plus souvent et c'est la plus utile, car elle ne dépend d'aucune estimation interne au système : si une personne reformule la même question, la réponse précédente n'a pas fonctionné, quoi qu'en disent les registres.

Ce qu'il faut transmettre à l'opérateur, et ce qu'il ne faut pas

Le passage est utile si celui qui reçoit n'a pas à recommencer depuis le début. Il est nuisible s'il lui décharge une demi-heure de conversation à lire.

• Utile : la demande initiale avec les mots de l'utilisateur, les données déjà recueillies, ce que l'assistant a déjà essayé et pourquoi il s'est arrêté.
• Utile : d'où vient la personne, c'est-à-dire la page ou le canal, car cela explique le contexte de la question.
• Inutile : la transcription intégrale quand elle est longue. Un résumé, avec le texte complet disponible sur demande, fonctionne mieux.
• Ne doit pas passer : les informations recueillies à d'autres fins et les données dont l'opérateur n'a pas besoin pour répondre.

Il faut dire à l'utilisateur ce qui est transféré. C'est à la fois une courtoisie et une protection : celui qui sait que ses mots sont transmis n'est pas surpris qu'on le rappelle sur ce qu'il a écrit.

Le passage doit finir entre les mains de quelqu'un

C'est le point où ces projets échouent le plus souvent, et cela n'a rien à voir avec la technologie.

1. Établir où arrive le passage — une file, une boîte, un chat interne — et qui la surveille pendant les heures de travail.
2. Établir ce qui se passe hors horaires : si personne ne répondra avant le lendemain, l'utilisateur doit le savoir avant de fermer la conversation.
3. Enregistrer la prise en charge : sans cela, personne ne sait si le passage a abouti ou est tombé dans le vide.
4. Compter les passages non recueillis. C'est le seul chiffre qui dit si la promesse « nous vous mettons en contact avec une personne » est vraie.

Trois conversations, trois issues

• Résolu. « Assurez-vous aussi l'assistance sur des installations posées par d'autres ? » L'information se trouve dans les sources autorisées : l'assistant répond, indique la page d'où vient la réponse et propose l'étape suivante.
• Clarification. « Ça ne fonctionne plus. » La question est trop vague : l'assistant demande une fois de quel produit il s'agit. Si la réponse reste générale, il passe la main à une personne au lieu d'essayer de deviner.
• Passage. « Me faites-vous une remise si j'en commande dix ? » Cela relève des engagements. L'assistant ne négocie pas : il dit que la demande va à un commercial, recueille les données minimales et confirme ce qui va se passer.

Quand le passage humain n'est pas la réponse

• Si presque toutes les conversations finissent en passage, l'assistant n'aide pas : il ajoute une étape avant le téléphone. Mieux vaut le restreindre aux quelques choses qu'il fait bien, ou y renoncer.
• S'il n'y a personne pour prendre en charge, la fonction doit être retirée : promettre une personne qui n'arrive pas coûte plus cher que ne pas la promettre.
• Si le problème est que les informations publiques sont incomplètes, le passage cache la cause au lieu de la résoudre, et la charge se déplace sur l'assistance.

Ce que ce guide ne couvre pas

Ici, on parle de limites, de passage et de continuité : quand s'arrêter, quoi transférer, comment vérifier que quelqu'un recueille. Le choix des parcours à offrir aux clients — assistant, centre d'assistance, opérateur — vient avant cette décision. Et la façon de vérifier que les réponses sont correctes, avec des tests reproductibles, est un travail à part que ce guide ne remplace pas.