Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Prácticas recomendadas para diseñar las bases de una experiencia de IVR dinámica y modular en Amazon Connect
Ayesha Borker y Nicholas Pung, Amazon Web Services ()AWS
agosto de 2023 (historial de documentos)
Los arquitectos técnicos, los desarrolladores y los equipos empresariales tienen la oportunidad de reimaginar las experiencias de autoservicio automatizadas que ofrecen a sus clientes cuando migran a un centro de contacto basado en la nube mediante Amazon Connect.
Los equipos empresariales suelen querer añadir funcionalidades y características y, al mismo tiempo, personalizar más la experiencia de autoservicio. Los arquitectos técnicos y los desarrolladores se centran principalmente en cómo reducir la redundancia, permitir cambios rápidos y flexibilidad, modular los procesos repetidos y reducir los gastos de mantenimiento.
Esta guía proporciona a los arquitectos técnicos un conjunto de prácticas recomendadas que pueden utilizar para crear el diseño fundamental de su aplicación de respuesta de voz interactiva (IVR) de forma modular y dinámica. Proporciona ejemplos de sistemas de IVR (es decir, tecnologías de voz). Sin embargo, puede extender los mismos conceptos a cualquier otro canal. La guía se centra en la creación de un diseño de IVR modular y escalable mediante el uso de flujos y módulos de Amazon Connect. Amazon Lex, que le permite añadir funciones de lenguaje natural (NL) a su aplicación de IVR, está fuera del ámbito de aplicación.
Descripción general
Los métodos tradicionales para el diseño de experiencias de IVR pueden ser estáticos y complejos. Las organizaciones suelen gestionar experiencias independientes para diferentes idiomas, entornos de implementación (como desarrollo, pruebas y producción), países y líneas de negocio (LOBs). Con frecuencia, confían en el talento de la voz humana para crear mensajes, que luego se cargan y se hace referencia a ellos en guiones codificados. Esto complica el proceso de realizar cambios y actualizaciones, especialmente en tiempo real en el caso de emergencias o anuncios urgentes. Cuando las aplicaciones se separan de esta manera, solemos observar que los casos de uso habituales se repiten y se gestionan de forma redundante. Algunos ejemplos comunes son la recepción de pagos mediante un sistema IVR o el envío de un SMS después de la transacción. Las integraciones de backend con bases de datos, soluciones de gestión de relaciones con los clientes (CRM) u otros sistemas de terceros suelen estar codificadas de forma rígida, lo que significa que los cambios deben replicarse manualmente en varias aplicaciones.
Este tipo de diseño de arquitectura monolítica genera procesos administrativos y una sobrecarga de gestión excesivos, e impide la innovación. Los desarrolladores dedican más tiempo a implementar pequeños cambios en múltiples dependencias, lo que les dificulta seguir procesos ágiles. A menudo, esta complejidad se convierte en una carga y las empresas deben confiar en organizaciones de servicios profesionales o consultores externos para que les ayuden a gestionar estos cambios. Como resultado, la empresa aumenta el tiempo de respuesta de las actualizaciones habituales. Una arquitectura complicada que implica estos ciclos de desarrollo complejos y lentos se traduce en un aumento de los costes.
Esta guía se centra en una arquitectura fundamental para una aplicación de IVR que ayuda a eliminar las redundancias y agiliza el proceso de gestión de cambios. Esta arquitectura facilita a los desarrolladores el mantenimiento y la innovación, y también proporciona a las empresas la agilidad que necesitan.
Contenido
