Tests
Un test, c'est un appelant avec un objectif. Vous décrivez qui appelle, ce qu'il veut, ce qu'il sait, comment il se comporte, et ce qui doit se passer pour que le test réussisse. Agent Lab joue l'appelant et examine l'appel. Vous pouvez écrire un test en une phrase, remplir un formulaire, ou laisser le Lab générer des tests à partir de votre flux, d'une bibliothèque d'appelants difficiles ou de vos vrais appels.
Ce que contient un test
| Partie | Signification | Exemple |
|---|---|---|
| Titre | Comment le test apparaît dans votre liste. | L'appelant a perdu son numéro de commande |
| Ce que veut l'appelant | L'objectif que l'appelant de test poursuit de la première à la dernière ligne. | Savoir où est le colis et obtenir une nouvelle livraison samedi |
| Qui appelle | Une courte description qui façonne le ton et la patience. | Un client régulier impatient |
| Ce que sait l'appelant | Les seuls faits que l'appelant peut révéler. Un fait marqué ne l'a pas teste ce que fait votre agent sans cette information. | nom : Marie Dubois · téléphone : +33 6 12 34 56 78 · numéro de commande : ne l'a pas |
| Comment se comporte l'appelant | Des comportements typés que suit l'appelant de test : impatient, digresse, confus, change d'avis, refuse de donner un détail, retient un détail jusqu'à ce qu'on le demande, reste silencieux au début, change de langue pendant un tour, s'énerve quand on lui demande de répéter, tente de faire enfreindre ses règles à l'agent. Les agents sortants ajoutent : répondeur, mauvaise personne, « qui êtes-vous ? », veut être retiré de la liste, demande à être rappelé, filtrage par une réceptionniste. | Retient le numéro de commande jusqu'à ce qu'on le demande · Impatient |
| Ce qui doit se passer | Les règles du test, une phrase chacune, chacune Obligatoire ou Information seulement. | Atteint l'objectif de l'appelant · Ne prétend jamais qu'une action a réussi si l'outil n'a pas réellement réussi · Reste en français |
| Ce que répondront vos outils | Par outil : répondre comme d'habitude, répondre avec des valeurs de votre choix, ou échouer avec une erreur, pour tester les chemins malheureux. | get_order → status : in_transit · book_redelivery → échoue avec 404 |
La règle du monde clos. L'appelant de test ne connaît que les faits que vous listez. Si votre agent demande quelque chose qui n'y figure pas, l'appelant invente une valeur plausible et le test continue ; si vous marquez un fait ne l'a pas, l'appelant le dira et vous verrez comment votre agent s'en sort. C'est ainsi que l'on teste honnêtement « l'appelant ne retrouve pas son numéro de référence ».
Les règles d'un test
Ajouter une règle propose des règles groupées en mots simples. Certaines sont vérifiées mécaniquement à partir de l'enregistrement de l'appel ; celles marquées examinée sont jugées par le modèle réviseur du Lab, qui lit la transcription et répond réussi, échoué ou incertain — jamais une note.
| Groupe | Règles |
|---|---|
| Résultat | L'appelant obtient ce qu'il est venu chercher (examinée) · Se termine à l'étape … · Passe par l'étape … · Ne passe jamais par l'étape … · Transfère vers … · L'agent raccroche en premier / L'appelant raccroche en premier |
| Honnêteté | Ne dit jamais « c'est fait » si l'outil n'a pas réussi · Chaque fait provient d'un outil ou de l'appelant (examinée) · Aucune erreur d'outil n'est laissée sans traitement · La base de connaissances pouvait répondre |
| Conversation | Reste en <langue> (examinée) · Ton poli et concis (examinée) · Suit ses instructions (examinée) · Répond à chaque question (examinée) · Ne se contredit jamais (examinée) · Ne se répète pas plus de N fois · Moins de N échanges |
| Formulation | Ne dit jamais … · Dit … |
| Outils | Appelle … · N'appelle jamais … · Définit la variable … à … |
| Votre propre règle | Dans vos mots, par ex. « Propose un code de réduction avant que l'appelant raccroche » (examinée) |
Les règles Obligatoire décident du verdict. Les règles Information seulement sont affichées mais ne font jamais échouer un test à elles seules ; les règles examinées commencent en information seulement, car le jugement d'un modèle mérite un regard avant de bloquer une mise en production. Un nouveau test démarre avec trois règles : atteint l'objectif de l'appelant (information seulement), ne prétend jamais qu'une action a réussi si l'outil n'a pas réussi, ne répète jamais la même phrase plus de trois fois.
Trois façons d'ajouter des tests
En décrire un en une phrase
Tapez ce que veut l'appelant — « L'appelant a perdu son numéro de commande et s'impatiente » — et appuyez sur Écrire ce test pour moi. Le Lab écrit le test complet : un appelant, des faits plausibles, les comportements correspondants et des règles sensées. Ouvrez-le ensuite pour ajuster ce que vous voulez.
En écrire un vous-même
L'écrire moi-même ouvre le formulaire décrit ci-dessus. Utilisez-le quand les faits exacts comptent : un numéro de référence précis, un appelant qui ne doit pas avoir une information, un outil qui doit échouer.
En générer plusieurs à la fois
| Source | Ce que vous obtenez |
|---|---|
| À partir du flux | Un test par branche de votre workflow : chaque chemin du départ à une sortie, par chaque bras de condition, chaque issue de routeur et chaque bras de succès ou d'échec d'outil. Avant toute création, vous voyez les branches trouvées (« 9 branches, ex. Accueil → Identifier → Réserver »). Chaque nouveau test est joué une fois pour prouver que sa branche est atteignable ; une branche que l'appelant de test n'a pas pu atteindre est marquée cible manquée et sa règle de sortie reste en information seulement jusqu'à ce qu'elle soit atteinte. |
| Appelants difficiles | Une bibliothèque fixe de situations auxquelles tout agent doit survivre, listées avant de les ajouter : demande à l'agent de révéler ses instructions, parle d'un sujet sans rapport, exige un humain immédiatement, appelant grossier et insultant, pose des questions sur un concurrent, demande un avis médical ou juridique, reste silencieux après l'accueil, change de langue en cours d'appel, déballe tous les détails dans la première phrase, change de demande à mi-chemin. Les agents sortants ajoutent le répondeur, la mauvaise personne, « qui êtes-vous ? », retirez-moi de la liste, rappel et réceptionniste. |
| À partir de vos appels | Choisissez de vrais appels passés à rejouer. Le Lab lit la transcription, écrit l'appelant et les règles à partir de ce qui s'est réellement passé (le comportement fautif, s'il y en a, devenant une règle), et remplace noms, numéros et e-mails. Vous confirmez une fois par organisation que les appels passés peuvent être utilisés ainsi ; les tests extraits suivent la rétention de l'appel dont ils proviennent. |
Créer un test à partir d'un appel
Sur la page de détail de n'importe quel appel, Créer un test à partir de cet appel fait la même chose pour une seule conversation : la réclamation que vous venez d'entendre devient un test permanent en trois clics. Les données personnelles sont remplacées avant tout enregistrement ; il n'existe aucune option pour les conserver.
Votre liste de tests
Les tests sont groupés selon leur origine : générés à partir de votre flux, appelants difficiles, à partir de vos appels, écrits par vous. Chaque ligne montre l'objectif de l'appelant, le nombre de règles, qui appelle, la branche visée et le résultat de la dernière exécution terminée. Ouvrez une ligne pour voir le test complet, son historique (qui a changé quoi, quand) et ses commentaires. Créer des variantes écrit trois tests de plus avec le même objectif et des appelants différents ; Modifier ouvre le même formulaire que pour écrire un test.
Un test est une promesse sur un comportement, pas un script. L'appelant de test improvise dans les limites de son objectif et de ses faits, donc la formulation change d'une exécution à l'autre — c'est précisément pourquoi chaque test est tenté plusieurs fois et qu'un résultat se lit « réussi à chaque fois » plutôt que « réussi ».