Pourquoi la plupart des chatbots d'entreprise déçoivent — et ce qu'il faut construire à la place

Un chatbot répond ; une entreprise ferme ses portes

On demande au chatbot à quoi il sert, on obtient généralement : « Il répond aux questions sur nos produits » ou « Il aide les employés à trouver les politiques ». Cela semble utile. Ce n'est pas tout à fait le cas.

Personne n'a pour tâche de recevoir une réponse. Quelqu'un est chargé de traiter un remboursement, d'approuver une commande, de reprogrammer une installation, de confirmer une réclamation de garantie ou d'obtenir un contrat auprès du service juridique. Une réponse est l'étape intermédiaire de cette tâche. Un système qui s'arrête à la réponse renvoie le travail à la personne qui essayait de le déléguer.

Ainsi se déroule l'interaction : le client pose une question sur son commande retardée, le bot explique la politique d'expédition, et le client demande à parler à un être humain car la politique n'était pas le point. Le bot a accompli sa mission et a tout de même échoué.

Les trois façons dont ils échouent

La plupart des déploiements décevants partagent quelques traits communs :

• Aucun accès aux systèmes en direct. Le bot a été formé sur des documents. La question du client porte sur sa commande, son facture, son compte. Un bot sans accès au système de commande ne peut que parler en généralités, et les généralités sont celles que la page FAQ a déjà faites.
• Aucune capacité d'action. Même s'il connaît la réponse, il ne peut pas accomplir la tâche. Chaque conversation se termine par un transfert, ajoutant ainsi une étape plutôt qu'en supprimant une.
• Aucune définition de la réussite. Personne n'a défini au préalable ce qui constitue un bon résultat, donc personne ne peut dire si le bot fonctionne ou non. Les comptes d'utilisation augmentent, le volume des centres de contact ne diminue pas et le projet cesse d'être discuté.

Sous les trois se trouve une décision : le projet a été défini comme un canal - un nouvel endroit pour parler à l'entreprise - plutôt que comme une capacité, un moyen d'accomplir plus de travail avec les mêmes personnes.

Construire un complétur de tâches au lieu de cela

L'alternative n'est pas plus sophistiquée. Elle est plus étroite et plus profonde.

Choisissez une tâche à fort volume. Pas un sujet, une tâche - « reprogrammer une livraison », pas « questions logistiques ». Une tâche qui se produit des centaines de fois par mois et suit un chemin connu.

Donnez au système les deux choses dont il a besoin pour terminer réellement cette tâche : l'accès en lecture aux systèmes qui détiennent la vérité, et l'accès en écriture à une ou deux actions que la tâche exige. S'il peut rechercher la livraison, proposer des créneaux horaires réels et modifier la réservation, il a remplacé un appel téléphonique. S'il ne peut décrire que la politique de reprogrammation, il n'a rien remplacé.

Déterminez ensuite ce qu'il fait lorsqu'il ne peut pas terminer. C'est la partie que la plupart des projets oublient, et elle renforce la confiance plus que toute quantité d'ajustement de modèle. Définissez les conditions dans lesquelles il s'arrête et transmet à une personne - faible confiance, état inhabituel du compte, tout impliquant un montant d'argent au-dessus d'un seuil - et faites en sorte que le transfert porte l'ensemble du contexte afin que le client ne doive pas répéter ses questions. Un système qui termine 60 % des cas sans intervention humaine et qui escalade les 40 % restants avec un résumé concis bat un système qui tente 100 % et se trompe sur un cinquième d'entre eux.

Enfin, convenez du nombre avant de construire. Pourcentage de demandes de reprogrammation terminées sans intervention humaine. Temps moyen de traitement pour celles qui sont escaladées. Taux de contacts répétés dans les 48 heures. Un ou deux chiffres, mesurés par rapport au mois précédent le lancement. Si ils ne bougent pas, vous avez appris quelque chose à moindre coût et tôt.

Ce que cela change dans le plan

Définir ainsi l'étendue du projet le rend plus petit et l'intégration plus importante, ce qui est inconfortable pour quiconque a acheté un chatbot en s'attendant à une configuration de deux semaines. La couche conversationnelle est maintenant la partie facile. Le travail réside dans les permissions, l'accès aux systèmes, la piste d'audit et le chemin d'escalade - la plomberie peu glamour qui décide si la chose peut porter du poids ou non.

C'est également pourquoi le spécifique bat le général. Une tâche accomplie complètement mérite le droit d'ajouter une seconde. Un système couvrant quarante sujets de manière superficielle ne vaut rien, car il n'y a aucune tâche unique à laquelle quelqu'un puisse pointer et dire : cela prenait quatre minutes et maintenant ça ne prend plus rien.

Nous construisons ce second type. Le premier est plus facile à lancer mais beaucoup plus difficile à maintenir.