La urgente necesidad de modernizar la plataforma IVR

La mayoría de las organizaciones de TI empresariales tienen aplicaciones avanzadas de IVR basadas en telefonía que sirven como «puerta de entrada» para todas las llamadas de atención al cliente basadas en voz. Estas aplicaciones utilizan una combinación de tonos táctiles (DTMF) y voz para interactuar con las personas que llaman. Se han diseñado, desarrollado y ajustado cuidadosamente a lo largo de los años.

Los objetivos de cualquier IVR son dos: 1) Automatizar las consultas rutinarias sencillas (como la consulta del saldo, el estado de los pagos, etc.) y 2) autenticar y dirigir de forma inteligente las llamadas que requieren asistencia en vivo al agente correspondiente.

Las organizaciones de TI de todos los sectores verticales de la industria, como los servicios financieros, los viajes, los medios de comunicación, las telecomunicaciones, el comercio minorista o la atención médica, cuentan con un pequeño equipo de desarrolladores de IVR internos o subcontratados para mantener estas aplicaciones. Si bien las empresas se han centrado en ampliar y actualizar sus canales de soporte digital (como el chat y el correo electrónico), las aplicaciones de IVR prácticamente no se han utilizado durante años.

A medida que los CIO y los CDO (directores digitales) se embarcan en iniciativas estratégicas para migrar las cargas de trabajo empresariales a la nube, una carga de trabajo «especializada» en esta lista es el IVR. Sin embargo, migrar los IVR «tal cual» a la nube es complicado. Los lenguajes, protocolos y plataformas en los que se crearon estos IVR basados en telefonía datan de principios de la década de 2000 y están a punto de quedar obsoletos. Además, si bien admiten diálogos dirigidos con expresiones habladas limitadas por parte del cliente, no son adecuados para las interacciones conversacionales entre bots.

Por lo tanto, las organizaciones de TI se enfrentan a una situación difícil. Por un lado, es engorroso mantener estas cargas de trabajo de IVR. Por otro lado, la justificación para migrar las plataformas existentes «tal cual» a una infraestructura de nube moderna es cuestionable. ¿Para qué soportar las molestias y los gastos si los IVR eventualmente van a ser reemplazados por bots conversacionales?

Por lo tanto, existe una necesidad real de modernizar estos IVR como parte de su estrategia de migración a la nube.

Un breve análisis de la infraestructura subyacente de estas aplicaciones de IVR

‍

Tradicionalmente, las aplicaciones de IVR de voz se ejecutaban en plataformas de telefonía de Contact Center locales. Empresas como Avaya, Nortel, Cisco, Intervoice, Genesys y Aspect dominaron el panorama de los proveedores. A principios y mediados de la década de 2000, estos proveedores trabajaron en colaboración como parte del consorcio del W3C para desarrollar XML de voz, un lenguaje abierto independiente del proveedor para aplicaciones de IVR con capacidad de voz.

VoiceXML permitió a los desarrolladores crear diálogos de voz interactivos y proporcionó una forma estándar de interactuar con un reconocedor automático de voz (ASR). Esto se hizo mediante un protocolo basado en telefonía llamado MRCP. El estándar también proporcionaba un método para definir las gramáticas del habla denominado SARGOS y un formato llamado GRXML.

La arquitectura y la jerga y terminología de apoyo en torno a VoiceXML se inspiraron en gran medida en el mundo web. La plataforma VoiceXML se denominaba «navegador de voz» que podía «renderizar páginas de VoiceXML» del mismo modo que un navegador web podía renderizar páginas HTML. La mayoría de las plataformas de centros de contacto proporcionaban IDE visuales para ayudar a crear y mantener estos flujos de llamadas interactivos. Algunas también automatizaron la generación de las páginas de VoiceXML. El IDE generaba código que podía ejecutarse en un servidor de aplicaciones (como Apache Tomcat), que a su vez generaba páginas de VoiceXML que se enviaban a una plataforma de VoiceXML a través de HTTP estándar. El servidor de aplicaciones también era responsable de realizar las solicitudes de servicios web a los recursos de bases de datos empresariales que eran necesarios para la interacción con el IVR; por ejemplo, los sistemas de facturación y pago o los sistemas CRM.

Además, la mayoría de los ASR de finales de los 90 y principios de los 2000 se basaron en modelos ocultos de Markov y modelos de mezcla gaussiana. Principalmente eran compatibles con el reconocimiento gramatical, lo que significaba que, como desarrollador de Speech IVR, tenías que anticipar todas las expresiones posibles que un usuario podía pronunciar en respuesta a una pregunta o mensaje. Existían algunas opciones para crear modelos lingüísticos estadísticos abiertos, pero eran complicadas y requerían una cuidadosa selección del corpus formativo.

¿Por qué modernizar ahora?

‍Si bien VoiceXML funcionó bien en el pasado, es un lenguaje especializado y anticuado. ¡La última versión de VoiceXML 2.1 fue en 2007! Eso fue hace más de una década.

Y muchas cosas han cambiado en el mundo web desde entonces. VoiceXML se desarrolló en una época en la que se utilizaba ampliamente JSP (Java Server Pages). Así fue antes de JSON, YAML, las API RESTful y AJAX.

Para las empresas, es caro mantener un personal dedicado, ya sea interno o subcontratado, con conocimientos especializados en tecnologías como VoiceXML y MRCP.

Lo ideal es que las empresas puedan ejecutar la aplicación IVR como cualquier otra aplicación web moderna. La mayoría de las aplicaciones web empresariales se basan en lenguajes de programación como Python y Node.JS, que son populares entre los desarrolladores web. Se almacenan en contenedores con Docker y se orquestan con Kubernetes.

Sería ideal para una organización de TI empresarial que su aplicación IVR se construyera en lenguajes de programación similares para que pueda recibir soporte o mantenimiento al igual que otras aplicaciones de la cartera de TI.

Además de la obsolescencia de VoiceXML, el motor de reconocimiento de voz (ASR) que se implementó a principios de la década de 2000 también ha quedado obsoleto. Los motores modernos de conversión de voz a texto se basan en redes neuronales profundas que funcionan en una potente infraestructura de GPU. Ofrecen una precisión asombrosa y permiten el uso de un vocabulario muy amplio, que es lo que se necesita para una experiencia conversacional similar a la de los bots. Además, los modernos motores de NLU permiten extraer fácilmente las intenciones del texto transcrito.

Por lo tanto, si una empresa quiere ofrecer un bot de voz que admita una experiencia de conversación abierta, debe pasar a una plataforma moderna de conversión de voz a texto basada en DNN que pueda integrarse con dichos motores de NLU.

Nuestra receta para la modernización de las aplicaciones IVR

En Voicegain, recomendamos que la empresa primero modernice la infraestructura subyacente y, al mismo tiempo, conserve la lógica de aplicación de IVR existente. Este es un excelente primer paso. Permite a una empresa seguir atendiendo a los usuarios existentes y, al mismo tiempo, dar un paso hacia la prestación de una experiencia de usuario más conversacional.

¿Cómo puede una empresa modernizar su aplicación IVR heredada?

Sugerimos que la lógica de flujo de llamadas existente, que normalmente se mantiene mediante IDE visuales de las plataformas de centros de contacto, se reescriba (idealmente con la ayuda de herramientas automatizadas) en un lenguaje de programación moderno como Python o Node.Js.

En lugar de generar páginas antiguas de VoiceXML, las empresas deberían utilizar lenguajes de representación de datos compatibles con la web, como JSON o YAML, para interactuar con las modernas API RESTful Speech-to-Text mediante llamadas web.

¿Cómo apoya Voicegain la modernización de la aplicación IVR?

En Voicegain, ofrecemos una plataforma moderna de IA de voz que incluye

1. Un moderno reconocedor de voz basado en DNN accesible mediante API RESTful
2. Capacidad de interactuar directamente con las llamadas telefónicas entregadas a través de SIP/RTP
3. API de devolución de llamadas de estilo JSON para reemplazar la funcionalidad de un VoiceXML
4. Capacidad de implementación en su VPC/nube privada o de uso como servicio en la nube
5. Totalmente compatible con las funciones de los estándares antiguos (admite gramáticas SRGS y universales)
6. Entrenamiento del modelo acústico subyacente y los modelos lingüísticos para obtener una alta precisión de reconocimiento

Voicegain está desarrollando herramientas para convertir automáticamente VoiceXML a una representación JSON/YAML equivalente que se comunica con nuestras API de devolución de llamadas.

¿Cómo es esta una arquitectura «preparada para el futuro» para una empresa?

La plataforma Voicegain es capaz de transcribir gran cantidad de vocabulario, lo cual es un requisito para los Voice Bots basados en NLU. Esta será la forma en que los clientes interactuarán con las empresas en el futuro.

Permitimos a los desarrolladores cambiar entre el reconocimiento basado en la gramática y el reconocimiento de vocabulario extenso en cada turno del cuadro de diálogo; o bien, puedes usar ambos simultáneamente para lograr una mayor flexibilidad.

Nuestra API de bots de telefonía también puede integrarse con Bot Frameworks como Google Dialog Flow,.

Estamos invitando a desarrolladores web empresariales de forma gratuita juicio de nuestra plataforma.