Para un chatbot de ecommerce, mi punto de partida es este: consultar la tienda, verificar al cliente y controlar cada acción antes de ejecutarla. Atender las 24 horas no sirve si el bot informa mal el stock o confirma un cambio que no hizo.
En esta guía, te muestro cómo organizo el sistema:
Mi criterio para salir a producción: <u>cada control debe pasar sus pruebas</u>. Una demo que funciona no alcanza.
Arquitectura de chatbot para ecommerce: flujo seguro
Los canales reciben y emiten mensajes. El backend normaliza los eventos, los guarda y decide qué hacer. Normalizá cada evento antes de pasarlo al motor de diálogo.
Webhook de WhatsApp / Instagram
↓
Validación de firma + normalización + limitación de tasa
↓
Persistencia duradera + ACK inmediato + cola de entrada
↓
Procesamiento y acciones idempotentes
↓
Cola de salida → Adaptador del canal → Cliente
↑
Webhooks de estado → Registro de entrega
Una vez definido el flujo, aplicá estos requisitos a cada canal para evitar diferencias de implementación.
En WhatsApp, configurá la WABA, el número comercial, los tokens y los webhooks. Verificá que el número no tenga otro uso incompatible y completá las aprobaciones necesarias.
En Instagram, verificá la cuenta profesional, la autorización y los permisos del flujo elegido. Instagram Login no siempre requiere una página de Facebook vinculada. Antes del lanzamiento, comprobá los requisitos en la documentación vigente de Meta.
| Aspecto | WhatsApp Business Platform | Instagram Messaging |
|---|---|---|
| Eventos entrantes | Mensajes, estados de entrega y eventos de cuenta suscriptos. | Mensajes y otros eventos habilitados para la integración. |
| Reglas de salida | Ventana de atención de 24 horas; fuera de ella, plantilla aprobada y consentimiento aplicable. | Ventana estándar de 24 horas, con los permisos y límites aplicables. No permite iniciar mensajes sin límites. |
| Archivos | Validar tipo, tamaño e identificador del archivo. | Validar formatos y restricciones del endpoint antes del envío. |
| Identidad del canal | Conservar WABA ID, phone-number ID e identificador del cliente. | Conservar la cuenta profesional y el identificador del usuario dentro de Instagram. |
| Intervención humana | Pausar el bot sin saltearse las reglas de envío. | Asignar la conversación a una bandeja autorizada y mantener la derivación humana sin reactivar la automatización. |
Cada mensaje iniciado por el cliente vuelve a abrir la ventana de atención. Calculala antes de enviar, no solo al generar la respuesta. Guardá el nombre, idioma, categoría y variables de cada plantilla aprobada. Si no hay una plantilla válida, bloqueá el envío y generá una tarea de revisión.
En Instagram, mantené una matriz de capacidades por cuenta y endpoint que detalle los permisos, los archivos admitidos y los límites.
Con los permisos y las ventanas definidos, pasá al evento canónico: esta capa convierte los mensajes en eventos idempotentes antes de procesarlos.
El evento canónico debe incluir event_id, event_type, channel, account_id, conversation_id, los identificadores del usuario y del mensaje, contenido, adjuntos, fecha, referencia de consentimiento y, cuando corresponda, estado de entrega. Conservá también el payload original, sin transformar. Guardá las fechas en UTC y mostralas en horario local:
2026-10-10T21:30:00Zcorresponde a 10/10/2026 18:30 en Argentina.
Para cada adjunto, registrá el tipo MIME, el tamaño, la ubicación y el estado del análisis de seguridad.
Verificá la firma y el origen del evento, validá el esquema y guardalo de forma duradera antes de confirmar la recepción. Una tabla inbox con claves únicas y una outbox transaccional permiten publicar en la cola sin perder eventos entre pasos. El webhook no debe esperar al modelo ni a la tienda.
Deduplicá por identificador del proveedor, ordená los eventos por conversación y hacé que las acciones sean idempotentes. Ante fallas transitorias, reintentá con una espera creciente y variación aleatoria. Definí un máximo de intentos y un tiempo total; cuando se agoten, enviá el caso a una dead-letter queue.
Registrá los estados enviado, entregado, leído y fallido, sin retroceder por eventos tardíos. Que una API acepte el envío no confirma la entrega.
Una vez normalizados los eventos, definí qué entiende el bot, qué consulta y qué puede ejecutar. Separá comprensión, consulta y ejecución. El motor de diálogo detecta la intención y los datos que faltan. La capa de consulta recupera información aprobada y datos de la tienda. La capa de acciones ejecuta solo operaciones autorizadas. El modelo propone; las reglas ejecutan.
Definí reglas verificables para dirigir las consultas a ventas o soporte. Usá un solo agente si ambos comparten permisos y reglas; separalos solo cuando cambien las herramientas, las aprobaciones o los responsables. Ambos deben consultar los mismos datos autorizados. Mantené al responsable asignado hasta cerrar la consulta. Si aparece un reclamo, derivá y congelá el estado.
Pedí solo los datos necesarios para resolver cada consulta. Usá guías y políticas aprobadas y versionadas, y consultá las API para obtener precios, stock y estado del pedido. Limitá las herramientas y los reintentos según la intención. Si falta un dato, preguntá. Si hay información contradictoria o falla la consulta, no inventes una respuesta: derivá.
Después de detectar la intención, definí qué contexto guardar y qué identidad verificar antes de usar datos personales.
Separá el contexto del turno, el estado de la sesión y el historial del cliente. Guardá las preguntas pendientes, las referencias de pedidos, el consentimiento, el responsable y la caducidad de cada dato. Si aparecen cambios contradictorios, registrá la fuente y confirmá lo necesario antes de actuar.
No vincules identidades de WhatsApp e Instagram por nombre o coincidencias. Exigí una verificación antes de vincular historiales o recuperar pedidos. Aislá la memoria por tienda y cliente verificado.
Con el contexto y la identidad resueltos, alineá la base de datos con la tienda, sin crear otra fuente de verdad comercial.
Mantené registros separados de clientes, identidades de canal, mensajes, estado del diálogo, referencias de catálogo, pedidos, consentimientos, versiones de conocimiento, aprobaciones y auditoría. La tienda es la fuente de verdad para precio, stock y pedido. La base solo guarda copias en caché con vigencia definida. Registrá la fecha de actualización y el límite de vigencia de cada dato.
Revalidá precio y stock antes de avanzar al checkout. Reconciliá los eventos periódicamente para detectar faltantes. Burbuxa describe su Commerce Brain como una capa de agentes y automatizaciones con datos compartidos e integraciones nativas con Shopify, Tiendanube, VTEX y WooCommerce. Verificá qué entidades sincroniza cada integración, con qué demora y cómo resuelve los conflictos.
Una vez resuelto el contexto, definí qué puede ejecutar el bot. Exigí propuestas estructuradas que incluyan acción, parámetros tipados, referencia del cliente, motivo y nivel de confianza. Todas deben pasar por un validador determinista: el modelo propone, el validador autoriza, la API ejecuta.
El validador debe autenticar el canal y al cliente, identificar la tienda correcta, comprobar el esquema y los rangos de parámetros, y verificar la titularidad y el estado vigente. Con esos controles, decide si ejecutar, pedir datos, solicitar aprobación, derivar o rechazar. Definí contratos de API autenticados y versionados para catálogo, carritos, clientes, pedidos, envíos, descuentos, devoluciones y reembolsos. Cada herramienta debe tener permisos mínimos, con las credenciales fuera del contexto del modelo. OWASP advierte sobre el exceso de permisos y autonomía.
Revalidá elegibilidad, precio, stock y parámetros justo antes de ejecutar. Guardá una clave de idempotencia para cada modificación y registrá la versión de política, la decisión, el responsable, la fecha y el ID externo de la operación. Un timeout no confirma que la operación falló: marcala como unknown, consultá su estado y no la repitas a ciegas. En WhatsApp, registrá por separado la entrega del mensaje y la confirmación de la acción comercial.
| Acción | Ejecución automática | Pedir aprobación o derivar | Rechazo seguro |
|---|---|---|---|
| Consultar pedido | Vínculo verificado con el pedido; solo lectura | Identidad dudosa, pedido con datos sensibles o referencia ambigua | Sin vínculo verificado |
| Modificar carrito | Cliente autenticado y cambio válido con precio aceptado | Valor o cantidad fuera de límites, o fallas repetidas | Sin stock o parámetros inválidos |
| Cancelar pedido | Pedido pago, sin preparación iniciada y elegible; identidad verificada | Preparación iniciada o excepción de política o importe | Entregado, restringido o inelegible |
| Reembolsar | Motivo aprobado, importe dentro del límite y elegibilidad confirmada | Excepción de importe, disputa, posible fraude o pago incierto | Motivo inválido, duplicado o pago incompatible |
| Cambiar domicilio | Cliente verificado, pedido sin despachar y dirección validada con envío recalculado | Despacho inminente, riesgo alto o identidad inconsistente | Ya enviado o dirección no validable |
| Aplicar descuento | Cupón publicado válido y condiciones cumplidas | Cortesía o excepción de vigencia, acumulación o importe | Conflicto con la promoción o precio negativo |
Definí disparadores concretos para la intervención humana: fallas de identidad, sospecha de fraude, incertidumbre sobre el pago o la API, excepciones de política, amenazas de acción legal, riesgos de seguridad, frustración repetida del cliente, datos regulados o sensibles y pedidos fuera de la base de conocimiento aprobada. Usá estados explícitos: automatización, faltan_datos, pendiente_aprobación, asignado, en_progreso, resuelto y retorno_a_automatización.
Cada cola debe tener un responsable y un plazo de atención. Priorizá las fallas de pago y los cambios antes del despacho; las consultas de producto no urgentes pueden tener un plazo más largo.
Al derivar, transferí un paquete de caso compacto y auditable. Incluí la identidad verificada y el método usado, el consentimiento y el estado del canal, un resumen de la conversación y los fragmentos relevantes. Sumá la intención actual, las referencias de pedido o carrito, los datos recuperados de la tienda, las acciones intentadas, las respuestas de la API y los controles de política. También deben quedar registrados el motivo de la derivación, la urgencia, el SLA y las promesas ya realizadas.
Pausá las respuestas automáticas durante la atención humana. Retomalas solo cuando la persona responsable cierre el caso sin pendientes.
La aprobación debe dejar constancia de quién aprobó, qué cambio autorizó, hasta cuándo tiene vigencia y qué versión de política se aplicó. Revalidá las condiciones antes de ejecutar: si el pedido cambió o la autorización venció, pedí otra aprobación. Verificá los permisos y las acciones disponibles en la documentación, el contrato y las pruebas. Implementar rápido no garantiza seguridad.
La derivación también debe coordinarse con las reglas de retención, el monitoreo y el despliegue por etapas.
Aplicá roles de mínimo privilegio, almacenamiento separado de secretos, cifrado, registros con datos sensibles ocultos y entornos de prueba aislados con datos sintéticos. Definí las reglas de retención, eliminación, consentimiento y baja de comunicaciones. No guardes datos sensibles innecesarios en las auditorías.
Tratá los mensajes, archivos y datos recuperados como datos no confiables. Validá fuera del modelo tanto los datos que devuelven las herramientas como las acciones propuestas. Bloqueá las acciones no permitidas y las afirmaciones sin respaldo, y limitá los intentos abusivos. Para los pagos, dirigí al cliente a un checkout seguro: no pidas tarjetas ni credenciales bancarias por chat.
Antes del lanzamiento, revisá con asesoría legal la Ley N.º 25.326. Documentá proveedores, hosting, subencargados, finalidades, retención, derechos de acceso y corrección, y mecanismos de transferencia.
Estos controles deben estar definidos antes de las pruebas de falla, el monitoreo y el despliegue gradual.
Con los permisos y controles definidos, validá el lanzamiento, la resiliencia y los costos antes de escalar.
Armá una ficha para cada intención prioritaria. Incluí datos, responsable, contrato de API, permisos, umbral de aprobación, derivación y SLA. Definí tres criterios de evaluación: funcionamiento, resiliencia y resultado comercial de la automatización. Una demo solo valida el funcionamiento.
Usá esa ficha para liberar cada intención por etapas. Primero, probá en un entorno aislado. Después, habilitá producción con acceso limitado: empezá con respuestas aprobadas, seguí con consultas de pedidos con identidad verificada y, recién entonces, incorporá acciones de bajo riesgo y operaciones con aprobación humana.
Avanzá solo si cada etapa pasa sus pruebas y cuenta con un mecanismo para desactivarla sin interrumpir la atención humana. Pedí resultados de pruebas, no solo una lista de funciones.
Forzá fallas reales: eventos duplicados o fuera de orden, stock desactualizado, caídas de API, cortes de canal y picos de tráfico. Probá también la derivación humana. Documentá el resultado esperado y exigí idempotencia y ausencia de confirmaciones falsas.
Ante una falla, la respuesta segura debe reconocer el problema sin prometer un resultado. Cada alerta necesita un responsable y una salida definida: reintento controlado, derivación o desactivación de la función afectada.
Monitoreá profundidad de cola, latencia, errores de API, precisión de respuestas, acciones completadas, derivaciones, reaperturas y satisfacción. Como objetivos iniciales - no como garantías - , podés usar una primera respuesta en menos de 2 minutos, escalado a los 5 minutos y CSAT > 4,5/5, con revisión semanal.
Medí la resolución automática sobre los casos elegibles y revisá si vuelven a abrirse. Para evaluar ventas, definí una ventana de atribución y un grupo de control: una compra posterior al chat no demuestra, por sí sola, que el bot la generó.
Si el costo no cierra, la arquitectura no escala. Presupuestá por separado suscripción, IA, mensajería, integración, infraestructura, monitoreo y tiempo humano. Incluí los cargos del proveedor y las tarifas vigentes sin duplicarlos.
Identificá los importes en USD y ARS. Para convertirlos, registrá el tipo de cambio, la fuente y la fecha en formato DD/MM/AAAA. Evitá precios sin fecha y ahorros no comprobados.
Calculá el costo por consulta resuelta mediante una plataforma de automatización con todos los gastos operativos y revisalo junto con las ventas incrementales para evaluar la viabilidad del sistema.
Usá esta lista para decidir si la arquitectura está lista para salir a producción.
Eventos y registro durable. Verificá que cada canal use un formato común, que los eventos se guarden antes del ACK y que haya idempotencia ante reintentos y mensajes fuera de orden.
Respuestas y memoria. Comprobá que las respuestas críticas se basen en la fuente vigente de la tienda. Definí cuánto tiempo se conserva la memoria, cuál es su alcance y cómo se borra.
Después, validá la identidad y el alcance del consentimiento.
Consentimiento y permisos. Confirmá que se verifique la identidad antes de acceder a información privada. Revisá el registro del consentimiento y su alcance, junto con los permisos y las aprobaciones de cada acción. El consentimiento no otorga permisos fuera de su alcance.
Supervisión y trazabilidad. Verificá que la derivación incluya la identidad verificada, el contexto, las aprobaciones pendientes y el resultado de cada acción. Los registros deben permitir reconstruir quién autorizó cada operación y qué datos se usaron.
Habilitá el despliegue recién cuando la derivación y la trazabilidad cumplan estos requisitos.
Aceptación del lanzamiento. Aprobá cada control solo con evidencia. Incluí fallas seguras, alertas activas y la posibilidad de intervención humana. Ampliá la automatización solo cuando todos los controles estén aprobados.
Enfocate en 2 o 3 objetivos clave. Para ventas, priorizá la recuperación de carritos y las recomendaciones personalizadas. Para soporte, apuntá a las consultas repetitivas y el seguimiento de pedidos. Empezá con tareas simples, como responder preguntas frecuentes o dar información sobre productos.
Cuando superes el 90 % de resolución automática y un CSAT de 4,0/5, sumá funciones avanzadas: procesamiento de pedidos, análisis de reseñas o campañas personalizadas. Mantené la supervisión humana para los casos complejos.
No hace falta separar a los agentes de ventas y soporte: Burbuxa reúne ambos roles en un solo sistema inteligente.
La automatización resuelve las tareas repetitivas. Cuando la IA detecta frustración, urgencia, un tono negativo o consultas que no puede resolver - como reclamos específicos o problemas de pago - , debés derivar la conversación a un agente humano. La transferencia mantiene el contexto y el historial, para que el cliente no tenga que repetir la información.
Revisá los abandonos y los casos que requirieron intervención humana. Si los indicadores salen de rango, revisá las reglas y los mensajes antes de escalar.
Monitoreá la profundidad de la cola, la latencia y la tasa de error. Ante fallas transitorias, aplicá reintentos con espera exponencial. Separá los mensajes fallidos en una Dead Letter Queue y usá identificadores únicos para evitar duplicados.
Validá los ajustes con tests A/B en grupos pequeños durante 2–4 semanas antes de implementarlos de forma gradual.