Agente de Voz IVR — Estudio de Caso Laboral
Conectando conversaciones asíncronas de chatbots en flujos IVR de Amazon Connect en Espressive
Resumen
Contexto, enfoque y resultado.
Problema
El agente de soporte virtual de Espressive fue construido para chat asíncrono, donde una respuesta de dos segundos se siente rápida. Una llamada telefónica es un canal en tiempo real y bloqueante: los que llaman escuchan cada salto en la tubería como silencio. La plataforma necesitaba un canal de voz sin reescribir el backend del chatbot existente.
Mi rol
Arquitecté y lideré la integración de principio a fin: enrutamiento de intenciones, orquestación de conversión de voz a texto/texto a voz a través de Amazon Connect, Amazon Lex, AWS Lambda y Polly, y la transferencia al cumplimiento existente.
Restricciones
- Los presupuestos de latencia de voz son implacables: los que llaman notan brechas de menos de un segundo que los usuarios de chat nunca ven.
- El backend de cumplimiento asíncrono era infraestructura de producción compartida con cada canal de chat; no se podía bifurcar para voz.
- Los requisitos de seguridad empresarial —autenticación, manejo de secretos— se aplicaban a cada nuevo salto.
Arquitectura
Amazon Connect captura audio y lo transmite a Lex para la resolución de intenciones; un puente de Lambda traduce entre el flujo IVR sincrónico y el backend de chatbot asíncrono, luego Polly sintetiza respuestas de vuelta a la llamada. Las búsquedas posteriores comienzan especulativamente al inicio de la expresión en lugar de después de la resolución de intenciones, y el viaje de un llamador se correlaciona a través de Connect, Lex, Lambda y APIs posteriores para que los rastros sobrevivan al límite del canal.
Resultado
Se lanzó como un canal de producción de la plataforma del agente de soporte virtual que ayudó a reducir el volumen de llamadas al servicio de asistencia en un 40–60%.
Lo que haría diferente
Diseñaría la correlación entre servicios desde el primer día en lugar de agregarla durante el endurecimiento: los rastros que mueren en un límite de canal no son rastros. Y presupuestaría para la semántica de cancelación por interrupción desde el principio: cada síntesis en curso se vuelve cancelable, lo que cambia los requisitos de idempotencia a nivel posterior.
Aprendizajes
Lo que me llevo.
Los presupuestos de latencia de voz son implacables: la prefetching al inicio de la expresión supera cualquier optimización posterior. Y los rastros que mueren en el límite del canal no son rastros; la correlación entre servicios debe ser diseñada desde el inicio, no añadida después.
Stack
Herramientas y plataformas.
Textos relacionados
Notas de este proyecto.
- Daily Note: TIL — Polly SSML <mark> tagsPolly's SSML <mark> tags emit timing events over the stream. Useful for synchronizing on-screen captions to voice playback.
- Building Voice Integrations on Top of Async ChatbotsWhat breaks when you front an async chatbot with Amazon Connect + Lex, and how to keep latency, barge-in, and context handoff sane.
Conversemos
¿Quieres platicar de este tipo de trabajo?
Si estás contratando para trabajo backend, AWS, voz o integraciones similares —o simplemente quieres comparar notas de arquitectura— escríbeme directo.