Si tu soporte por WhatsApp tarda, se contradice o pierde contexto, el problema no suele estar en el agente: está en cómo se mueven los datos entre sistemas.
Yo lo resumiría así: cuando una marca pasa de decenas a cientos de pedidos por día, consultar sistema por sistema deja de servir. Shopify, Tiendanube, VTEX, logística, pagos y WhatsApp actualizan datos en momentos distintos. El resultado es conocido: respuestas cruzadas, demoras, reintegros sin contexto y clientes que tienen que repetir todo.
La salida es simple de explicar: usar microservicios con una capa de eventos común. En vez de pedir datos “en vivo” cada vez que entra un mensaje, cada sistema informa lo que pasó y el resto reacciona sobre ese cambio. Así, soporte trabaja con un estado compartido, historial del caso y reglas claras para cambios, cancelaciones, devoluciones y traspasos entre IA y personas.
Puntos clave del artículo:
OrderPaid, OrderShipped, ReturnRequested y RefundProcessed.order_id e idempotencia evitan duplicados, desorden y fallas al procesar webhooks.En pocas palabras: si no hay una capa de eventos, soporte siempre responde tarde o con datos cruzados. Y si esa capa existe, WhatsApp pasa de ser un cuello de botella a un canal conectado con pedidos, logística, pagos e inventario.
La salida pasa por una arquitectura orientada a eventos. Cada capacidad de soporte vive en un servicio aparte, ordena el estado que suele quedar repartido entre varios sistemas y se coordina con eventos de negocio, no con llamadas directas. Con esa base, cada servicio se ocupa de una parte del soporte y evita que WhatsApp dependa de chequeos manuales.
En lugar de que un bot consulte en tiempo real a Shopify, al operador logístico y a la pasarela de pagos cada vez que entra un mensaje, cada sistema publica un evento cuando cambia algo. Los demás servicios lo escuchan y actúan. Así, el agente no tiene que ir saltando entre paneles distintos para entender qué pasó.
Orders maneja el ciclo del pedido. Returns se ocupa de la automatización de devoluciones y reintegros. Notifications envía los mensajes de WhatsApp. Inventory controla el stock. Routing decide si responde la IA o una persona. Agent Inbox concentra el hilo completo del caso.
Burbuxa conecta WhatsApp y Shopify, Tiendanube y VTEX, sincroniza pedidos, clientes, stock, descuentos y políticas en tiempo real, y les da ese contexto a sus agentes de IA para resolver casos comunes en WhatsApp.
Los eventos son el idioma compartido entre servicios. Cada evento deja registrado un hecho que ya ocurrió, y cualquier servicio suscripto puede reaccionar sin que otro tenga que llamarlo de forma directa.
No hace falta tener decenas de eventos para que esto funcione bien. Con unos pocos, se cubre gran parte de los casos de soporte del día a día.
| Evento | Quién reacciona | Resultado concreto |
|---|---|---|
OrderPaid | Notifications, Inventory | WhatsApp de confirmación enviado; stock ajustado |
OrderShipped | Notifications | Mensaje con número de seguimiento |
OrderDelivered | Notifications | Confirmación de entrega |
ReturnRequested | Returns, Routing | Evaluación de elegibilidad; IA o agente asignado |
ReturnApproved | Notifications, Inventory | Aviso al cliente; stock liberado |
RefundProcessed | Notifications | Confirmación de reintegro en ARS |
AgentHandoffRequested | Agent Inbox | Ticket creado con historial completo adjunto |
Cuando Returns recibe ReturnRequested, valida la elegibilidad. Después, Routing define si el caso lo resuelve la IA o si conviene derivarlo. Si lo deriva, AgentHandoffRequested crea el ticket con el pedido, los mensajes y los eventos. Entonces el agente humano entra al caso con todo el contexto, sin arrancar de cero y sin salir del mismo hilo de WhatsApp.
Con esta capa ya armada, el paso que sigue es resolver estados de pedido, cambios y devoluciones sin mezclar sistemas.
CRUD Sincrónico vs. Microservicios Orientados a Eventos en Soporte WhatsApp
Con los servicios separados, estos eventos resuelven casos bien concretos: estado del pedido, cambios, devoluciones y notificaciones.
Cuando esos eventos ya están circulando, soporte deja de mirar sistemas sueltos y pasa a responder sobre un estado común.
Con CQRS, los mensajes de WhatsApp se transforman en comandos - "Consultar estado del pedido", "Cambiar dirección de envío" - que van a los servicios de escritura. Mientras tanto, las consultas de estado se resuelven contra modelos de lectura ya preparados, que se actualizan con el stream de eventos. Si un cliente escribe "¿mi pedido #4872 ya fue despachado?", el agente no necesita pegar un salto al e-commerce ni hacer una consulta directa: revisa un modelo de lectura que ya consumió los eventos OrderPacked, ShipmentLabeled y ShipmentDispatched, y devuelve el estado al día junto con la ventana de entrega estimada - por ejemplo, entre el 18/08 y el 20/08.
El registro de eventos suma otra capa de valor. Cada acción queda guardada de forma inmutable: mensajes del cliente, respuestas del agente, decisiones de la IA y eventos del sistema. Eso permite reconstruir toda la línea de tiempo del caso sin salir de WhatsApp. En soporte, eso vale oro: si algo salió mal, el historial está ahí, completo, sin parches ni versiones cruzadas.
Cada acción de soporte se modela como un comando con reglas de validación explícitas. Un cambio de dirección comprueba que el pedido todavía no haya salido. Un cambio de talle revisa el stock disponible. Una cancelación evalúa el estado del pago y la etapa de preparación. Si la validación pasa, el comando genera eventos (ShippingAddressChanged, SizeChangeApproved, OrderCancelled) que se propagan a todos los sistemas involucrados: tienda, operador logístico y pasarela de pagos.
Ese patrón mantiene sincronizados tienda, depósito y WhatsApp en tiempo real, facilitando la automatización de WhatsApp en TiendaNube. No hay un sistema diciendo una cosa y otro mostrando otra. Por ejemplo, cuando se procesa un RefundCompletedARS, el cliente recibe un mensaje con el monto exacto en AR$ y el tiempo estimado de acreditación, sin que un agente tenga que mover hilos a mano.
La diferencia entre los dos enfoques salta a la vista cuando la operación crece y todos los canales necesitan el mismo dato.
| Dimensión | CRUD sincrónico | Microservicios orientados a eventos |
|---|---|---|
| Frescura del estado | Depende del polling; riesgo de datos desactualizados | Actualización en tiempo real al emitirse cada evento |
| Historial de soporte | Fragmentado entre sistemas; difícil de auditar | Registro inmutable con toda la línea de tiempo del caso |
| Escalabilidad en picos | Limitada por la base de datos transaccional y los límites de API | Servicios y consumidores se replican horizontalmente |
| Confiabilidad de notificaciones | Depende de cron jobs o envíos manuales | Colas durables e idempotencia evitan duplicados y pérdidas |
| Cambios y devoluciones | Actualizaciones directas con riesgo de estados inconsistentes | Comandos y eventos garantizan convergencia entre sistemas |
Con el estado unificado, el paso siguiente es coordinar IA, humanos y backend sin perder contexto. El punto ya no es solo saber qué pasó, sino decidir quién actúa y con qué contexto.
Desde ese punto, el problema deja de ser el estado y pasa a ser la coordinación. Cuando un bot de IA, un agente humano y varios sistemas backend meten mano sobre el mismo pedido desde una sola charla de WhatsApp, el riesgo es claro: que se pisen entre sí. Ahí el desafío ya no es solo leer bien el estado, sino definir quién actúa y cuándo.
Un cambio por WhatsApp no es un solo movimiento. Dispara una cadena: validación, posible interceptación logística, ajuste de importe, actualización de inventario y del pedido, y aviso al cliente.
El patrón Saga ordena esa cadena como una secuencia de transacciones locales, cada una con su evento de éxito o fallo. Si el ajuste de importe falla - por ejemplo, si el cargo adicional de $3.000 ARS es rechazado por la pasarela - , la Saga deshace los pasos previos y deja un solo estado consistente.
Lo mismo pasa con cancelaciones y devoluciones. Si el paquete ya salió, la Saga deriva el caso a una devolución post-entrega.
Cuando la Saga no logra cerrarse sola, el caso pasa a una persona con el mismo contexto.
La IA deriva cuando pierde confianza, cuando el monto en juego es alto o cuando el cliente muestra señales de frustración. En ese momento, emite AgentHandoffRequested con la conversación, el pedido, el motivo y el estado de la saga.
Después, un servicio de enrutamiento consume ese evento, aplica reglas de prioridad - como clientes VIP o pedidos de alto valor - y emite AgentAssigned. La conversación pasa a modo humano y se frenan las respuestas automáticas de la IA. El mismo historial de eventos que alimenta el estado viaja junto con el ticket. Burbuxa le pasa al agente humano el historial completo, el pedido y el motivo de derivación sin cortar el hilo de WhatsApp.
La diferencia se entiende mejor cuando se pone lado a lado la orquestación automática y la coordinación manual.
| Dimensión | Coordinación orientada a eventos | Coordinación manual |
|---|---|---|
| Pasos del flujo | Sagas automáticas con disparadores por evento | El agente actualiza cada sistema a mano |
| Visibilidad | Tablero en tiempo real con trazabilidad completa | Fragmentada entre pestañas, mails y planillas |
| Riesgo de inconsistencia | Bajo: idempotencia y compensaciones mantienen la consistencia | Alto: estados divergentes entre pedidos, pagos y logística |
| Velocidad de respuesta | Inmediata o en segundos | Limitada por disponibilidad del agente |
| Experiencia en WhatsApp | Actualizaciones claras, sin repetición de datos | Mensajes contradictorios, esperas largas, cliente repite todo |
Para que esta coordinación pueda crecer sin volverse un caos, hace falta una base de eventos confiable.
Para que esa coordinación funcione en producción, hay una base mínima que no se puede saltear: un receptor de webhooks, una cola durable, workers asincrónicos, un historial unificado de conversaciones y observabilidad. Sobre esa base se apoyan los flujos de estado, cambios, devoluciones y notificaciones. Así, WhatsApp puede confirmar rápido y resolver el resto en segundo plano.
El patrón outbox guarda la actualización del negocio y el evento dentro de la misma transacción. Después, el broker publica ese evento. Dicho simple: evitás que una cosa sea la que ve el cliente y otra muy distinta la que queda registrada.
El orden por order_id evita que los eventos entren fuera de secuencia. Y la idempotencia hace que procesarlos más de una vez no rompa nada. Eso pesa mucho cuando hay reintentos o reentregas de webhooks, porque evita duplicados molestos, como tu pedido fue enviado, o algo peor: reembolsos dobles.
Los reintentos con espera exponencial sirven para fallas transitorias. Las DLQ separan los mensajes que siguen fallando. Conviene mirar de cerca tres métricas:
Con esta base, el soporte deja de depender de decisiones manuales y pasa a moverse con reglas claras y consistentes.
El problema de fondo no está en responder, sino en coordinar. Microservicios y eventos permiten escalar soporte, mantener trazabilidad y alinear IA, humanos y backend dentro del mismo contexto. CQRS, event logs, Sagas, outbox e idempotencia no son teoría linda en un diagrama: son las piezas que hacen que todo funcione en producción.
En Burbuxa, eso baja a tierra de forma directa. Se traduce en sincronización en tiempo real de pedidos, inventario y conversaciones, para que IA y humanos trabajen sobre el mismo estado.
Conviene cuando necesitás que el soporte por WhatsApp responda a cambios reales del journey: estados de pedidos, devoluciones, reembolsos y eventos de contacto. También suma cuando querés coordinar sistemas y medir todo con eventos estandarizados e IDs unificados.
En la práctica, esto suele apoyarse en webhooks para recibir actualizaciones en tiempo real. Después, se completa con reconciliaciones por polling y manejo de eventos fallidos con DLQ para no perder datos cuando la operación crece.
No hace falta frenar la operatoria diaria. El sistema se integra de forma nativa con tu tienda y sincroniza catálogos, pedidos y clientes en tiempo real, sin necesidad de programar nada.
Para que todo siga en marcha, la IA trabaja con supervisión. Te sugiere acciones, pero los cambios críticos quedan sujetos a tu aprobación. Al mismo tiempo, las automatizaciones basadas en eventos corren solas, y tu equipo entra en juego solo en casos más complejos, con todo el contexto del cliente a mano.
Pueden desincronizar el sistema: repetir acciones, generar inconsistencias de inventario o enviar mensajes en el momento equivocado.
Para evitarlo, usá idempotencia: procesá cada evento una sola vez según su ID. Además, trabajá con un esquema de entrega “al menos una vez”.
Como los webhooks pueden reintentarse o llegar con demora, también conviene sumar polling periódico y una Dead Letter Queue para los eventos que fallen.