Notre équipe est engagée dans l'automatisation du service client depuis plus de deux ans. Récemment, nous avons réalisé que la connexion de chatbots et d'assistants virtuels ne profite pas toujours aux entreprises.
Pour voir cela, imaginez cette situation: vous êtes un directeur dans une grande banque, où il est difficile pour les clients de se connecter à une application mobile - chaque seconde tombe en panne au stade de la connexion, car la connexion est aussi difficile que de maîtriser le grand théorème de Fermat.
Vous avez deux options:- Corrigez le processus d'autorisation - concevez normalement des écrans et mettez fin aux tourments des utilisateurs. Cela coûtera des roubles NNN.
- Automatiser le support - connectez un assistant virtuel qui apprendra aux clients comment utiliser l'application. Cela coûtera de NN roubles.
L'automatisation de l'assistance et l'embauche d'un robot sont généralement moins onéreuses que la mise à l'esprit des processus dans une application. Par conséquent, les gestionnaires à courte vue choisissent maintenant la deuxième option - ils comptent sur la première ligne de support pour fermer les trous dans les produits.
Cela est particulièrement vrai pour les innovateurs commerciaux (fintech, voyages, télécoms, e-commerce) - ils ont déjà mis en place avec succès des assistants virtuels et ont pu leur poser la plupart des problèmes. En conséquence, le support fonctionne parfois comme un bouchon pour fermer les trous dans un bateau.
Affaire. La banque voulait que notre assistant virtuel coordonne la livraison des cartes avec les clients. Au cours de l'automatisation du script, il s'est avéré que le processus lui-même a été mal construit: l'utilisateur sélectionne d'abord la région, puis la carte est amenée à la ville souhaitée et ensuite seulement l'adresse de livraison est convenue.
Cette approche conduit à un tas de problèmes avec ceux qui n'ont pas prêté attention à l'article sur la ville - il est prérempli comme "Moscou" et beaucoup ne le remarquent tout simplement pas. En conséquence, le robot appelle le client et lui dit: "Bonjour, votre carte à Moscou, quand est-il pratique de livrer?", Et le client répond: "Bl **, je suis à Novossibirsk, comment ça va?"
Il n'est pas difficile de résoudre un tel processus: il suffit de demander clairement dans l'application où prendre la carte. Mais nous avons dû apprendre au robot à répondre correctement à l'articulation et à envoyer des cartes à d'autres régions.
En conséquence, la banque a perdu de l'argent à la livraison et a résolu le bogue avec l'aide du support, bien que cela valait la peine de terminer le processus de demande - il n'y aurait aucun problème.
Ce n'est pas un cas isolé. Nous avons analysé les demandes de 6 millions d'utilisateurs et constaté que la douleur la plus courante était les jambages banaux du produit.
5 des 10 scénarios les plus fréquents (en fintech, commerce de détail, télécommunications) peuvent être fermés si vous modifiez les processus métier ou changez la conception UX.
Mais la question est de savoir comment l'équipe produit sait
ce qui doit être amélioré?
Les bots peuvent donner une réponse. Nos réseaux de neurones regroupent les demandes des utilisateurs et les messages de groupe du même type en groupes (clusters): plus le groupe est grand, plus le problème est aigu et populaire. Si vous regardez le cluster, vous pouvez comprendre ce qui mérite d'être réparé pour faciliter la vie des utilisateurs.
Au cours de la dernière année de travail avec de tels cas, nous avons conclu que l'automatisation du support n'est pas toujours bonne si nous oublions de résoudre les problèmes de produit: changer les processus et la conception, établir la bonne communication. Mais alors que le support consiste à faire face et à enseigner aux clients comment utiliser ce qu'ils ont, peu de gens le prennent au sérieux.
Et les assistants sont en partie à blâmer.Fonction oubliée: communication
Essayer de fermer tous les trous d'un produit avec un robot n'est pas le seul problème que les assistants virtuels créent pour une entreprise.
Avec l'avènement de l'automatisation sur les premières lignes de support, tout le monde a oublié d'apporter à l'entreprise des informations sur les défaillances du système et la douleur des utilisateurs. Nous nous sommes concentrés sur la plupart des services d'assistance, mais nous n'avons pas réfléchi à la manière d'établir une communication avec les chefs de produit.
Par conséquent, une fois que nos collègues d'Ukraine se sont retrouvés dans cette situation: ils ont lancé un assistant dans une grande banque et n'ont pas configuré correctement l'algorithme de commutation pour l'opérateur. Lorsque la fonctionnalité de paiement de base a échoué et que les demandes des clients ont chuté, le robot était stupide, a demandé de reformuler la question, ou otmazyvatsya: "Oui, oui, nous allons le réparer bientôt."
C'était le deuxième jour, l'assistant a continué de consoler les utilisateurs, et personne à l'intérieur de la banque n'était au courant de l'incident. Il était difficile de le remarquer sur les analyses - les fonctionnalités ne tombaient pas partout, mais seulement sur un petit segment.
Eh bien, il y avait des clients en colère qui ont contourné le robot: quelqu'un l'a brisé par des jurons qui les ont forcés à passer à l'opérateur, quelqu'un a téléphoné aux gestionnaires et a signalé une panne. La banque a finalement réalisé ce qui n'allait pas et n'a résolu le problème que le deuxième jour.
C'était un cas cool qui a montré un bug dans le robot de communication → gestionnaire. Nous avons réalisé que nous devions créer un modèle et établir une connexion d'urgence entre les assistants et les produits.
Comment nous avons appris aux assistants à parler des problèmes
Tout d'abord, nous devions comprendre de quoi informer les produits - en d'autres termes, ce qui est considéré comme un incident et ce qui ne l'est pas.
Afin que le robot apprenne à comprendre les paramètres du volume de demandes et à distinguer les erreurs de masse des petites erreurs, nous l'avons formé à déterminer l'incident selon plusieurs critères:
- Nombre d'utilisateurs - selon l'historique des messages du client, le robot reconnaît le nombre approximatif d'utilisateurs actifs et détermine le pourcentage d'appels pouvant être considéré comme critique.
- La durée pendant laquelle les messages sur le problème arrivent - lorsque le robot voit une forte augmentation d'appels identiques, il le corrèle avec le nombre de clients: si l'erreur est massive, il déclenche un incident (la similitude est déterminée par notre réseau neuronal de base, qui reconnaît la signification des appels dans le texte).
L'algorithme de clustering identifie des groupes d'appels similaires, qu'ils soient ou non dans le balisage. Si les utilisateurs contactent le support de masse et que la dynamique des messages augmente au cours des dernières minutes / heures / jours - c'est un incident.
Pas encore parfait, mais nous avons appris à résoudre le problème de la communication avec les employés de l'entreprise. Si l'assistant comprend qu'un problème est survenu, il agit selon cet algorithme:
- Démarre un incident et envoie des notifications aux employés responsables par numéros de téléphone / e-mail prédéfinis.
- Il demande à écrire un message qui sera envoyé aux utilisateurs en réponse: par exemple, "la réparation prendra deux heures, nous nous excusons" .
- Après avoir corrigé le bug, l'assistant ferme le ticket et peut écrire à toutes les victimes: "Hourra, nous avons tout corrigé. " Ceci est pratique, car vous n'avez pas à envoyer de réponse dans toute la base de données - le robot se souvient uniquement des personnes affectées par le problème.
Lorsque l'assistant a commencé à signaler des défaillances massives, nous avons constaté que de nombreuses erreurs étaient liées à des problèmes techniques. Et nous avons appris à y répondre rapidement.
Par exemple, lorsque la logique des paiements budgétaires s'est envolée vers nous et que les utilisateurs n'ont pas pu payer de taxes, le robot a envoyé un rapport d'erreur en une heure. L'équipe a rapidement annulé la version et a rapidement résolu le problème.
C'est bien mieux que d'écrire:
"Oui, oui, bientôt tout ira bien .
" Et plus honnête vis-à-vis des utilisateurs.
Généralement, toutes les personnes impliquées dans la prise en charge de l'automatisation du support se concentrent sur l'enseignement aux robots de la manière de réagir rapidement, efficacement et à moindre coût. Mais ils manquent un point important: les tâches d'un responsable du support sont plus larges que la simple rédaction d'une réponse.
Lorsque nous avons commencé à étudier en profondeur toutes les fonctions du rôle que nous essayons d'automatiser, nous avons vu qu'un bon service client était lorsque le support contactait l'équipe et leur parlait des douleurs des utilisateurs, et l'entreprise finalisait son produit.
Sinon, le support devient une béquille permanente pour l'entreprise: il ferme les trous et les otmazyvatsya au dernier, au lieu de résoudre les problèmes.