Lo que aprendí al diseñar integraciones de backend omnicanal
Esquema de intención compartida, estado de conversación eventualmente consistente y por qué el canal debería ser lo último que tu backend conozca.
Parte de Backend Craft
Omnicanal es una palabra que se utiliza mucho por personas que venden tableros de control. Lo que realmente significa es: un cliente comienza en WhatsApp, continúa en voz, termina en la web, y espera que tu sistema se mantenga al día.
El backend no debe saber qué canal es
La mayor victoria de cualquier proyecto omnicanal que he construido es esta regla:
El código de cumplimiento no debe ramificarse según el canal. Si lo hace, estás construyendo N productos.
La lógica de tu bot, tus prompts de LLM, tus actualizaciones de CRM —nada de eso debería importar si la entrada provino de SMS, voz, web o paloma mensajera. El adaptador de canal normaliza a un sobre común y lo entrega. Todo lo que viene después opera en intenciones y entidades, no en "la voz dice esto, WhatsApp dice aquello".
El estado de la conversación es eventualmente consistente
Los llamadores no esperan por tu retraso de replicación. Si el llamador escala de bot a agente a través de un cambio de canal, el agente necesita un estado que podría estar 500 ms detrás del borde.
Dos opciones que funcionan:
- Registro de conversación de escritor único identificado por cliente + sesión. Cada canal escribe eventos solo de adición. Los lectores proyectan.
- Instantánea "última conocida" idempotente que cualquier canal puede sobrescribir, con un sello de versión. Más simple, menos seguro.
Yo prefiero el registro. Solo de adición es aburrido y correcto.
El esquema de intenciones es el contrato
Si tu equipo de voz y tu equipo de chat definen intenciones de manera diferente, las fusionarás más tarde bajo presión de tiempo. Define una ontología de intenciones compartida desde el primer día. Versiona eso. Trata los cambios como cambios de API.
Lo que le diría a mi yo del pasado
- Construye el adaptador de canal al final. Primero haz que el cumplimiento sea correcto.
- Mide el éxito del cambio de canal como un KPI de primera clase. Es el único que prueba que el omnicanal funciona.
- Presupuesta para la observabilidad que abarque canales. Un rastro que muere cuando la voz pasa a la web no es un rastro.
Relacionado
Sigue leyendo
Nota diaria: Hoy aprendí — etiquetas <mark> de Polly SSML
Las etiquetas <mark> de SSML de Polly emiten eventos de temporización a través del flujo. Son útiles para sincronizar los subtítulos en pantalla con la reproducción de voz.
Nota diaria: Depurando un flujo de API en producción
La prueba de integración pasó, el entorno de staging está en verde, pero en producción falla para el 1% de los llamadores. El error estaba en un lugar que nunca habría adivinado.
Construyendo Integraciones de Voz sobre Chatbots Asíncronos
¿Qué se rompe cuando enfrentas un chatbot asíncrono con Amazon Connect + Lex, y cómo mantener la latencia, la interrupción y la transferencia de contexto en un nivel razonable?
Continúa
¿A dónde sigues?
Explora más textos técnicos, revisa los casos de estudio o escríbeme directo.