Pensez-y : ce n’est pas un problème auquel sont confrontés les RVI à clavier (officiellement connus sous le nom de DTMF) ou les applications Web qui se basent sur des clics et la navigation avec une souris. Ces dernières ne sont jamais ambiguës. Un signal sonore ‘2’ ne peut pas être confondu avec un ‘1’ ou un ‘3’. Au-delà d’une erreur de la part de l’utilisateur, un clic de souris sur un bouton pour « passer à la caisse » sur un site d’achat en ligne ne peut pas être interprété comme une recherche pour un autre article. Et même si c’est l’utilisateur qui fait une erreur, il y a toujours le bouton « retour ».

Avec la parole, c’est différent. Les êtres humains ont parfois tendance à mal comprendre ce qu’on leur dit et, malgré toutes les améliorations apportées quotidiennement à la précision de la reconnaissance vocale automatisée, les logiciels peuvent eux aussi se tromper, de temps en temps.

Que peut donc faire le pauvre créateur d’applications ?

Il y a des outils à notre disposition

Tout d’abord, il faut savoir que les résultats du traitement de la voix sont généralement accompagnés d’un score de confiance qui indique à l’application à quel point le moteur de reconnaissance est certain d’avoir fait une bonne correspondance des mots prononcés. Si le pointage est suffisamment élevé, l’application peut considérer que les résultats sont valides et passer à l’exécution du choix de l’utilisateur. Si le niveau de confiance est trop faible, l’application doit trouver un autre moyen de procéder – et faire en sorte que cela ne suscite pas de réaction négative de la part de l’utilisateur.

Mais il y a d’autres possibilités. Dans un premier temps, les résultats de la reconnaissance peuvent se situer dans une zone grise : un niveau de confiance ni trop élevé, ni trop faible non plus. Il est plutôt possible que le moteur de reconnaissance se trouve avec une hypothèse qui nécessite une confirmation. Ceci doit également être traité délicatement.

Enfin, il se peut que l’utilisateur n’ait pas répondu du tout, ou qu’il l’ait fait de telle manière que l’application ne l’ait tout simplement pas compris.

Ainsi, si on laisse de côté un résultat clair et net de confiance élevée, il nous reste trois scénarios à considérer : une confiance moyenne, une confiance faible ou aucun résultat du tout. Pour chacune d’entre elles, l’application se retrouve dans un scénario de récupération, ce qui signifie qu’il faut de nouveau faire appel à l’utilisateur, chose que personne n’apprécie. Toutefois, chacun de ces scénarios doit être traité en employant une approche subtilement différente. En plus de développer une demande adaptée à chaque besoin pour inviter l’utilisateur à réessayer, le créateur d’applications doit également se demander combien de fois il pourra le faire avant que l’utilisateur ne se lasse.

Compliqué, certes, mais voici quelques éléments simples à garder à l’esprit pour orienter la démarche.

Élaborer des stratégies claires dès le départ

Tout d’abord, évitez autant que possible de poser plusieurs fois la même question en rendant votre demande initiale aussi claire que possible. Par exemple, si vous demandez le numéro de téléphone à un utilisateur, indiquez le nombre de chiffres que l’application s’attend à saisir. Même s’il y a plus de 20 ans que l’Amérique du Nord a commencé à normaliser les numéros de téléphone à 10 chiffres, ça vaut toujours la peine de le préciser. Par conséquent, un message du type :

« Veuillez dire ou entrer les 10 chiffres de votre numéro de téléphone. » est préférable à « Veuillez entrer votre numéro de téléphone. »

La différence est assez subtile, mais elle permet de clarifier les choses, ce que les gens apprécient et dont ils ont besoin. Dois-je inclure mon code régional ? Oui. Dois-je inclure le numéro de poste ? Non. C’est une chose simple à faire, mais très utile. Un autre exemple pour les utilisateurs américains est celui des codes postaux du service des postes américaines, qui apparaissent sous forme de 5 ou 9 chiffres. Si une application doit recueillir un code postal, indiquez d’emblée à l’utilisateur celui qu’il doit utiliser, par exemple : « Veuillez me fournir votre code postal à 5 chiffres ».

Combien de fois devez-vous demander à un utilisateur de refaire une tentative ?

En règle générale, il est préférable de demander une deuxième fois que d’abandonner, ce qui signifie qu’il est normal de faire au moins un essai. D’un autre côté, les gens commencent à en avoir assez si l’application ne fonctionne pas de manière récurrente. Alors, même si une deuxième demande est une bonne idée, en faire plus que deux entraînent généralement de la frustration. En d’autres termes, avoir moins d’une demande est rare et en avoir plus que deux est extrêmement rare.

Alors, comment reformuler la demande ? Si tout va bien, la demande initiale a indiqué aussi clairement que possible les renseignements que l’application tente d’obtenir de la part de l’utilisateur. Si ce dernier ne les a pas fournies, il est possible qu’il n’ait pas compris, donc le nouveau message peut contenir des instructions supplémentaires. Par exemple, l’invite initiale d’une compagnie d’assurance pour connaître le numéro d’une police pourrait être la suivante : « Veuillez indiquer votre numéro de police à 9 chiffres ». Si cela ne suscite qu’un grognement confus chez l’utilisateur et que le résultat est d’un niveau de confiance très faible, une première demande supplémentaire raisonnable accompagnée d’instructions pourrait être « Désolé, je n’ai pas compris. Veuillez me préciser votre numéro de police à 9 chiffres. Celle-ci figure dans le coin supérieur droit de votre contrat. »

Si cela ne résout pas le problème, ajoutez un exemple lors de la deuxième tentative : « Désolé, mais je n’ai toujours pas compris. Veuillez me fournir votre numéro de police à 9 chiffres, comme suit : un-deux-trois, quatre-cinq-six, sept-huit-neuf. Encore une fois, il se trouve dans le coin supérieur droit de votre contrat. »

Notez que toutes les demandes de nouvelle tentative doivent non seulement ajouter de plus en plus d’exemples et de précisions, mais aussi s’excuser brièvement afin de rejeter la faute sur l’application, et non sur l’utilisateur.

D’autres options peuvent consister à proposer à l’utilisateur de se rendre dans une autre pièce plus calme, à l’écart du bruit de fond. Même si l’utilisateur se trouve déjà dans une région peu bruyante, cela lui indique que la clarté est importante et l’encourage à parler plus clairement. Cela peut également l’amener à baisser le son de leur télévision ou à demander aux gens de son entourage de se taire.

Voici un exemple de comment gérer un scénario où le niveau de confiance est faible.

Qu’est-ce qui arrive lorsqu’un utilisateur ne répond pas du tout ? La stratégie de progression des instructions à chaque nouvelle tentative reste valable, mais il est important de faire la distinction entre le fait de ne pas avoir entendu une réponse et celui de ne pas l’avoir saisie. Même si un utilisateur répond par quelque chose que l’application ne comprend pas, il a au moins donné une réponse. Lorsque l’application n’entend rien et cesse de fonctionner, la différence doit être signalée. Au lieu de s’excuser en disant « Je n’ai pas compris », l’invite devrait plutôt commencer par « Je ne vous ai pas entendu », ou quelque chose de ce genre. Cela indique à l’utilisateur que l’application est à l’écoute et qu’il a besoin de fournir des informations quelconques.

Enfin, les confirmations. Lorsque la réponse d’un utilisateur est reconnue avec un niveau de confiance moyen, l’application peut répondre à l’utilisateur avec un message comme « Je pense que vous avez dit… » suivi de ce qui a été compris, et elle peut ensuite fermer la demande de la nouvelle tentative avec une question explicite oui/non telle que « Est-ce correct ? ». Si l’hypothèse est correcte, l’utilisateur est encouragé à continuer en sachant que l’application est non seulement assez intelligente pour le comprendre, mais aussi assez habile pour ne pas se lancer dans une mauvaise direction quand elle n’est pas certaine. Si l’hypothèse est incorrecte, là encore, l’utilisateur peut être rassuré par le fait que l’application ne s’est pas déchaîné et qu’il a la possibilité de corriger son erreur en réessayant.

L’être humain à l’autre bout de la ligne

Dans un monde de génie high-tech, les stratégies de relance de demande ne sont pas tant guidées par des mathématiques complexes et des algorithmes sophistiqués, mais plutôt par une compréhension de la nature humaine. Les gens vont collaborer avec une machine qui leur pose des questions s’ils se sentent compris, s’ils ont l’impression que les interactions mènent à quelque chose d’utile et que l’application les traite avec respect.

Sinon, ils appuieront probablement sur le ‘0’, déterminés à obtenir un agent, car personne n’aime se sentir manipulé, surtout pas par une machine. Pire encore, ils raccrocheront et appelleront votre concurrent !

Enfin, gardez à l’esprit qu’il s’agit que de lignes directrices, et non des règles strictes. Les concepteurs devront donc réfléchir en profondeur à la manière de créer une persona qui reflète l’entreprise (nous reviendrons sur les personas dans les mois à venir) et appliquer ces stratégies avec soin et cohérence, ainsi que avec la possibilité de contourner les règles, le cas échéant. Il y aura toujours des exceptions, mais les messages d’invite à réessayer, s’ils sont appliqués de manière réfléchie, peuvent augmenter considérablement le succès de l’utilisateur avec les applications vocales, qui signifie une meilleure expérience pour le client, moins de temps passé avec les agents – et des clients qui apprécient et restent fidèles à votre marque.