Si yo integro WhatsApp con un CRM para soporte, el punto no es solo responder mensajes: es lograr que cada mensaje termine en una sola acción clara y trazable.
En esta guía, el foco está en cuatro cosas: validar webhooks, identificar bien al cliente, usar el contexto justo y decidir si corresponde responder, actualizar un ticket o derivar a una persona. Si una de esas piezas falla, aparecen problemas comunes: tickets dobles, respuestas fuera de tiempo, historiales cortados y agentes que arrancan sin contexto.
Dicho simple, el flujo sano se ve así:
Hay dos reglas que ordenan todo:
También hay controles que no puedo saltear:
Un buen criterio de revisión es este: si el cliente pregunta “¿Dónde está mi pedido?” el sistema debería responder o abrir el caso en segundos, con historial, pedido y motivo ya vinculados. Si el agente después tiene que pedir todo de nuevo, el flujo quedó corto.
Dato simple pero útil: en este tipo de integración, buena parte de los errores no aparece al enviar mensajes, sino al IDs, estados y tickets entre sistemas. Por eso conviene medir, como mínimo, duplicados, latencia del webhook, cumplimiento de SLA y porcentaje de derivaciones donde el cliente repite información.
La idea del artículo es bajar todo eso a tierra con un esquema simple, en español rioplatense, usando fechas como 23/09/2026, horario 14:30 y montos como $ 25.000,00.
Implementación Frágil vs. Confiable: WhatsApp API + CRM
Antes de integrar, conviene dejar en orden IDs, credenciales y permisos. No arranques con tokens temporales: vencen en 24 horas y después te fuerzan a tocar producción otra vez. La integración, además, tiene que poder vincular cada mensaje con un contacto, una conversación y un ticket dentro del CRM.
La base mínima pide un Meta Business Portfolio verificado, una app de Meta con WhatsApp habilitado y un número exclusivo para la API. Ese número no puede usarse al mismo tiempo en la app móvil de WhatsApp.
De esa configuración salen dos IDs que vas a usar todo el tiempo:
En permisos, la integración necesita whatsapp_business_messaging y whatsapp_business_management. Ya en producción, el token temporal se tiene que cambiar por un token de usuario del sistema, guardado en un gestor de secretos. Nunca en el código fuente. Nunca en logs.
Del lado del CRM, suma crear un rol aparte para la integración, con acceso solo a lo justo: crear y actualizar contactos, conversaciones, mensajes y tickets, sin abrir permisos administrativos generales. Y si trabajás con stacks de e-commerce como Shopify, Tiendanube o VTEX, lo mejor es usar credenciales separadas y permisos limitados sobre pedidos, clientes e inventario, solo si el flujo necesita, por ejemplo, cancelar pedidos.
Checklist mínima:
| Componente | Identificador / Credencial |
|---|---|
| Meta Business Portfolio | Portfolio ID |
| App de Meta | App ID + App Secret |
| Cuenta de WhatsApp Business | WABA ID |
| ID del número de teléfono | Phone Number ID |
| Token de sistema | Token de sistema (producción) |
| Webhook | URL HTTPS + Verify Token |
| CRM | Credenciales del CRM |
| Plataforma de e-commerce | Credenciales o token de acceso acotado |
Con estas credenciales listas, el próximo paso es recibir y procesar eventos sin trabar el flujo.
Cuando entra un mensaje, Meta publica un evento en el webhook. La integración valida que la solicitud sea legítima, registra el evento y responde con HTTP 200 de inmediato. Todo lo pesado - consulta de pedidos, clasificación del mensaje, armado de respuesta - corre en segundo plano, de forma asíncrona.
Después, el sistema normaliza el número a E.164. En Argentina, eso implica usar el prefijo +54. Con ese dato, busca al cliente en el CRM. Si ya existe un contacto, recupera tickets abiertos, historial reciente y datos del pedido o envío asociado. Si no encuentra coincidencia, crea un contacto mínimo.
Con ese contexto, la automatización toma una decisión: responder sola, actualizar un ticket existente o abrir uno nuevo. Si el caso no se puede resolver, lo manda a una cola humana con todo el historial ya cargado. Así el equipo no arranca de cero ni pierde tiempo buscando contexto.
Con la arquitectura ya definida, el foco pasa al webhook y al manejo del evento entrante.
Responsabilidades por capa:
| Responsabilidad | WhatsApp / Meta | Capa de integración | CRM | Equipo de soporte |
|---|---|---|---|---|
| Autenticación | Aloja la cuenta, el número y la app | Almacena y usa tokens; valida el webhook | Provee credenciales y políticas de roles | Usa autenticación individual por agente |
| Entrega de mensajes | Transporta mensajes entrantes y salientes | Convierte, encola, reintenta y correlaciona eventos | Guarda historial y estados | Revisa conversaciones y envía respuestas humanas |
| Datos del cliente | Provee identificadores de remitente | Normaliza IDs y mapea identificadores externos | Mantiene el perfil e historial de interacciones | Corrige datos cuando el cliente los confirma |
| Propiedad del ticket | No gestiona tickets | Aplica reglas de enrutamiento y sincroniza estados | Dueño del estado, prioridad, cola, SLA y auditoría | Acepta, trabaja, escala y cierra tickets |
| Respuestas humanas | Entrega el mensaje final al cliente | Aplica plantillas y reintentos de entrega | Registra la respuesta contra el caso | Redacta o aprueba respuestas y toma la conversación |
Hay una idea que conviene dejar grabada desde el arranque: WhatsApp transporta mensajes; el CRM guarda el estado. Mezclar esos papeles es uno de los errores de arquitectura más comunes. Y, peor todavía, uno de los más caros de arreglar cuando el sistema ya está en marcha. Desde ese punto, lo crítico pasa por verificar, encolar y responder sin demoras.
Cuando entra un mensaje, el sistema primero lo valida. Recién ahí decide qué hacer. Todo arranca en el webhook.
La verificación inicial es directa: Meta manda un GET con hub.mode, hub.verify_token y hub.challenge. El endpoint valida el modo, compara el token y responde con hub.challenge usando HTTP 200.
Para los eventos POST, validá la firma sobre el cuerpo crudo con HMAC-SHA256 y compará el resultado con el encabezado X-Hub-Signature-256. Si no coincide, rechazá la solicitud y registrá el intento y seguí estos consejos para depurar integraciones API.
Después, persistí el evento, encolalo y respondé HTTP 200 al instante. El resto corre en workers. Ese flujo pide un registro mínimo que sirva para deduplicar, auditar y vincular cada mensaje con su ticket.
Guardá secretos y credenciales en un gestor seguro o en variables protegidas.
Con el webhook validado, el foco cambia: qué guardar para reconstruir cada interacción sin perder el orden.
WhatsApp entrega eventos. El CRM guarda el estado operativo. Por eso, cada evento tiene que escribir un registro con los campos que marcan deduplicación, trazabilidad y vínculo con el ticket.
| Campo | Descripción |
|---|---|
event_key | Clave única por evento; base para deduplicación |
received_at | Fecha y hora de recepción en UTC |
provider_message_id | ID de mensaje de WhatsApp |
event_type | Tipo de evento (messages, statuses, etc.) |
processing_status | Estado del procesamiento y cantidad de intentos |
conversation_id | ID de conversación en el CRM; evita que mensajes del mismo cliente abran tickets sin relación entre sí |
ticket_id | Ticket vinculado al evento |
direction | Entrante o saliente |
La tabla de eventos y sus acciones en el CRM queda así:
| Evento de webhook | Acción en el CRM |
|---|---|
messages entrante | Crear o actualizar contacto, guardar mensaje, vincular a conversación y aplicar la regla de apertura de ticket |
Estado sent | Marcar el mensaje saliente como enviado con timestamp de confirmación |
Estado delivered | Actualizar la entrega del mensaje |
Estado read | Marcar como leído y actualizar la actividad de la conversación |
Estado failed | Registrar el error, aplicar reintento controlado o derivar a una incidencia técnica |
| Actualizaciones de plantilla | Actualizar estado y calidad; bloquear el uso si fue rechazada o degradada |
| Salud del canal | Actualizar el estado del número y alertar a operaciones si hay riesgo de restricción |
Con esa base, el siguiente punto es evitar dobles registros y eventos fuera de orden.
Meta garantiza entrega al menos una vez. En la práctica, eso quiere decir que un mismo evento puede llegar más de una vez. La salida más simple es una restricción única en base de datos sobre event_key. Si el worker intenta insertar una clave que ya existe, descarta el evento sin abrir otro ticket ni dejar actividad duplicada.
El CRM también tiene que respetar la secuencia sent → delivered → read. No debería retroceder el estado por culpa de un evento anterior que llegó tarde.
Si los timestamps se contradicen, guardá ambos eventos en la línea de tiempo y marcá el registro para revisión. Y si un evento agota sus intentos, mandalo a una cola de excepción con alerta y reprocesamiento manual.
Con los eventos persistidos y ordenados, el paso siguiente es identificar al cliente y recuperar contexto antes de responder.
Antes de responder cualquier mensaje, el sistema tiene que saber con exactitud con quién está hablando. La base para esa búsqueda es el número normalizado. El número original conviene guardarlo por separado para auditoría.
La búsqueda en el CRM tiene que seguir un orden claro de confianza. Primero, el identificador de WhatsApp que llega desde la API y el teléfono normalizado. Después, el ID de la cuenta o el número de WhatsApp Business. Recién al final, los identificadores internos del CRM o de la tienda.
Si dos registros coinciden con el mismo número, no hay que fusionarlos de forma automática. En ese caso, corresponde crear un registro provisional y mandar el caso a revisión manual. Un nombre o una dirección escritos en el mensaje no alcanzan para probar identidad. Tampoco hay que sobrescribir datos ya confirmados con texto libre sin verificar antes al cliente.
Cada fusión tiene que dejar traza de auditoría: los registros involucrados, la regla aplicada, la fecha y hora, y los valores anteriores y posteriores.
Con el contacto ya resuelto, el paso siguiente es traer solo los datos que hacen falta para responder.
Recuperá únicamente el contexto necesario para resolver la consulta. Ni más ni menos.
El contexto mínimo incluye:
Si el cliente escribe ¿Dónde está mi pedido?, el sistema tiene que buscar el pedido activo del contacto verificado, el estado del envío, el último evento de tracking y cualquier ticket de entrega que siga abierto. Si aparecen pedidos o identidades en conflicto, lo correcto es hacer una pregunta de aclaración o derivar el caso a una persona.
Un campo clave que el CRM debe calcular y mostrar de forma explícita es service_window_expires_at. Esa marca de tiempo indica cuándo vence la ventana de 24 horas desde el último mensaje entrante del cliente. Mientras esa ventana siga activa, se puede responder con texto libre. Cuando vence, la empresa tiene que usar una plantilla aprobada para retomar el contacto. Esta reactivación es el punto de partida para ejecutar campañas efectivas en WhatsApp que mantengan el interés del usuario. Cada nuevo mensaje del cliente reinicia el contador, y este campo debe basarse en el timestamp del evento de plataforma, no en el momento en que se procesó el webhook.
Con el contexto ya listo, Burbuxa puede responder o derivar sin perder el hilo.
El flujo es directo: identidad verificada → contexto acotado → respuesta o handoff. El CRM le pasa a Burbuxa un paquete corto con la identidad verificada, el ticket activo, el estado del pedido, la ventana de atención y el consentimiento. A partir de ahí, Burbuxa consulta contexto en tiempo real y ejecuta respuestas o acciones desde Shopify, Tiendanube o VTEX.
Cuando la identificación tiene baja confianza o el caso es sensible, Burbuxa frena la automatización y deriva el caso con el resumen y el ticket ya cargados. En paralelo, el CRM registra el mensaje entrante, la respuesta, la clasificación y el resultado de la derivación.
Con el cliente ya identificado y el contexto ya cargado, el sistema tiene que decidir qué mandar, cuándo abrir un ticket y cuándo pasar el caso a una persona.
Antes de cada envío, el CRM valida si la ventana sigue abierta. Si está activa, puede usar texto libre. Si ya venció, tiene que usar una plantilla aprobada.
Para bajar errores, conviene manejar un catálogo versionado con, como mínimo, estos campos: template_name, language_code, category, version, approval_status, rejection_reason, allowed_variables y last_updated_at. Ojo con esto: la aprobación puede demorar hasta 24 horas, así que no te apoyes en una plantilla recién enviada si el flujo es crítico.
Antes de completar una plantilla, el sistema tiene que revisar que todas las variables estén y que además tengan el formato correcto. Un ejemplo en es-AR sería este: Tu pedido #45821 fue despachado el 23/09/2026 a las 14:30. Importe: $ 25.000,00. Si una plantilla fue rechazada o quedó pausada, hay que registrar el motivo, usar una alternativa de respaldo ya aprobada y, si no existe una opción válida, crear una tarea de revisión manual. Lo que no hay que hacer es cambiarla de categoría de forma automática para esquivar la clasificación.
Con los tickets, la lógica tiene que ser simple y firme. Antes de crear uno nuevo, el sistema revisa si ya existe un caso abierto con la misma combinación de customer_id, conversation_id, intent y, cuando haga falta, order_id. Si ya existe, suma el mensaje como evento y actualiza el ticket. Si no existe, crea uno nuevo con categoría, prioridad, SLA, cola, responsable, canal de origen: WhatsApp API e identificador del mensaje. Los SLA tienen que definirse según el calendario real de atención en Argentina, con diferencia entre horas hábiles, feriados y atención fuera de horario. El cierre solo debería ocurrir cuando se cumpla una condición explícita: resolución confirmada, falta de respuesta según la política interna o cierre manual por parte de un agente, siempre con el motivo registrado.
Cuando la automatización no alcanza, el contexto no puede perderse en el camino. Tiene que llegar completo al agente.
El paquete de derivación reúne seis bloques: cliente (ID, nombre, teléfono normalizado, consentimiento y segmento), conversación (últimos mensajes, marcas de tiempo, idioma y ventana de atención), diagnóstico (resumen, intención detectada, nivel de confianza y motivo del escalamiento), comercio (pedido, estado, importe - por ejemplo, $ 25.000,00 - , envíos y reclamos previos), ticket (ticket_id, categoría, prioridad, SLA, cola y estado) y controles (consentimiento, restricciones de privacidad y trazabilidad). Sin ese paquete, pasa lo de siempre: el agente pierde tiempo y el cliente tiene que repetir todo.
Los modos de resolución marcan cuándo entra una persona y de qué manera:
| Modalidad | Cuándo usarla | Acción del sistema | Resultado esperado |
|---|---|---|---|
| Automática | Intención conocida, datos completos y confianza alta | Responder, consultar sistemas autorizados, ejecutar acciones de bajo riesgo y registrar | Caso resuelto sin agente |
| Asistida | Intención probable, pero requiere validación o una acción sensible | Preparar respuesta, reunir datos, crear o actualizar el ticket y proponer solución | Agente valida y envía |
| Derivación humana inmediata | Baja confianza, reclamo sensible, fraude, enojo persistente, pedido de alto valor o solicitud explícita de una persona | Bloquear automatizaciones, priorizar el ticket y transferir contexto | El agente toma el control |
Cuando un caso necesita escalamiento, Burbuxa frena la automatización y deriva con el historial completo y los datos comerciales ya cargados - pedidos, estados y políticas - desde Shopify, Tiendanube o VTEX. A la vez, el CRM recibe el evento de escalamiento, bloquea respuestas automáticas duplicadas y confirma que un agente aceptó el caso antes de seguir.
Antes de salir a producción, hay que probar el flujo en serio. No alcanza con ver si “anda”. Tiene que aguantar errores, reintentos y duplicados.
Primero, revisá credenciales, permisos, el número de WhatsApp, las URLs de webhook, la firma y la validación de eventos. Después, cubrí los casos que suelen romper todo si nadie los prueba a tiempo:
También conviene sumar escenarios en español rioplatense con números +54, fechas 23/09/2026, horarios 14:30 y montos como $ 25.000,00. Y sí, también los casos incómodos: baja confianza, fraude, reclamo legal, pedido de atención humana y saturación de agentes.
Ante fallos, la lógica tiene que ser clara: reintentos limitados con espera progresiva, clave de idempotencia en cada envío y cola persistente. Si falla WhatsApp, el mensaje queda pendiente o fallido y dispara una alerta. Si se cae el CRM, el webhook queda en cola para reprocesamiento. Si falla la consulta de pedidos, el usuario recibe una respuesta segura: Estamos verificando la información; un agente va a continuar el caso, sin inventar datos. Si la ventana de atención está cerrada y no hay una plantilla aprobada disponible, el sistema registra el bloqueo y ofrece un canal alternativo autorizado.
Después del lanzamiento, el tablero tiene que agrupar las métricas en siete bloques: resolución (porcentaje automático, asistido y derivado), derivación (porcentaje de clientes que repiten información después del handoff y tiempo hasta la asignación), SLA (cumplimiento por categoría, prioridad, cola y horario), plantillas (tasa de aprobadas, rechazadas, pausadas y bloqueadas por ventana cerrada), duplicados (tickets duplicados y mensajes procesados más de una vez), disponibilidad (uptime de webhooks y latencia de respuesta) y cola (tamaño y antigüedad del evento pendiente más antiguo).
Además, cada acción automatizada tiene que dejar rastro. El registro de auditoría debe guardar fecha y hora en formato de 24 horas, correlation_id, customer_id, ticket_id, regla aplicada, variables completadas, resultado, reintentos y responsable.
Después de webhooks, identificación, contexto, plantillas y tickets, cada mensaje tiene que terminar en un solo resultado auditable.
Ahí está la línea que separa un flujo frágil de uno que funciona bien de verdad: cómo resuelve fallas, cómo usa el contexto y cómo hace la derivación.
| Aspecto | Implementación frágil | Implementación confiable |
|---|---|---|
| Webhook | Responde en línea | Valida, confirma y encola |
| Reintentos | Trata duplicados como errores | Asume duplicados y usa idempotencia |
| Cliente | Crea un contacto por conversación | Normaliza, busca coincidencias y evita duplicados |
| Contexto | Responde con el último mensaje | Consulta pedido, historial y tickets abiertos |
| Plantillas | Se reutilizan sin control | Se versionan según ventana y propósito |
| Tickets | Se crea uno por mensaje | Se aplican reglas de prioridad, agrupación y SLA |
| Escalamiento | Envía la conversación sin explicación | Transfiere resumen, datos y próximo paso |
El criterio de aceptación más simple es este: cada mensaje entrante debe tener exactamente un resultado auditable - resolución automática, creación o actualización de ticket, o escalamiento explícito - .
La derivación debe sumar criterio, no reiniciar la conversación.
En la práctica, esto baja a tierra una idea muy simple: la persona que toma el caso tiene que poder actuar en el momento, con el historial y el motivo del escalamiento ya preparados. Si ese agente tiene que volver a pedir contexto, el flujo todavía falla donde más importa.
La trazabilidad es la pieza que ordena todo. Es lo que deja resolver rápido, bancarse el volumen y evitar que un evento duplicado rompa el caso.
Anclá cada conversación y cada pedido al mismo cliente y a un solo contexto dentro del CRM o del inbox compartido: misma conversación, mismo contacto, misma tienda y mismos datos de compra.
En otras palabras: si una persona vuelve a escribir, el sistema no tendría que abrir caminos paralelos ni mezclar datos. Todo tiene que quedar unido al mismo hilo para que el equipo vea el historial completo y actúe con contexto.
También conviene asegurar que la derivación a una persona no reinicie el flujo. Si el caso pasa de automatización a atención humana, la conversación debería seguir desde el mismo punto, sin perder mensajes, estado ni datos cargados.
Además, sumá repeat guards por cliente o por orden, definí reglas de estado y validá los datos importados o externos antes de crear el ticket.
Eso ayuda a evitar problemas bastante comunes, como:
Dicho simple: primero ordená la identidad del cliente y el contexto de la conversación; después, recién ahí, dejá que el sistema cree o derive casos.
Si se vence la ventana de 24 horas de WhatsApp, la charla directa queda limitada. Aun así, Burbuxa mantiene la continuidad desde su CRM unificado, con el historial, los pedidos y las notas del cliente dentro del mismo registro.
Cuando el equipo humano vuelve a tomar la conversación, entra con todo el contexto a mano. El cliente no tiene que repetir lo que ya dijo, ni volver a explicar su caso desde cero. Así, las dudas y los tickets se resuelven de forma ágil y sin idas y vueltas.
Conviene pasar la conversación a un agente humano cuando el caso se complica, hace falta criterio personal, la consulta se sale de las reglas de automatización o el cliente directamente pide hablar con una persona.
Con Burbuxa, ese pase se hace al instante y con todo el contexto del cliente. Así, el agente puede retomar la charla sin volver al punto de partida.
