Au cours des dernières années, les solutions d’agents virtuels ont bénéficié d’avancées technologiques majeures dans le domaine du Traitement Automatique du Langage Naturel (TALN) et de l’Intelligence Artificielle (IA).

Cependant, la complexité et la quantité d’efforts requis pour tirer partie des plateformes conversationnelles basées sur l’IA, tels que Lex d’Amazon ou Dialogflow CX de Google, sont des freins qui découragent beaucoup d’entreprises de considérer les agents virtuels comme un investissement potentiellement rentable.

En mutualisant les volumes d’appels de plusieurs clients, les fournisseurs de solution d’agents virtuels gérée sont en mesure d‘offrir des agents virtuels à la demande, dans des délais beaucoup plus courts et à un coût bien plus bas que si chaque client devait implémenter  sa propre plateforme conversationnelle.

De nombreuses entreprises ont développé leurs propres critères de sélection de main-d’œuvre externalisée, mais ces critères ne sont pas entièrement applicables au choix d’une solution d’agents virtuels.

Quand il s’agit de sélectionner un fournisseur de solution d’agents virtuels gérée, le choix des entreprises devrait s’appuyer principalement sur ces 4 critères:

• L’intégration et la sécurité 
• L’expérience du prestataire avec le canal voix et en téléphonie
• L’expérience du prestataire en conception d’interface conversationnelle
• L’amélioration continue de la solution

Explorons en détails chacun de ces critères afin d’établir ce qu’un client devrait être en droit d’attendre de la part du fournisseur.

L’intégration et la sécurité

Du point de vue de l’intégration, une solution d’agents virtuels gérée est similaire à une externalisation des appels ; c’est-à-dire qu’il faut mettre en place un moyen de transférer les appels à un autre centre de contact tout en garantissant l’accès aux systèmes requis selon les cas d’utilisations choisis.

Le diagramme suivant illustre l’architecture à haut niveau d’une solution d’agents virtuels gérée:

Il est à espérer que le fournisseur choisi sera capable de s’intégrer à vos systèmes existants sans vous imposer d’en mettre certains, tels que votre solution de centre de contacts, à jour. Il vous incombe de vérifier les implications liées à l’ouverture de certains points d’accès à un fournisseur.

Dans la mesure où vos données clients ainsi que leur interactions vocales seront partagées avec ce fournisseur, il sera primordial de discuter des aspects de sécurité de l’intégration. Vous devrez vous assurer que le fournisseur est capable de faire transiter et d’héberger vos données clients à l’intérieur des zones géographiques que vous desservez. Par exemple, il est probable que vous ne souhaitiez pas que vos appels transitent à travers des infrastructures basées aux États-Unis si vous faites affaires au Canada.  De plus, il sera nécessaire d’évaluer le niveau de sécurité du fournisseur. Des audits de sécurité et des certifications reconnues (ex. SOC 2, ISO 27001) peuvent faciliter cette évaluation et confirmer que le niveau de sécurité du fournisseur répond à vos exigences.

L’expérience du prestataire avec le canal voix et en téléphonie

Fournir une expérience conversationnelle de premier rang sur le canal téléphonique requiert plus que l’ajout d’outils de transcription et de synthèse de la parole à un chatbot. Les conversations vocales se font en temps réel, de manière synchrone. Il y a plusieurs facteurs en jeu: garder le temps de réponse à l’échelle des milli-seconds pour réduire les silences et éviter l’inconfort, détecter précisément quand l’appelant arrête de parler ou interrompt l’agent virtuel, s’adapter à un signal audio de faible qualité ou au bruit, permettre une reconnaissance de la parole précise même avec des accents forts, des appelants hésitants ou qui changent d’avis, et enfin être capable de générer des réponses qui semblent naturelles.

Lors du choix d’un fournisseur de solution d’agents virtuels gérée, vous devrez vous assurer qu’il dispose d’une expérience significative dans la gestion des enjeux liés aux communications téléphoniques.

L’expérience du prestataire en conception d’interface conversationnelle

Comme mentionné précédemment à propos des faibles taux de satisfaction pour certaines applications de réponses vocales interactives (RVI), une approche « taille unique” n’offre généralement pas une bonne expérience client. La personnalisation devrait être partie intégrante de votre stratégie de conception des dialogues. Par exemple, l’intégration de vos agents virtuels avec votre système de gestion de la relation clients peut permettre de s’appuyer sur vos données clients pour mieux contextualiser leurs besoins et comprendre leurs raisons d’appels. Lors des échanges avec le fournisseur, il sera important de vous assurer qu’il ne vous propose pas une solution à l’emporte-pièce ne permettant aucune personnalisation de l’expérience conversationnelle.

L’attention portée à l’expérience client devrait viser à réduire les frictions avec d’autres interactions que le client a eu avec vous. Malheureusement, les RVI mal conçues peuvent être trop contraignantes et imposer une structure conversationnelle trop rigide que les clients n’apprécient pas. Sans vouloir faire croire à vos clients qu’ils conversent avec un agent humain, votre objectif devrait être de reproduire autant que possible l’expérience qu’ils auraient avec un agent humain. Le propre des conversations d’humain à humain est de permettre aux gens de s’exprimer naturellement tout en identifiant les informations pertinentes au gré de la conversation.

Vous devrez aussi prendre en compte les restrictions liées au canal téléphonique lors de la conception des dialogues. Bien que de disposer d’une solution omnicanal est tout à fait souhaitable, les entreprises doivent comprendre les différences inhérentes à chaque canal. Prenons, par exemple, le cas de la prise de rendez-vous par le biais d’un agent virtuel. Si un client veut prendre un rendez-vous un jour où il y a beaucoup de disponibilités, vous pourriez présenter une liste visuelle de tous les créneaux horaires disponibles dans une interface de chat afin que le client puisse facilement en sélectionner un. Cependant, au téléphone, cette stratégie est vouée à l’échec car la liste des disponibilités est tout simplement trop longue à énumérer de vive voix. Une interface utilisateur vocale vient avec son lot de contraintes spécifiques que vous devrez garder à l’esprit lors de la phase de conception. Méfiez-vous des fournisseurs qui vous assurent que leurs agents virtuels peuvent fonctionner sur n’importe quel canal.

L’amélioration continue de la solution

Les gens sont imprévisibles. Il est important d’anticiper que certaines personnes ne vont pas interagir avec l’agent virtuel de la manière prévue. De plus, les besoins de vos clients évoluent avec le temps. Tout comme les agents humains, les agents virtuels doivent être supervisés et évalués d’une manière ou d’une autre tout en recevant l’entraînement nécessaire.

Dès lors, il est vital de comprendre qu’une solution d’agent virtuel ne se limite pas à son implémentation et à son lancement. La solution d’agent virtuel requiert de la surveillance, du support, de la maintenance et de l’optimisation pour s’adapter à vos clients. Veillez à ce que votre fournisseur s’attache à améliorer constamment la solution.

Questionnez votre fournisseur sur la façon dont il propose de tirer partie de vos données d’utilisation. Comme les gens s’expriment de manière naturelle, vous pourriez en profiter pour identifier comment mieux les servir.  Cela peut vous aider également à identifier d’autres cas d’utilisation qui pourraient être implémentés.

Les avantages d’une solution gérée

S’appuyer sur l’expertise d’un partenaire-fournisseur d’agents virtuels a plusieurs avantages.

L’avantage principal réside dans la réduction du temps nécessaire pour arriver à générer de la valeur avec la solution. Une fournisseur de solution gérée sera en mesure de vous offrir des connecteurs pour vos systèmes, aura conçu des agents conversationnel ou des dialogues similaires, aura optimisé le traitement de la parole… Cela peut réduire le temps de mise en place d’une projet d’agent virtuel de quelques mois à quelques semaines.

Définir, concevoir, implémenter et assurer la maintenance d’agents virtuels nécessite une équipe multidisciplinaire et une bonne compréhension des dernières technologies d’IA.

Cette expertise peut lourdement grever le coût total de la solution ainsi que les investissements requis. Une solution d’agents virtuels complètement gérée par un fournisseur permet de réduire des investissements et de mieux prédire les coûts.

Le déploiement d’un assistant virtuel vocal qui répondra aux appels des clients peut être risqué pour les entreprises. Selon une enquête Rasa, 41% des personnes interrogées ont déclaré qu’une expérience limitée dans la création d’assistants virtuels était un obstacle à l’adoption de l’IA conversationnelle et seulement 18% des personnes interrogées utilisant des assistants vocaux sont en production avec elle. Un fournisseur d’agents virtuels entièrement gérés peut tirer parti de son expérience pour assurer le déploiement réussi des solutions en production.

Pour résumer

L’automatisation des appels via une solution d’agent virtuel entièrement gérée peut aider les centres de contact à servir leurs clients pour des tâches simples et répétitives afin de permettre à leurs agents humains de se concentrer sur les appels à valeur ajoutée. Cela implique un partenariat avec un fournisseur et les entreprises doivent s’assurer que les critères clés seront remplis par leur fournisseur.

Nu Echo a plus de 20 ans d’expérience dans la création d’expériences conversationnelles qui améliorent l’efficacité opérationnelle avec une expérience client exceptionnelle. Si vous êtes intéressé par une solution d’agent virtuel géré, contactez-nous dès aujourd’hui.

The post L’automatisation des appels n’a pas besoin d’être risquée, longue et coûteuse. first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post L’automatisation des appels n’a pas besoin d’être risquée, longue et coûteuse. appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

Imaginez que vous avez réservé des billets pour un événement à venir qui vous passionne vraiment. Quelques semaines plus tard, vous recevez un e-mail vous informant que votre événement a été annulé. Vous essayez de comprendre vos options : puis-je obtenir un remboursement, l’événement est-il reporté, quelle place aurai-je si je reporte… Vous naviguez sur le site Web et ne trouvez pas de réponses à vos questions. Vous décidez donc d’appeler le service client de l’événement et vous devez attendre près d’une heure avant de pouvoir enfin parler à un agent.

Cela vous semble familier? Ces mauvaises expériences sont principalement dues à 4 grandes tendances qui affectent actuellement les centres de contact.

⚠️Volumes élevés sur le canal téléphonique

Selon CFI group, 76% des personnes souhaitant contacter un service client choisissent de téléphoner.

⚠️Volume d’appels variables

Selon Talkdesk, 50 % des professionnels de l’expérience client du commerce de détail déclarent que le principal défi auquel ils sont confrontés est la grande variabilité de la quantité d’assistance client nécessaire pendant les vacances, les pics saisonniers, les baisses hors saison et autres. Les gens s’adaptent également à de nouvelles situations telles que le travail à domicile, les interactions virtuelles et l’évolution des règles de voyage.

⚠️ Une complexité d’appels croissante

Selon le Harvard Business Review qui a étudié l’effet de la pandémie de COVID sur le service client, le pourcentage d’appels classés comme « difficiles » a plus que doublé, les temps d’attente ont augmenté de 34 % et les escalades de 68 %.

⚠️ Une augmentation de la complexité et des coûts de main d’oeuvre dans les centres de contact

Selon CGS, 37 % des entreprises ne sont pas confiantes ou peu confiantes dans leur capacité à maintenir les niveaux de service et à prévenir les effets négatifs sur les niveaux de service de vagues supplémentaires de COVID.

🌀Un cocktail explosif pour les centres de contact

La combinaison de ces tendances exerce une pression énorme sur les centres de contact. La gestion de la main-d’œuvre d’un centre de contact est devenue de plus en plus difficile avec des volumes d’appels encore plus imprévisibles combinés à des difficultés d’embauche et de dotation en personnel.

Ne pas pouvoir parler avec une entreprise peut entraîner une baisse de la satisfaction et de l’engagement des clients, ce qui peut causer une perte de revenus et une baisse de la valeur de la marque.

Comment les centres de contact peuvent-ils suivre le rythme? Espérons que les entreprises pourront utiliser différentes stratégies pour atténuer l’impact de ces défis. Afin de choisir les bonnes stratégies, il est important de considérer la complexité ainsi que le volume de chaque cas d’utilisation ou catégorie d’appels. L’automatisation des appels devient un élément clé pour les centres de contact afin de permettre aux agents virtuels de gérer les appels simples et transactionnels et de laisser les appels plus complexes et à valeur ajoutée aux agents humains.

Découvrez comment les centres de contact peuvent s’associer à des fournisseurs de solutions pour automatiser les appels avec des investissements réduits, des coûts plus prévisibles et un délai de rentabilité réduit dans un article qui sera publié prochainement  L’automatisation des appels n’a pas besoin d’être risquée, longue et coûteuse.

The post Mesdames et messieurs, nous traversons une zone de turbulence. Veuillez patienter pendant que nous essayons de localiser un agent disponible. first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Mesdames et messieurs, nous traversons une zone de turbulence. Veuillez patienter pendant que nous essayons de localiser un agent disponible. appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

Even in its core conversational AI business, Nuance is fast transforming itself from a software company with a very large focus on professional services to a product and platform company. This was evident at the 2019 Partner eXperience Summit, but it was even more so at this year’s event.

This change was of course necessary and, I might add, a bit overdue. Long the dominant vendor of enterprise speech technology solutions, Nuance is now being challenged by companies – Google, Amazon, Microsoft, and IBM among others – that offer easy to use conversational AI platforms with state-of-the-art technologies. With these platforms, the claim is that anybody can now develop sophisticated conversational AI solutions; that speech recognition (ASR) and natural language understanding (NLU) work “out-of-the-box” without any need for speech scientists; and that, in fact, you don’t even need developers to build solutions. This is the “do-it-yourself” (DIY) message and it is a compelling one.

Of course, that message is highly misleading. Yes, to some extent, the technology now works “out-of-the-box” in the sense that it is possible to get a simple conversational demo bot up-and-running quickly. With speech-to-text (STT) engines, there is no need to write speech recognition grammars and NLU engines can be trained with a few training phrases per intent. But that’s only good for a demo. Building an effective, enterprise-grade conversational AI system is hard work, no matter what the platform is (more on that in a future blog post).

What is true, though, is that enterprises really are looking for DIY tools. And they are increasingly demanding cloud-native solutions. And, above all, they want flexibility. And Nuance has heard that message loud and clear. They now understand that it’s no longer sufficient to have best-in-class technology and a good professional services organization. Customers want to have flexible development and deployment models.

The most recent big steps that Nuance has taken in that direction are:

• Conversational AI APIs (launched November 2019);
• The Nuance GateKeeper cloud based security and biometrics suite (launched October 2019);
• Nuance Mix: DIY Tooling for partners and end users (general availability planned for end of March)

The introduction of Nuance Mix, in particular, is a big change for a company that is used to directly delivering most of its conversational AI solutions through its professional services organization, using closely guarded development tools. But what we’ve seen so far of Mix is promising, with a slick, contemporary user interface. From a company that has years of experience building and deploying compelling conversational AI solutions, this is quite encouraging.

Nuance is facing powerful new competitors, but it has many advantages. Its technology is top-notch, it has a very large installed base, it offers the most flexible deployment models (premise or cloud), its technology is integrated with most contact center platforms, and it understands better than anybody what it takes to deliver conversational experiences that work not just in demos, but in the real world. Nuance also offers the most extensive capabilities to adapt and optimize the technology for a specific domain and a specific dialog state, which is often what makes the difference between a good demo and an enterprise-grade solution.

Another Nuance differentiator – which they position as a key element of their value proposition – is its strong professional services organization. But that could also turn out to be its Achilles’ heel, because customers no longer want to be dependent on the vendor’s PS; they want to know that there is a large pool of people that are skilled on the technology and have all the tools necessary. It will be a challenge to change a company that is culturally used to delivering all the big projects into one that enables its partners and customers to do it themselves.

In conclusion, Nuance is clearly going in the right direction and making all the right moves, but its plan is ambitious, so execution will be key. Perhaps the biggest challenge will be to implement the culture changes that are required in order to successfully implement this transformation.

We’ve been in this market for close to 20 years and these are by far the most interesting times we’ve seen. We’re expecting quite a ride in the next few years.

The post Retour sur le Nuance Partner eXperience Summit: Une transformation accélérée dans un marché fluide (Article en Anglais) first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Retour sur le Nuance Partner eXperience Summit: Une transformation accélérée dans un marché fluide (Article en Anglais) appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

Conséquemment, le canal téléphonique traite désormais des problèmes complexes, et ce, dans une proportion plus importante qu’auparavant. Puisqu’il est le canal ultime pour ces parcours clients problématiques ou complexes, il devient donc stratégique pour l’organisation d’y prêter une attention particulière. Personne aujourd’hui ne saurait douter de la pertinence d’offrir à sa clientèle un service téléphonique simple et efficace afin de préserver la loyauté de ses clients.

Le mot « conversationnel » sur toutes les lèvres

Il y a maintenant quelques années que le terme « conversationnel » a fait son apparition dans le vocabulaire du domaine de l’expérience client. Pour en savoir davantage sur ce concept, il vous est possible de consulter l’article « Whaddya mean, conversational IVR? » (disponible en anglais seulement). Essentiellement, les approches dites conversationnelles permettent aux utilisateurs de s’exprimer librement, en énonçant eux-mêmes le problème, tout en permettant une structure de dialogue peu contrainte. Le rôle du système dans la conversation est de demander les informations manquantes tout en s’adaptant aux interruptions et aux changements de sujets.

Appliquées aux systèmes de réponse vocale interactive (RVI), les interfaces conversationnelles révolutionnent l’expérience client en permettant à l’utilisateur d’énoncer d’emblée sa requête verbalement plutôt que de se promener à travers un dédale d’options de menu. Le client n’a plus à s’adapter. À l’inverse c’est le système qui doit désormais le faire.

De coup de fil en aiguille

Pour ceux qui n’ont pas encore déployé de solutions conversationnelles sur le canal téléphonique, l’élaboration d’une feuille de route pour cette transition est cruciale. La stratégie doit considérer à la fois les bénéfices d’affaires potentiels, les risques technologiques et les impacts organisationnels. Alors, comment y parvenir?

Nous avons besoin d’un plan en plusieurs étapes qui permette à l’organisation d’absorber les transformations progressivement tout en maximisant les bénéfices. Elle doit pouvoir apprendre et s’ajuster. En effet, le développement et le déploiement de systèmes conversationnels nous demandent de changer notre façon de fournir les spécifications, d’effectuer la conception, de réaliser et de tester la solution. De plus, le traitement du langage naturel demande une grande quantité de données provenant des utilisateurs, c’est-à-dire des enregistrements d’appels et leurs transcriptions. C’est un élément nouveau mais essentiel et on doit en tenir compte dans la planification des projets.

Premiers mots: aiguillage des appels en langage naturel

Comme première étape de la transition vers la RVI conversationnelle, il est très intéressant de considérer une solution d’aiguillage des appels en langage naturel (abrégé ici en AALN pour le reste de cet article). Le but de cette solution est de permettre à un client d’exprimer verbalement et en ses propres mots la raison de son appel. Le système analyse et interprète la requête formulée par le client et achemine l’appel à la bonne destination, c’est-à-dire, soit vers les agents appropriés ou vers un module de libre-service. Ceci remplace les menus, du moins comme interface d’avant-plan, les menus demeurant utiles comme palliatifs. Voici une illustration d’un scénario dans lequel un client interagit avec une solution d’AALN.

Quel genre d’efforts est requis pour le déploiement d’une solution d’AALN? Premièrement, on doit procéder à la collecte de données. D’une part, la collecte de données vocales effectuée auprès des clients permet de comprendre comment s’expriment les clients lorsqu’ils communiquent avec l’organisation et d’autre part, l’inventaire des produits et services, la terminologie utilisée à l’interne et à l’externe ainsi que la structure du centre de contact (groupes d’agents, compétences, etc.) nous servent à comprendre le domaine d’affaire.

Ensuite, ces données seront analysées afin de définir le catalogue d’intentions, c’est-à-dire toutes les catégories de raisons d’appel pouvant être traitées par le système. Pour les intentions plus vagues qui nécessitent une caractérisation plus précise, on devra définir la stratégie de désambiguïsation, laquelle consiste à identifier quelles questions devront être posées au client afin de préciser son intention. Finalement, pour chaque intention non vague, on devra déterminer quelle sera la bonne destination, c’est-à-dire le groupe d’agents ou le libre-service apte à répondre à la requête du client.

À partir des données recueillies lors de la collecte de données, on pourra entraîner et optimiser les engins de reconnaissance de la parole et de traitement du langage naturel afin qu’ils puissent adéquatement reconnaître les phrases prononcées par les utilisateurs et catégoriser l’intention de l’appel correctement.

L’application RVI pour l’AALN est simple. C’est en partie pourquoi il s’agit d’une première étape idéale dans la transition vers la RVI conversationnelle. Dans le flux d’une telle application, on pose initialement une question, à la suite de quoi le système peut demander une confirmation selon le niveau de confiance du module de traitement du langage naturel. Ensuite, un dialogue de désambiguïsation sera peut-être nécessaire si la requête est considérée vague. Finalement, selon l’intention détectée dans la requête, l’appel sera acheminé au bon agent.

Il y a donc, dans cette application, très peu d’états. Ceci simplifie grandement sa conception, sa réalisation ainsi que les tests.

Une fois l’application complétée, on procédera à une phase de pilote. Typiquement, lors de ce pilote, la nouvelle solution d’AALN sera exposée à une fraction de la clientèle. Ceci permettra non seulement de mesurer les performances de l’application mais aussi de l’améliorer. Les phrases utilisées par les clients seront récoltées et elles viendront enrichir le modèle de traitement du langage naturel. Lors du pilote, il serait aussi judicieux d’en profiter pour sonder les utilisateurs sur leur nouvelle expérience. Une fois les ajustements apportés, l’application pourra être rendue disponible à grande échelle.

Suite à la mise en production, il est important de périodiquement récupérer les données afin d’améliorer le modèle de traitement du langage naturel. Ces optimisations post déploiement permettent à l’application de s’adapter à l’évolution des requêtes de la clientèle.

Voici une vue simplifiée du processus de développement:

Récolter les fruits

La réduction du nombre d’erreurs de transfert est le bénéfice principal d’une solution d’AALN. Ceci aura donc pour effet de libérer les agents. De cette façon, on améliore l’efficacité opérationnelle du centre de contact client. Par le fait même, les utilisateurs éprouveront moins de frustration, ce qui contribuera à améliorer non seulement l’expérience client mais aussi l’expérience agent.

L’efficacité et la convivialité de l’interface conversationnelle et le fait que le client puisse s’exprimer naturellement, en ses propres mots, sont d’autres facteurs contribuant à améliorer l’expérience client. Comme le centre de contact client demeure le lien entre l’organisation et son client, meilleure est l’expérience client, meilleure sera la fidélisation.

La nouvelle solution permettra de comprendre les raisons réelles des appels. La RVI traditionnelle ne reflète que les choix des clients parmi les raisons d’appels présumées par l’organisation. À l’inverse, les énoncés en langage naturel ne subissent aucun filtre et nous permettent d’identifier des problèmes ou questions récurrents qui pourront être traités en libre-service (téléphonique ou autre). Avoir en main ces statistiques nous permet aussi de concentrer nos efforts d’optimiser le design pour les requêtes les plus fréquentes.

L’AALN offre aussi la possibilité de regrouper plusieurs numéros de téléphone en un seul numéro. Il n’est plus nécessaire de séparer les services afin de réduire la complexité et la taille des menus. Tout est disponible dès la première interaction. Avec un numéro unique, on évite la frustration des clients qui ont dû chercher le bon numéro à utiliser ou qui n’ont pas utilisé la bonne porte d’entrée.

L’expérience acquise

L’AALN permet à l’organisation d’acquérir de l’expérience dans plusieurs aspects de la RVI conversationnelle. Par exemple, lorsqu’on travaille avec la technologie de la reconnaissance de la parole en langage naturel, il n’est pas possible d’avoir des spécifications techniques déterministes, ce à quoi on est habitué dans le développement de solutions de RVI traditionnelles. Comme le langage est un phénomène humain, il impossible d’anticiper toutes les formulations possibles. C’est pourquoi on a recours à des systèmes d’intelligence artificielle, lesquels apprennent avec les données qui leur ont été fournies. Il leur faut donc travailler avec la notion d’incertitude. Le système est composé de deux étapes, la reconnaissance de la parole et le traitement du langage naturel, chacun ajoutant un degré d’incertitude au résultat.

Donc, si auparavant, il suffisait de dire…

“Lorsque l’utilisateur appuie sur la touche Y, l’appel est transféré au département X”

…nous devons maintenant décrire le comportement de cette façon :

“Lorsque le système reconnaît l’intention Y, l’appel est transféré au département X”

La façon dont l’intention est reconnue ne peut être décrite formellement. Le tout doit être considéré comme une boîte noire. Ceci a un impact non seulement sur le plan de la spécification, mais aussi des tests. On doit traiter séparément les aspects suivants :

• • la performance de la détection des intentions, c’est à dire les performances combinées de la reconnaissance de la parole et du traitement du langage naturel
  • la conformité du comportement de l’application suite à la reconnaissance d’une intention, c’est-à-dire qu’après avoir reconnu une intention donnée, l’application devra se comporter d’une manière prédéterminée

Ce principe demeurera pertinent tout au long de l’évolution vers une solution conversationnelle complète.

Mais ceci n’est qu’un exemple parmi plusieurs éléments de pratique qui requièrent une attention particulière. On devra aussi se préoccuper des rapports d’évaluation de performance de la solution, de la collecte et de la conservation de données audio, de la conduite de pilotes, des ajustements post déploiement et du processus d’amélioration en continu.

Et ensuite?

Une fois l’AALN en place, il existe plusieurs avenues pour approfondir l’approche conversationnelle. On pourrait, par exemple, ajouter un module pour l’interrogation d’une base de renseignements. Cette solution permet de répondre directement à une question posée par l’utilisateur au lieu d’acheminer l’appel à un agent qui devrait lui-même faire la recherche afin de répondre à l’utilisateur.

Il est aussi possible d’offrir des modules de libre-service transactionnels à même le canal téléphonique. On pourra transformer les libres-services existants et en introduire de nouveaux. Afin d’identifier les libres-services les plus pertinents à mettre en place, on pourra se servir de l’analyse des données fournies par la solution d’aiguillage des appels. Ces libres-services permettront aux utilisateurs de formuler des demandes complexes, et ce, dès l’accueil. Contrairement à l’aiguillage des appels, qui possède une structure de dialogue simple, les libres-services conversationnels exigent un moteur de dialogue sophistiqué qui prend en charge les dialogues en mode initiative mixte et qui permet de gérer correctement les situations particulières du dialogue, telles que les digressions, les changements d’idée et les corrections. Vous pouvez consulter cet article sur les corrections: partie 1 et partie 2 (en anglais seulement).

Comme certains libres-services ont besoin de connaître l’identité de l’appelant afin d’effectuer des opérations liées au compte de ce dernier, on devra mettre en place un module d’identification et d’authentification. Et afin de préserver le caractère naturel des interfaces conversationnelles, il serait très judicieux d’opter pour une solution d’authentification biométrique. Permettant d’authentifier un client par le simple son de sa voix, cette méthode est conviviale, rapide et efficace.

Le fait d’avoir déployé une solution d’AALN permet à l’organisation d’affronter en toute confiance les nouveaux défis. L’expérience qu’elle aura acquise l’aidera à anticiper les enjeux techniques et lui permettra d’identifier comment les interfaces conversationnelles peuvent apporter de la valeur à l’organisation.

The post L’aiguillage des appels en langage naturel, votre porte d’entrée vers l’automatisation conversationnelle first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post L’aiguillage des appels en langage naturel, votre porte d’entrée vers l’automatisation conversationnelle appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

In an attempt to, if not eliminate, at least reduce some of that confusion, I’ll propose some broad definitions for these terms.

A chatbot is an automated system with which users interact through a “chat-like” interface. This includes messaging channels such as Messenger, WhatsApp, Slack… but it also includes SMS, iMessage, as well as other chat-like interfaces such as web chats, chat widgets in mobile applications, etc. Although chatbot interactions should primarily be done through text input and output, they in practice increasingly incorporate rich media (depending on what the channel supports) such as buttons, images, carousels, webviews, etc. In reality, many chatbots have little or no support for text input, relying primarily on buttons for user input. A chatbot is not necessarily conversational (see here for an explanation of what we mean by conversational) and in fact most chatbots are highly directed, menu driven “dialogs”.

A voicebot is a chatbot with which users can interact vocally. This assumes that the chatbot behind the voicebot can handle natural language input and it requires a capability to convert voice input into text (or directly into intents), as well as text output into voice. Example voicebots include any bots accessible through a voice channel, which include the now ubiquitous smart home speakers, but also the plain old telephone channel as well as any VoIP channel, for instance the call channels of Skype, Messenger, WhatsApp, Slack, etc. In that sense, a conversational IVR could be seen as a voicebot. Another example would be a Dialogflow voicebot, accessible through any voice channel, that takes advantage of Dialogflow’s ability to detect intent from audio.

An Intelligent Virtual Agent (IVA) is a robot that simulates an agent (which, in this context, really means a contact center agent). It provides some of the services normally provided by a contact center agent through a communication with users – via voice or text channels – that resembles human-to-human communication. For reference, DMG defines an IVA as “A system that utilizes artificial intelligence, machine learning, advanced speech technologies (including NLU/NLP/NLG) to simulate live and unstructured cognitive conversations for voice, text, or digital interactions via a digital persona.” A virtual agent can hence be a chatbot, a voicebot, or both.

An Intelligent Virtual Assistant (also IVA, unfortunately) is a system that is dedicated to helping its user, either by providing useful information or advice (weather or traffic information, financial advice, etc.), by answering questions, or by accomplishing tasks on his/her behalf (e.g., planning meetings, booking hotels, paying bills, whatever). Interaction with an intelligent virtual assistant is often done through text or voice conversational channels, which effectively makes it a chatbot or a voicebot, but it can also be done through mobile or web applications.

An IVR (Interactive Voice Response) is an interactive telephone system that is primarily used in a call center to steer calls to the appropriate agent, and possibly to enable callers to perform some self-service transactions. Most IVR systems today are anything but conversational, relying instead primarily on menu navigation through DTMF (touch-tone) user inputs. Several IVR systems also enable speech input, but most of these only support voice menus and directed dialogs. More recently, natural language call steering applications, which enable callers to state the purpose of their call in their own words, have gained in popularity, but that remains a very small minority of IVR systems out there. The surge in popularity of conversational systems, however, is inevitably now impacting IVR, so expect to see a rapidly increasing number of IVR voicebots being deployed in the near future.

The post Assistants virtuels, agents conversationnels, agents virtuels, système de réponse vocale interactive : comment y voir plus clair ? (Article en anglais) first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Assistants virtuels, agents conversationnels, agents virtuels, système de réponse vocale interactive : comment y voir plus clair ? (Article en anglais) appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

Contact centers are still a central component of medium and large enterprises, and an essential channel for customers to connect with businesses. For a contact center to reach its full potential, it needs to meet the following business objectives:

• Customer service: provide customer support, deliver the best possible experience and generate positive word of mouth
• Customer retention: retain existing customers and boost customer loyalty
• Operational efficiency : by optimizing average interaction and resolution time

Contrary to popular belief, the telephone is still a widely used tool to connect with enterprises. While customers appreciate being able to self-serve and perform transactions on their own—whether on their mobile phone or on the web—they still turn to contact centers for assistance when they have more complex issues or are having a hard time with self-service. In both cases, the customer is likely to call your company looking to speak with a real person. And when they do, you want to be sure you make a strong impression!

Many enterprises today still rely on traditional touch-tone IVRs for call routing and to establish customer intent. But touch-tone menus are often complex, with multiple steps and options, confusing terminology and long wait times. Frustrated with the experience, customers end up hitting zero or selecting an incorrect option (any option!) hoping to reach an agent. This results in a high volume of misrouted calls, with customers having to repeat themselves and agents wasting valuable time talking to customers they can’t help.

These frustrating experiences, for both the caller and the agent, come at a cost: $62 billion in the U.S. alone in 2016.

So how can you improve your customer experience in the IVR while optimizing your agent resources? For starters, by asking customers why they’re calling, instead of having them go through a bunch of menu options trying to get their issue resolved.

Natural Language Call Steering (NLCS) IVRs use natural language understanding and automatic speech recognition to listen to callers, interpret what they’re saying and understand what they need.

By precisely categorizing the caller’s request, the NLCS can route the caller to the right agent on the very first try, most times in a single interaction. This serves to reduce the number of transfers and means callers don’t have to repeat themselves. Not only that, but the IVR can transfer the information it collects directly to the agent, giving them a head’s up as to why the customer is calling.

Making the transition from a touch-tone IVR to an NLCS solution is an investment, but one that will generate great returns. And sticking with the alternative can be extremely costly for companies in the long term, resulting in:

• High call transfer rates, a costly issue that wastes valuable agent resources
• Customer frustration, which again wastes agent resources (with customers spending more time expressing their frustration than discussing their needs) and leads to low agent morale/high employee turnover
• Poor customer retention, with existing customers often leaving the company after a single negative experience
• Loss of potential customers if the IVR experience is negative and you fail to make a good first impression

NLCS solutions result in fewer misrouted calls, reduced route times, fewer abandoned calls and better agent utilization—so you can improve your customer experience and reduce your operational costs. And the benefits don’t stop there. NLCS IVRs give you the opportunity to:

• Identify new self-service opportunities, by undersanding why people are calling, we can identify opportunities to address their issue right in the IVR, therefore greatly reducing the volume of calls into the contact center
• Offer simplified access to your services, by consolidating all your services in a single phone number
• Gather key data with analytics, giving you better insights into your customers, products and services

NLCS IVR solutions are a game changer, leveraging the latest conversational technologies to deliver an intuitive, human-like caller experience. Bring your voice channel into the future to improve your customer experience, boost customer loyalty, optimize your agent resources—and make every call count.

Many thanks to my colleague Annie Brasseur for her invaluable contribution to this post, and to Yves Normandin for his insightful comments.

Download our one pager!

The post Pour que chaque appel compte (Article en anglais) first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Pour que chaque appel compte (Article en anglais) appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

Our banking IVR is a self-service application in which a caller can execute tasks like paying a bill or getting an account balance. The dialogue includes a loop that allows the caller to carry out tasks as many times as he or she wants:

The application accommodates expert users by allowing them to quickly complete their tasks:

It also adapts to less experienced users by providing them with a more directed dialogue when needed:

The IVR supports mixed initiative strategies like digressions:

As well as change requests or corrections:

The dialogue also handles error recovery, including errors that are specific to the voice channel:

This is only an overview of the patterns handled by our dialogue model; several others are already implemented. We are also planning on adding other dialogue strategies, such as cancelling a task or handling more complex corrections and change requests.

Implementation: why we opted for a deterministic approach

Early on, we decided to rely on a deterministic approach for our use cases. The main reasons why machine learning was less adapted to our current use cases are as follows:

• Task related dialogues are predictable and relatively directed
• Tasks can be executed repeatedly and the application behavior should be identical every time
• Tasks should be interrupted and resumed reliably
• Tokens of information that are collected for a given task are not relevant for another
• Tasks are independent and must not interact with each other

In addition, our requirements for error recovery and change management were rather strict.

Deterministic approach

Our deterministic approach consists in managing actions using a stack. A stack is a data structure of type last in first out; in other words, the last item added to the stack is the first one to be removed. The action at the top of the stack is the one in focus. When we add an action to a stack, it becomes in focus. When the action in focus is completed, it is removed from the stack and the dialogue goes back to the previous action. This allows to interrupt and resume actions in a predictable and robust manner.

This can be illustrated as follows:

Here is an example of the state of a stack for a dialogue in which the user interrupts the ongoing action (digresses) to ask for a list of their accounts. Once the digression to hear the list of accounts is completed, this action is removed from the stack and the focus comes back to the previous action, that is, the bill payment action.

In addition to allowing us to manage digressions elegantly, our approach allows us to define isolated contexts for each action. This ensures that they remain independent.

Next are some additional details on how this was implemented using Rasa.

Custom policy

In Rasa, a policy is what allows to predict/specify the next action to be executed in the dialogue depending on context (tracker). Out-of-the-box, Rasa offers a combination of deterministic and machine learning based policies. It is also possible to create our own policy. This is what we did by implementing a deterministic policy that alternates between waiting for the next user input and triggering an action used as an action manager (responsible for managing the action stack). Since we do not make predictions as to what action must be executed, our policy does not use stories and does not require a training phase. This is the only policy that we use.

Action manager

We have created an abstraction to manage the action stack that was described above. The stack is a complex object that we store in an unfeaturized slot. The action to be executed depends on the user’s input as well as the state of the stack.

Custom dialogue patterns

One frequent dialogue pattern is information token collection, or slot-filling. This pattern is used, for instance, by the bill payment action. Rasa provides an action for this pattern: the FormAction. However, we needed to support other, more complex patterns than what is offered by the FormAction, for example: slot confirmation when the speech recognition confidence score is low, final confirmation at the end of an action, etc. We have therefore created a custom class “Task” that handles these more complex patterns. Some of our actions inherit this class. We appreciate that Rasa offers the flexibility that we need to implement our own dialogue management strategies.

Unit test framework

Since we have implemented our dialogues using a deterministic approach, we were able to build our own unit test framework to test our dialogues. This allowed us to increase our application’s reliability.

Next steps

Although we have been relying on a deterministic approach to develop our banking use cases, we are also currently experimenting with machine learning to develop dialogues for different use cases.

• Here are some of the next items that we will explore:
• Use the Recurrent Embedding Dialogue Policy to support uncooperative user behavior
• Use Rasa X to learn from real conversations
• Create more natural dialogues by using recorded prompts instead of TTS
• Try to integrate machine learning in our deterministic model

We will share our experience in future posts as we move forward. Stay tuned!

The post La RVI conversationnelle avec Rasa – 3e partie : gestion du dialogue (Article en anglais) first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post La RVI conversationnelle avec Rasa – 3e partie : gestion du dialogue (Article en anglais) appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

I know, there’s only one question on your mind right now: “What in the world is that name?”. First off, “Rivr” is because it uses Rivr, subtly mentioned in the first post, which is a Nu Echo created, open-sourced framework to write VoiceXML applications, entirely in Java. Then “Bridge” because it links a VoiceXML platform with the chosen dialogue engine. And yes, the pun was intended (but not by me).

But the real question is: “What does it do?”. As I said, Rivr is a framework to develop full-fledged applications, but the Rivr Bridge’s goal is only to translate what comes in and out of the VoiceXML platform and throw it to the Rasa side of the world in a digestible format. For instance, a classic Rivr application would programmatically process each user input and define the next dialogue steps, unlike the Rivr Bridge, which would query the chosen dialogue engine to decide the next dialogue steps. Adapting the model was simple, maybe even simpler than we thought. It roughly looks like this:

The great advantage of using the Rivr Bridge is that it interprets the VoiceXML platform’s input and generates bulletproof VoiceXML. For reusability purposes, we decided to make the Bridge platform-agnostic and application-agnostic, and let an IVR channel on the Rasa side manage the Rasa-specific aspects, which would allow us to eventually plug in other dialogue engines.

Here is an artistic representation of our input pipeline:

… Through an IVR JSON Protocol…

To better define the content of the requests and responses exchanged by the Rivr Bridge and the IVR channel, we designed a generic JSON protocol that could represent all necessary information for a conversational IVR application using VoiceXML. The protocol describes 5 types of input, namely: data (initialization data for example; caller’s phone number or any information the platform is set to return), user input (vocal or using the keypad) recognition/interpretation result, recording (of the user’s voice), transfer details (status, duration, etc.), event (hangup, noinput, nomatch…). Concerning outputs, we only designed support for interaction (the dialogue asks for a user input) and exit/hangup to cover our use cases.

As an example, to ask a question and wait for the answer, the dialogue could send this payload:

And the result sent by the Bridge could be:

… To the IVR Channel

Not a lot was then left for the IVR channel to do. Concerning inputs, each one would need some processing to be made accessible to the dialogue management. Specifically, inputs have to fit into Rasa’s NLU result format (namely, a string following the template: `intent@confidenceScore{“entityType”: entityValue, …}`). With well written grammars, this step’s implementation was rather simple for recognition results, but could have been tricky for input types with no intent nor entities (data, events), for which we still wanted to trigger a dialogue turn. To solve that problem, we could either create synthetic intents and entities representing the information we wanted to pass on, or insert it directly in the tracker and send a semantically empty input. We went for the first option, and created four synthetic intents to date:
start_conversation (with a data entity containing initialization data as a JSON object)
– noinput
– nomatch
– hangup

For the outputs, yet again some formatting was necessary, but since Rasa gives us full liberty on the output content through custom payloads, this was pretty straightforward. The (tiny bit more) delicate work was to concatenate and validate outputs from different parts of the dialogue. Rivr supports playing messages alone (without a recognition or hangup step), and it could be a nice feature for our Rasa dialogues, but would have required a bit more gymnastics in both the channel and the Bridge, so we chose not to implement it for now.

Ok, presenting it like that, maybe the IVR channel had a lot to do even with the use of the Rivr Bridge. But it was still less than generating VoiceXML content would have been. Thanks Rivr! To discover the journey of those user inputs once they enter the Rasa ocean, read the yet-to-come rest of the series!

The post La RVI conversationnelle avec Rasa – 2e partie : l’utilisation de Rivr (Article en anglais) first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post La RVI conversationnelle avec Rasa – 2e partie : l’utilisation de Rivr (Article en anglais) appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

Since Nu Echo’s foundation in 2002, VoiceXML has been the bread and butter of our IVR application development. We’ve been using it to create many solutions ranging from turnkey address change and identity validation modules to large scale IVR system using a custom JavaScript framework. We even open-sourced a Java VoiceXML development framework named Rivr, check it out!

While it is definitely possible to develop IVR applications in 2019 without using VoiceXML (think Dialogflow or Amazon Lex through Amazon Connect), it is still very prevalent in the large contact centers, which are an important part of our customer base. That’s why we decided to give Rasa a serious spin to find out if it could be a viable solution for developing multilingual conversational IVR applications using VoiceXML.

The use cases

For our proof of concept, we selected some banking use cases (account balance and pay bill) that offer us interesting dialogue patterns like digressions, confirmations, corrections and global commands (cancelling a task for example).

Here is an example that mixes some of those patterns:

Introducing Rasa IVR

Developing VoiceXML IVR applications using Rasa offers interesting challenges. For one, the real-time aspect of a voice conversation that must progress if the user says nothing is quite different from the classic chatbot approach. The application can’t keep the user waiting if he says nothing, it must propose alternate and more detailed messages and eventually terminate the conversation if the user decides to stay silent.

While Rasa offers a lot of prebuilt channels, nothing exists to express the richness of VoiceXML and interpret its different outputs. As you can see from the complexity of its specification, a lot must be done to cover all the functionalities (although some of them are less used than others). Some of the most important ones that must be taken into consideration for developing basic use cases are related to constructing the output (audio files / speech synthesis), activating bargein, specifying grammars / input mode (speech and/or DTMF), and configuring confidence levels / timeouts.

The user experience (UX) must also be tailored for the voice channel since the user cannot scroll up to access the whole conversation (unless he has a supernatural memory). Some patterns like confirmation or choosing in a list are much trickier to properly implement using voice than text and widgets.

Along with those challenges come some interesting opportunities. For example, using automatic speech recognition (ASR) alongside contextual grammars allows us to greatly improve the recognition accuracy by giving a greater weight to the most probable responses. VoiceXML also offers many functionalities for a better integration to the contact center, which must be exposed (agent transfer, attached data, recordings). The synchronous aspect of the conversation also simplifies the implementation since the user can’t frantically send multiple (sometimes contradictory) inputs.

As I said earlier, this post is the first of a series that will cover different aspects of the making of our conversational banking application proof of concept. Stay tuned for more articles from my colleagues on our approach toward generating VoiceXML, dialogue management, cloud deployment and more!

Many thanks to my colleagues Linda Thibault and Guillaume Voisine for their precious advice!

The post La RVI conversationnelle avec Rasa (Article en anglais) first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post La RVI conversationnelle avec Rasa (Article en anglais) appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

In other situations, we must rather produce canned demos, whose purpose is to “wow” potential clients by showcasing inspiring use cases and state of the art functionalities – even before the actual development takes place.

Between these two extremes, other types of demos can serve various purposes and can allow potential or existing clients to try, test and appreciate what a conversational IVR can do.

Different types of demos serve different purposes, require various amounts of effort and budget, allow diverse levels of hands on experience and involvement from those who try them, and present varying degrees of risk. Investing in the right type of demo for the right usage and the right prospect can be a determining factor in the success of that demo.

In the following paragraphs, I will describe four categories of demos, from the least to the most interactive, with their main characteristics, proposed usage, advantages and risks.

The canned demo

This is the type of demo that you often find on Youtube, where overly happy young people have an almost human conversation with the IVR. It recognizes the caller, understands everything, asks the right questions, reacts naturally when interrupted, and sometimes even risks a joke.

This type of demo is great to showcase the possibilities of a conversational IVR, to wow potential clients and make them dream, but also to provide decision makers with a vision of what their IVR could do for them, if they hired you. The canned demo is ideal to approach new prospects without investing a lot and without being too intrusive. Sales can safely use canned demos in early discussions with clients, and these demos can live on your website and be sent to anyone who’s interested in knowing about the potential of a conversational IVR.

On the flip side, canned demos can easily generate unrealistic expectations when the scenarios are too far from what your company can actually, realistically deliver. Overpromising is a risk, as well as making things look way easier than what they actually are to design and develop.

The scripted demo

The scripted demo consists of a working IVR that only supports a very finite number of scenarios, typically involving happy path use cases. It works well when the person calling the demo IVR knows exactly what to say, when, and how to say it.

This type of demo can allow you to demonstrate the technical feasibility of a few sample use cases in a fully controlled environment. Developing such a demo requires to design and develop a simple IVR, but it does not require to plan multiple scenarios or train sophisticated NLU models. Simple static speech grammars can be used, as long as the sample scenarios are covered.

While useful, this type of demo can easily underwhelm the recipient: it does not provide much of a wow factor, nor does it provide any hands on experience, since the prospective client is not really allowed to try it, with or without supervision. To use sparingly.

The environmentally controlled demo

The purpose of the controlled demo is to give your current or prospective client the opportunity to call a prototype of a conversational IVR, while making it clear which use cases or scenarios are included, and making sure you’re in the room when they call. It must be clear that the prototype is not production grade, but that it covers a large enough panorama of use cases and scenarios, including more than just happy paths.

This type of demo is great when you have an opportunity for more involved and detailed discussions with your client and wish to impress them with a sophisticated, well functioning demo. By trying it firsthand, your clients will get a feel for what their customers’ experience could be. By supervising the demo session, you have an opportunity to encourage your clients to try specific scenarios that you want to put forward, you can answer any questions they have and provide any technical details that they may find relevant or interesting. When properly done, this type of demo can convince a prospective client to move forward with your project.

This type of demo, however, requires quite a lot of work and presents some risks. To function properly, multiple scenarios must be anticipated and designed, including mixed initiative dialogues and error recovery strategies. In addition, the application must be robust to user input, which means a lot more time dedicated to developing good NLU models and speech grammars. Clients will try stuff; your demo IVR must be able to handle it.

The free roaming demo

That’s the fearless demo that you’re ready to release and let people use without supervision, and without you breathing down their necks. Scary!

This type of demo is more like a pilot deployment than a demo per se. It is pretty much the last stage of a prototype before it is ready to be deployed in production. It is extremely useful as a tool to collect data from a variety of users, or to share with internal employees at your client’s site to gather feedback for optimization. When it works well, it can also be used by some of your clients to showcase to other prospective clients in their enterprise, or by your partners to show to their clients.

Such a demo must include a significant number of functionalities, use cases and scenarios, including mixed initiative strategies, exception paths and error recovery strategies, as well as a very robust NLU module. This is costly. And the risk of letting such a demo out in the world is also significant. If it does not work well, it may have a very negative impact on your company’s image and communication strategy, among other things. But if it does work well, it can have enormous potential.

So, which one is right?

As you may have guessed by now, it depends. On what you want to demonstrate, to whom, in which context, on how much risk you are willing to take, and most of all, on how much time and money you can afford to spend.

• To manage risk, we recommend a few safety measures:
• Have a canned demo ready in case your interactive demo doesn’t work.
• Know your equipment and test it in advance.
• You should not use a speaker phone, as it affects barge-in and can impact speech recognition.
• Inform your department when you do a demo to ensure that no maintenance operation will take place during your presentation (yes, it happens!).
• The “demo curse” really exists! If a problem occurs, keep calm and carry on, and learn how to improvise.

In summary, whichever type of demo you decide to put forward, managing expectations and clearly communicating the demo’s purpose and limitations are essential to its success. You don’t get a second chance to make a good impression!

Many thanks to my colleague Jean-Philippe Gariépy for the initial idea, his review and great suggestions!

The post Jusqu’où pouvez-vous aller? Gestion des attentes clients dans les démonstrations RVI conversationnelles (Article en anglais) first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Jusqu’où pouvez-vous aller? Gestion des attentes clients dans les démonstrations RVI conversationnelles (Article en anglais) appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.