Mejores prácticas para diseñar las bases de una experiencia de IVR dinámica y modular en Connect Customer

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 Connect Customer.

Los equipos empresariales suelen querer agregar funcionalidades y características, además de personalizar más la experiencia de autoservicio. Los arquitectos técnicos y los desarrolladores se centran sobre todo en cómo reducir la redundancia, permitir cambios rápidos y flexibilidad, modular los procesos repetidos y reducir los gastos generales de mantenimiento.

En esta guía se 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 manera modular y dinámica. Se proporcionan ejemplos de los sistemas de IVR (es decir, tecnologías de voz). Sin embargo, puede aplicar los mismos conceptos a cualquier otro canal. La guía se centra en crear un diseño de IVR modular y escalable mediante el uso de flujos y módulos de Connect Customer. Amazon Lex, que le permite agregar características de lenguaje natural (NL) a la aplicación de IVR, está fuera del ámbito de aplicación.

Descripción general de

Los métodos tradicionales para el diseño de experiencias de IVR pueden ser estáticos y complejos. Las organizaciones a menudo administrar experiencias independientes para distintos idiomas, entornos de implementación (como desarrollo, pruebas y producción), países y líneas de negocio (LOB). Con frecuencia, confían en el talento de la voz humana para crear peticiones, que luego se cargan y se hace referencia a estas en guiones codificados. Esto complica el proceso para hacer cambios y actualizaciones, sobre todo en tiempo real en el caso de emergencias o anuncios urgentes. Cuando las aplicaciones se separan de esta manera, a menudo se observa que los casos de uso habituales se repiten y se administran de manera redundante. Algunos ejemplos comunes son la recepción de pagos mediante un sistema de IVR o el envío de un SMS después de la transacción. Las integraciones de backend con bases de datos, soluciones de administración de relaciones con los clientes (CRM) u otros sistemas de terceros suelen tener una codificación rígida, lo que significa que los cambios deben replicarse de manera manual en varias aplicaciones.

Este tipo de diseño de arquitectura monolítica genera procesos administrativos y gastos generales de administración excesivos, e impide la innovación. Los desarrolladores dedican más tiempo a implementar cambios pequeños en varias dependencias, lo que les dificulta seguir procesos ágiles. A menudo, esta complejidad se convierte en una carga y las empresas deben recurrir a organizaciones de servicios profesionales o consultores externos para que les ayuden a administrar 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 largos provoca un aumento de los costos.

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 administración de cambios. Esta arquitectura facilita a los desarrolladores el mantenimiento y la innovación. También proporciona a las empresas la agilidad que necesitan.

Contenido