3 types de contexte dont chaque agent IA a besoin, et celui que tout le monde oublie

Les agents IA s'appuient sur de nombreuses données pour mener une conversation : un modèle, une base de connaissances, un ensemble de règles, les données de votre CRM, et tout ce qui semble pertinent.

Ce qui manque généralement, c'est le contexte produit : le signal en temps réel et historique de ce que les gens font réellement dans votre produit. Il a été difficile d'y accéder, mais les équipes qui ont trouvé un moyen d'y parvenir ont vu les performances des agents s'améliorer considérablement.

Dans ce contexte, les agents répondent avec plus de précision et passent directement à la solution qui convient réellement, plutôt qu'à la correspondance la plus proche dans une base de connaissances.

Trois types de contexte dont chaque agent a besoin

Il existe trois types de données sur lesquelles un agent devrait s'appuyer :

1. Contexte commercial : la valeur annuelle du contrat du compte, son segment et ses données firmographiques.
2. Contexte utilisateur : l'enregistrement CRM d'un compte, son rôle et son niveau.
3. Contexte produit : les actions effectuées par un utilisateur dans votre produit, la fréquence à laquelle il se connecte, et où il se trouvait dans votre produit avant d'ouvrir le chat.

Les deux premiers sont courants. La plupart des CRM transmettent le contexte métier et utilisateur à tout agent qui le demande et est correctement configuré. Le contexte produit, en revanche, se trouve ailleurs. Il provient de votre plateforme d'analyse, le même système qui suit le comportement in-app pour vos chefs de produit et développeurs.

La base de connaissances indique à un agent ce que fait une fonctionnalité, tandis que le contexte produit lui indique que cet utilisateur spécifique a accédé à cette fonctionnalité sept fois au cours de trois sessions, a commencé la configuration à chaque fois sans la terminer, puis est revenu pour réessayer — ce qui produit une réponse différente de tout ce que la base de connaissances seule peut fournir.

Pour les créateurs qui exécutent un agent sur plusieurs applications, les mêmes données produit peuvent suivre le parcours d'une personne à travers tous ses points de contact.

Donner à votre agent des signaux qui lui permettent d'intervenir avant qu'un utilisateur demande de l'aide

Les clics de rage, les clics morts, les tentatives répétées infructueuses et l'abandon de flux de travail sont des signaux produit. La plupart des agents n'y ont pas accès, mais ceux qui y ont accès effectivement peuvent cesser d'attendre qu'on le leur demande.

Un agent d'assistance qui détecte qu'un utilisateur a réessayé la même action trois fois en quatre minutes peut afficher un message spécifique et contextuel au point de friction, avant que la frustration ne se transforme en conversation avec le support ou en quelque chose de pire.

La distinction entre un agent réactif et un agent proactif tient aux signaux auxquels il a accès et à la rapidité avec laquelle ces signaux arrivent pour pouvoir agir dessus.

Actuellement, l'impact du contexte produit sur les agents se manifeste principalement dans le domaine du support. Donnez à votre agent de support Fin, Decagon, Sierra ou développé en interne un comportement in-app, et ils pourront :

• Voir où les utilisateurs abandonnent et intervenir pour les guider tout au long du flux de travail
• Offrir des conseils lorsque les utilisateurs font des clics répétés ou des allers-retours
• Guider les utilisateurs à travers la configuration et les tâches qui influencent leur réussite dans l'application

Teachable a intégré le contexte Pendo dans son agent de support Fin et a réussi à résoudre 67 % des tickets de support sans intervention humaine. En savoir plus sur leur approche.

Questions à poser avant votre prochain sprint d'agent

La plupart des équipes n'ont pas de réponse claire sur ce que leur agent sait de l'utilisateur avec lequel il interagit. Avant le prochain cycle de développement de fonctionnalités, posez-vous les questions suivantes :

1. Votre agent sait-il ce qu'un utilisateur a fait dans l'application avant d'interagir avec lui ?
2. Sait-il si l'utilisateur a déjà été bloqué sur le même problème auparavant ? Si oui, combien de fois ?
3. Sait-il si les conversations précédentes ont résolu le problème sous-jacent ? Ou l'utilisateur a-t-il simplement abandonné et quitté votre application ?

Si la réponse à ces trois questions est non, votre agent a ensuite besoin du contexte produit à partir duquel raisonner.