Audits et tests
Tous les niveaux de couverture qualité, des scénarios que vous concevez avant le lancement aux sessions échantillonnées automatiquement en production.
Qu'est-ce que les audits et les tests ?
Les tests ont lieu avant le déploiement. L'audit a lieu en production. Ils répondent à des objectifs différents et fonctionnent ensemble : les tests valident que votre agent se comporte correctement dans des scénarios connus ; les audits détectent les écarts dans le monde réel.
Faites en sorte que votre couverture de tests se renforce dans le temps
Tests personnalisés
Chaque test personnalisé évalue trois éléments indépendamment : le scénario d'entrée, la réponse attendue et les appels d'outils attendus. Un test peut réussir sur le contenu de la réponse et échouer sur l'invocation d'outil — les deux sont suivis séparément, afin que le point exact de déviation soit toujours visible
Les tests de régression s'enrichissent automatiquement
Les tests de régression sont capturés. Lorsqu'un échec en production est identifié et résolu, cette session est figée comme cas de test. Chaque version suivante est exécutée face à tous les échecs déjà rencontrés par le système : la suite de régression s'étend donc automatiquement à mesure que l'agent gagne en maturité
Exécuter les tests en suites
Les tests personnalisés et de régression peuvent être regroupés en suites et exécutés ensemble en une seule opération. Utilisez les suites pour valider une version complète avant sa promotion : une seule exécution couvrant l'ensemble des scénarios conçus et tous les échecs passés simultanément.
La bonne couverture d'audit au bon volume
Taux d'échantillonnage
L'échantillonnage d'audit se configure entre 1 et 100 %. À fort volume de sessions, un échantillonnage total est irréaliste. Un taux de 1 à 10 % à grande échelle fait tout de même apparaître les problèmes systémiques. Le bon taux dépend du volume de sessions et du niveau de risque porté par un workflow donné.
Conditions d'audit
Les conditions filtrent les sessions éligibles à l'échantillonnage avant l'application du taux d'échantillonnage. Filtrez par résultat d'appel, type de routage, version de workflow ou toute variable personnalisée, afin de n'appliquer des taux d'échantillonnage élevés qu'aux sessions présentant le plus de risque opérationnel ou de conformité.
Ce que contient une remarque d'audit
Chaque remarque renvoie quatre champs : la réussite ou l'échec de la session au regard de l'indicateur phare, une correction suggérée en cas d'échec, le raisonnement qui sous-tend cette correction, et un statut (ouvert, résolu ou rejeté) — les constats peuvent ainsi être triés sans quitter la plateforme.
Les sessions en échec renforcent les agents
De l'échec au test de régression
Une session en échec peut être convertie instantanément en test de régression. L'échec est figé dans la suite et validé automatiquement à chaque version future, afin que le problème ne puisse pas réapparaître.
Retour d'audit et calibrage de l'indicateur phare
Chaque remarque d'audit peut recevoir un pouce vers le haut ou vers le bas. Ce retour ajoute directement la session à l'indicateur phare concerné comme exemple de calibrage. La précision se renforce à mesure que le nombre de sessions revues augmente.
Les signalements manuels comme données structurées
Les signalements manuels sont rattachés à un moment précis d'une transcription, avec un type de problème structuré et un niveau de priorité, et alimentent le même workflow de triage que les constats automatisés.