Agente de Voz IVR — Estudio de Caso Laboral

Problema

El agente virtual de soporte de Resolve Systems fue diseñado para chat asincrónico, donde una respuesta en dos segundos se siente rápida. Una llamada telefónica es un canal bloqueante y en tiempo real: los usuarios escuchan cada salto en la cadena como silencio. La plataforma necesitaba un canal de voz sin reescribir el backend del chatbot existente.

Mi rol

Diseñé la arquitectura de principio a fin y la implementé: enrutamiento de intenciones, orquestación de speech-to-text y text-to-speech a través de Amazon Connect, Amazon Lex, AWS Lambda y Polly, y la transferencia al fulfillment existente.

La parte que lo hizo posible no fue específica de voz. Diseñé y construí la capa de integración con Factory Method sobre la que corre la plataforma del chatbot: cada canal se normaliza en un solo sobre, una fábrica instancia el adaptador correcto, y el fulfillment opera sobre intenciones y entidades sin ramificarse por canal.

La propiedad que importó es que la abstracción es neutral respecto al tiempo. Slack, Teams, Google Chat y Webex son asincrónicos; una llamada telefónica es sincrónica y bloqueante. Ambos son adaptadores. La interfaz no hace ninguna afirmación sobre si una respuesta llega en dos segundos o doscientos milisegundos, por lo que la voz se agregó sobre una interfaz que ya existía en lugar de bifurcar la infraestructura de producción para adaptarla. Definir bien ese límite primero es la razón por la que el canal más difícil pudo agregarse.

Restricciones

• Los presupuestos de latencia en voz son implacables: los usuarios notan pausas de menos de un segundo que los usuarios de chat nunca ven.
• El backend asincrónico de fulfillment era infraestructura de producción compartida con todos los canales de chat; no podía bifurcarse para voz.
• Los requisitos de seguridad empresarial — autenticación, manejo de secretos — aplicaban a cada nuevo salto.

Arquitectura

Amazon Connect captura audio y lo transmite a Lex para resolución de intenciones; un puente Lambda traduce entre el flujo IVR sincrónico y el backend asincrónico del chatbot, luego Polly sintetiza respuestas de vuelta a la llamada. Las consultas posteriores comienzan especulativamente al inicio de la expresión en lugar de después de la resolución de intención, y el recorrido del usuario se correlaciona a través de Connect, Lex, Lambda y APIs posteriores para que los trazos sobrevivan el límite del canal.

Resultado

Se lanzó como un canal de producción de la plataforma del agente virtual de soporte que ayudó a reducir el volumen de llamadas al help-desk entre 40 y 60%.

Qué pasó después

El canal se movió fuera del stack de AWS a Vapi, que hace más orquestación en tiempo real como plataforma que el enfoque de primitivas ensambladas. Esto vale la pena decirlo claramente: después del esfuerzo de construir el puente, una plataforma de voz hecha a la medida resultó ser el mejor agente. La evaluación de otras plataformas de voz sigue en curso y corre en paralelo con ese trabajo, porque las restricciones decisivas en este tipo de sistemas rara vez son solo técnicas.

Lo que sobrevivió a la migración es la parte que seguiría construyendo igual: la capa de integración subyacente. Como el fulfillment nunca se ramificó por canal, reemplazar el front end de voz no lo tocó.

Qué haría diferente

Diseñar la correlación entre servicios desde el día uno en lugar de agregarla durante el endurecimiento — los trazos que mueren en un límite de canal no son trazos. Y presupuestar desde temprano la semántica de cancelación por interrupción: cada síntesis en curso debe ser cancelable, lo que cambia los requisitos de idempotencia aguas abajo.