Service client IA : votre file d'attente fixe le plafond
Recherchez le service client AI et vous obtenez des guides des fournisseurs. Ils suivent un arc : la file d'attente est chère, le modèle est performant, voici les fonctionnalités, et voici la proportion de tickets que nos clients résolvent désormais sans personne. Les listes de fonctionnalités sont globalement précises. Le numéro à la fin est la partie à ignorer, car il s'agit d'une mesure de la file d'attente de quelqu'un d'autre.
La part de votre charge de support qu'un modèle peut fermer tout seul dépend principalement de la composition de vos billets, et seulement légèrement du produit que vous achetez. Deux entreprises de même taille dans le même secteur peuvent avoir des plafonds très éloignés les uns des autres, et le même vendeur leur montrera la même projection.
Le travail utile n’est donc pas une liste restreinte de fournisseurs. Il s'agit de trouver votre propre plafond, de décider de ce que vous refuserez d'automatiser avant que quiconque ne construise et d'instrumenter la seule mesure que ces systèmes ne rapportent pas.
##Pourquoi aucun transfert de chiffre de confinement publié
Quatre éléments font varier ce chiffre bien plus que la qualité du modèle, et tous les quatre sont des propriétés de l'entreprise plutôt que du logiciel.
Quelle part de vos connaissances est écrite. Un modèle de réponse provenant de votre centre d'aide est limité par votre centre d'aide. Si les vraies réponses résident dans la tête de trois agents de longue date, la récupération n’a rien à récupérer et la première phase du projet est la documentation plutôt que l’automatisation.
À quelle fréquence résoudre un ticket signifie changer quelque chose. Une réponse est bon marché et une écriture ne l'est pas, car l'écriture doit exister comme quelque chose qu'un système peut appeler, et quelqu'un doit décider si une erreur peut être annulée.
À quel point votre produit est compliqué sur les bords. Facturation au prorata, règles d’éligibilité, compatibilité entre versions. Chaque exception dans la politique est un endroit où une mauvaise réponse est possible.
Ce pour quoi vos clients vous contactent alors qu’ils sont déjà mécontents. Une file d'attente contenant beaucoup de cela a un plafond plus bas et un coût plus élevé en cas d'erreur, quoi que le modèle puisse analyser.
Aucun de ces éléments n’apparaît dans une étude de cas, c’est pourquoi un tarif proposé par une autre entreprise ne vous dit presque rien sur le vôtre.
Comptez votre propre mélange et ajoutez la pile que le tri manque habituellement
L'exercice en lui-même n'est pas compliqué : prenez un vrai mois de tickets et triez chacun en fonction de la clôture qu'il nécessite. L'article sur le chatbot présente ce type dans son intégralité, car le même décompte décide également de la forme de système dont vous avez besoin, et cela vaut la peine de le faire une fois plutôt que deux.
Une pile y manque généralement lorsque le sujet est spécifiquement le support. À côté des tickets qui nécessitent des informations, ceux qui nécessitent une action et ceux qui nécessitent un jugement, il existe une pile où le contenu de la réponse n’est pas du tout le problème. Le client est déjà en colère, vous a déjà contacté deux fois ou vous signale que quelque chose ne va vraiment pas. Une réponse techniquement correcte dans cette pile ne résout rien et aggrave parfois le résultat. Comptez cette pile séparément et gardez-la volontairement hors de la portée de l'automatisation, plutôt que de la découvrir plus tard dans une transcription.
La déviation et la résolution ne sont pas la même mesure
La métrique que ces plates-formes signalent le plus facilement est une version de déviation : la conversation s'est terminée sans humain. C’est facile à instrumenter et, en tant qu’objectif, c’est activement dangereux, car le moyen le moins coûteux de mettre fin à une conversation sans humain est de ne pas aider jusqu’à ce que le client abandonne.
La mesure qui signifie quelque chose est la résolution, et vous ne pouvez la voir que plus tard. Le même client est-il revenu sur la même chose en une semaine ? Ont-ils ouvert un deuxième ticket par un autre itinéraire, par email ou par téléphone, après la clôture du chat. Ont-ils arrêté de vous contacter et également arrêté d'acheter.
Instrumentez le contact répété avant le lancement plutôt qu’après. C'est le chiffre qui détecte l'échec que personne ne signale, et il sera absent de chaque tableau de bord qui vous sera présenté dans une démo.
Décidez de ce que vous refuserez avant que quoi que ce soit ne soit construit
Ceux-ci sont beaucoup plus difficiles à récupérer une fois qu’un flux existe et qu’une métrique en dépend.
Tout ce qui déplace de l’argent sans chemin d’inversion. Un remboursement que vous pouvez annuler représente un risque différent d'un paiement que vous ne pouvez pas, et la distinction n'est pas le montant, mais plutôt la question de savoir si une erreur peut être corrigée le jour même.
Tout ce qui concerne la sécurité, la santé ou juridiquement contraignant. Non pas parce qu’un modèle ne peut pas produire la phrase, mais parce que la phrase crée une obligation, et une obligation a besoin d’une personne à qui on peut demander pourquoi.
Tout deuxième contact sur le même problème. Si le client est de retour, le système a déjà fait sa tentative. Les acheminer à nouveau vers le même flux est le moyen le plus fiable de transformer un client agacé en un ancien client, et il s'agit généralement d'un accident dans l'acheminement plutôt que d'une décision prise par quelqu'un.
Tout ce qui se trompe est invisible pour le client. Une réponse incorrecte en toute confiance concernant un délai, une règle d'éligibilité ou une question de compatibilité est crue et prise en compte. Le ticket se ferme, la métrique s’améliore et les dégâts font surface ailleurs des semaines plus tard.
Ce dernier argument plaide en faveur d’un ensemble d’évaluation plutôt que d’un projet pilote. Construisez-le à partir de tickets résolus réels dont vous connaissez déjà le résultat correct, et testez-les avant le lancement. C'est la méthode de l'article sur l'évaluation de la sortie LLM appliquée à une file d'attente plutôt qu'à une fonctionnalité, et c'est le seul moyen de détecter une mauvaise réponse dont personne ne se plaint.
L'échec que l'on impute généralement au modèle
Les déploiements de support les plus décevants ne manquent pas de compréhension. Ils échouent une étape plus tard.
Le système lit correctement le ticket, détermine que la bonne solution est de réémettre la livraison et n'a nulle part où envoyer cette instruction, car la réémission d'une livraison est quelque chose que trois personnes font manuellement dans un outil interne sans interface à appeler. Il fait donc la seule chose à sa disposition et écrit un message poli indiquant que quelqu'un vous contactera.
Il s'agit d'une file d'attente comportant une étape supplémentaire. Le moyen le moins coûteux de savoir si vous en achetez un est de prendre vos principaux types de billets et de demander, pour chacun, si la résolution est une action qu'un système peut effectuer aujourd'hui. Les réponses définissent l'ordre du travail et signifient souvent que la première phase est l'intégration plutôt que tout ce qui a trait à un modèle, qui est la question d'intégration plutôt qu'un modèle de support. Une version structurée du même audit couvrant plus que le support est ce que parcourt l'évaluation de l'état de préparation à l'IA.
Quatre questions qui coupent le terrain sans démo
Que se passe-t-il lorsque le système n'est pas confiant et ce comportement est-il configuré ou espéré ? Tout ce qui n'a pas de chemin explicite de faible confiance en a un de toute façon, et il s'agit généralement de répondre.
Peut-il confier une conversation à une personne avec le contexte attaché, puis rester en dehors de celle-ci. Un système qui reprend après une conversation humaine est pire que rien.
Pouvez-vous lire, des mois plus tard, exactement ce qu'il a dit à un client nommé un jour donné. Sans cela, il n’y a aucun moyen de revoir les limites et aucun moyen de répondre à une plainte.
À qui appartiennent les règles d’escalade, par écrit. Le support en est propriétaire, pas le fournisseur ni celui qui a configuré l'outil en dernier. Ce sont des politiques commerciales revêtues d'un costume technique, et elles dérivent dès que personne ne les possède.
Commencez avec un type de ticket
La version qui fonctionne est plus étroite que la version de la proposition. Prenez le type le plus volumineux dont la réponse existe déjà par écrit, automatisez-le seul et faites remonter tout ce qui ne lui correspond pas proprement.
Cela semble peu ambitieux à côté du déploiement d'une plate-forme, et c'est la seule configuration qui vous indique votre plafond réel sur votre propre file d'attente plutôt que sur celle d'un client de référence. Une fois que ce premier type est résolu plutôt que dévié, les arguments en faveur du second sont plus petits et vous les faites avec vos propres preuves. Ce qui change une fois que le système tient une véritable conversation plutôt que de répondre à une question à la fois, c'est l'étape suivante, et non le point de départ.