Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Bonnes pratiques pour concevoir les bases d'une expérience IVR dynamique et modulaire sur Amazon Connect
Ayesha Borker et Nicholas Pung, Amazon Web Services ()AWS
Août 2023 (historique du document)
Les architectes techniques, les développeurs et les équipes commerciales ont la possibilité de réinventer les expériences automatisées en libre-service qu'ils proposent à leurs clients lorsqu'ils migrent vers un centre de contact basé sur le cloud à l'aide d'Amazon Connect.
Les équipes commerciales souhaitent généralement ajouter des fonctionnalités et des fonctionnalités tout en personnalisant davantage l'expérience en libre-service. Les architectes techniques et les développeurs se concentrent principalement sur la manière de réduire la redondance, de permettre des changements rapides et de la flexibilité, de modulariser les processus répétés et de réduire les frais de maintenance.
Ce guide fournit aux architectes techniques un ensemble de bonnes pratiques qu'ils peuvent utiliser pour créer la conception de base de leur application de réponse vocale interactive (IVR) de manière modulaire et dynamique. Il fournit des exemples de systèmes IVR (c'est-à-dire de technologies vocales). Cependant, vous pouvez étendre les mêmes concepts à tous les autres canaux. Le guide se concentre sur la création d'une conception IVR modulaire et évolutive à l'aide de flux et de modules Amazon Connect. Amazon Lex, qui vous permet d'ajouter des fonctionnalités de langage naturel (NL) à votre application IVR, est hors de portée.
Présentation
Les méthodes traditionnelles de conception d'expériences IVR peuvent être statiques et complexes. Organisations gèrent souvent des expériences distinctes pour différents langages, environnements de déploiement (tels que le développement, les tests et la production), pays et secteurs d'activité (LOBs). Ils s'appuient souvent sur le talent de la voix humaine pour créer des instructions, qui sont ensuite téléchargées et référencées dans des scripts codés en dur. Cela complique le processus de modification et de mise à jour, en particulier en temps réel pour les urgences ou les annonces urgentes. Lorsque les applications sont séparées de cette manière, nous constatons souvent que les cas d'utilisation courants se répètent et sont gérés de manière redondante. Les exemples courants incluent la réception de paiements sur un système IVR ou l'envoi d'un SMS après une transaction. Les intégrations dorsales aux bases de données, aux solutions de gestion de la relation client (CRM) ou à d'autres systèmes tiers sont souvent codées en dur, ce qui signifie que les modifications doivent être répliquées manuellement sur plusieurs applications.
Ce type de conception d'architecture monolithique entraîne des processus administratifs et des frais de gestion excessifs, et entrave l'innovation. Les développeurs passent plus de temps à mettre en œuvre de petits changements dans de multiples dépendances, ce qui les empêche de suivre les processus agiles. Souvent, cette complexité devient fastidieuse et les entreprises doivent faire appel à des organisations de services professionnels ou à des consultants externes pour les aider à gérer ces changements. Par conséquent, l'entreprise constate une augmentation des délais d'exécution pour les mises à jour classiques. Une architecture complexe qui implique ces cycles de développement complexes et chronophages entraîne une augmentation des coûts.
Ce guide se concentre sur une architecture de base pour une application IVR qui aide à éliminer les redondances et à rationaliser le processus de gestion du changement. Cette architecture facilite la maintenance et l'innovation pour les développeurs, et fournit également aux entreprises l'agilité dont elles ont besoin.
Table des matières
