Cómo integrar la API de WhatsApp Business en retail y ecommerce: las decisiones de datos que se toman antes del primer mensaje

Este artículo es para quien va a montar o rehacer la integración de WhatsApp en una tienda con pedidos, catálogo y atención, en México o en cualquier operación que venda en línea y en piso. Al terminar vas a tener la lista de decisiones de datos que hay que cerrar antes de empezar, y las pruebas concretas que distinguen una integración que aguanta una temporada alta de una que se cae en la primera.

¿Qué tiene que conectar la integración, exactamente?

La respuesta corta son 7 cosas, y conviene escribirlas antes de elegir proveedor porque cada una vive en un sistema distinto y cada una tiene un dueño distinto dentro de la empresa.

Si alguno de esos 7 no está conectado, la integración funciona igual. Simplemente responde peor, y el síntoma no aparece el primer día: aparece semanas después, en forma de agente preguntando por el número de pedido que el cliente ya escribió tres mensajes antes.

Nótese una cosa en la tabla: solo dos de los siete viajan en los dos sentidos. El consentimiento y el resultado. Son justo los dos que casi nunca se devuelven al sistema de origen, y por eso la ficha del cliente envejece mal aunque la integración esté viva.

Sólo dos de los siete vuelven al sistema de origen. Son los dos que deciden si la ficha del cliente mejora con cada conversación o se queda como estaba.

Esta es la decisión que más discusiones evita y la que casi nunca se escribe. Cuando dos sistemas pueden modificar el mismo campo, uno tiene que ganar siempre, y eso se decide antes, no cuando aparece el conflicto a las tres semanas.

La regla que funciona en tiendas es simple: manda el sistema donde el dato nace. El pedido manda el ecommerce. El precio manda el catálogo. El estado de entrega manda el transportista. Y el consentimiento manda la plataforma de datos, porque es la única que lo ve entrar y salir por todos los canales a la vez.

El caso que rompe la regla es el nombre del cliente, porque lo toca todo el mundo: el checkout, el punto de venta, el propio cliente cuando lo corrige por chat. Ahí hay que elegir a mano y escribirlo. Si no, cada sincronización lo pisa y acabas mandando mensajes con tres versiones distintas del mismo nombre.

Hay una segunda regla que se olvida y que en ecommerce vale oro: cada handler tiene que ser idempotente. Si el mismo evento llega dos veces, el resultado tiene que ser el mismo que si hubiera llegado una. Sin eso, un reintento normal del ecommerce se convierte en un cliente duplicado o en dos avisos de envío para el mismo paquete.

Esa capa de decisión es la que resuelve un CDP y es lo que separa una integración de un montón de conexiones sueltas. Es el mismo problema que aparece al juntar marketing automatizado con un CRM unificado: sin una fuente de verdad declarada, las dos herramientas se corrigen entre ellas y ninguna gana.

Cinco de los seis tienen dueño evidente. El nombre no lo tiene, y por eso es el que acaba escrito de tres formas distintas si nadie decide antes.

¿Por qué los eventos no siempre llegan, y qué se hace al respecto?

Esta es la parte que casi ningún artículo sobre integraciones de WhatsApp menciona, y es la que más silenciosamente falla.

Un aviso de pedido no llega porque tu ecommerce lo mande. Llega si tu endpoint estaba levantado, si respondió a tiempo, si nadie desplegó nada en ese minuto y si la red se portó. La documentación de Shopify sobre webhooks lo dice sin adornos: «Your app shouldn’t rely on receiving data from Shopify webhooks. Webhook delivery isn’t guaranteed», y recomienda explícitamente «use reconciliation jobs to periodically fetch data» para mantener la consistencia.

Traducido a una tienda: además de escuchar eventos, hay que preguntar. Un proceso que cada cierto tiempo compare los pedidos de las últimas horas contra los avisos que salieron y rellene los huecos.

Sin eso, el día que la integración tenga 20 minutos malos, unos cuantos cientos de clientes se quedan sin su aviso de envío y nadie se entera, porque un evento que no llegó no deja rastro en ningún sitio. No hay error, no hay alerta, no hay fila roja en un panel. Hay silencio, y el silencio se parece mucho a que todo va bien.

Ese es también el motivo por el que conviene tratar la integración como una máquina de estados y no como un botón que funciona: cada pedido está en un estado, cada estado tiene los avisos que le corresponden, y la conciliación comprueba que el estado y los avisos cuadran. Es más trabajo al montarlo y es lo único que permite responder a la pregunta incómoda de «¿cuántos avisos se perdieron el mes pasado?» con un número en vez de con un encogimiento de hombros.

La conciliación no es una optimización. Es lo único que convierte «creo que no se perdió nada» en un número que se puede enseñar.

¿Cómo se evita que el mismo comprador acabe siendo tres fichas?

En retail esto pasa siempre, y no por descuido: pasa porque el mismo comprador entra por puertas distintas.

Compra como invitado con un correo. Vuelve dos semanas después y se registra con otro. Escribe a WhatsApp desde el número de su pareja. Y en la tienda física da un teléfono sin lada. Cuatro entradas y, si nadie decide qué las une, cuatro fichas y cuatro historiales.

La regla de unión tiene que estar escrita antes de abrir el canal. En México conviene ser explícito con el teléfono, porque es donde más se duplica: mismo país, mismos 10 dígitos, con o sin el 52 delante y con o sin el 1 histórico que todavía arrastran muchas bases. Un número guardado de dos formas distintas es la causa más común de ficha duplicada y también la más barata de arreglar si se decide al principio.

Y hay que decidir además el orden de prioridad cuando dos entradas se contradicen. Si el teléfono del checkout y el del punto de venta no coinciden, ¿cuál se queda? No hay una respuesta universal, hay que elegir una y respetarla.

Cuando la tienda vive en dos mundos, el de piso y el de línea, el problema se dobla. Es lo que trabaja una estrategia de clicks to bricks: si el perfil no sobrevive al salto entre canales, la conversación empieza de cero cada vez y el cliente lo nota antes que tú.

La regla de unión no se descubre, se declara. Si no está escrita antes de abrir el canal, cada entrada nueva crea una ficha y el historial deja de servir para nada.

Este video no va de WhatsApp: va de la conexión que hay debajo. Si tu tienda corre sobre Shopify, enseña en dos minutos por dónde entran el catálogo, el carrito y el pedido a la capa de datos, que es justo lo que tiene que existir antes de que la regla de unión y la conciliación de esta sección puedan hacer su trabajo.

Aquí es donde las integraciones se vuelven molestas. La tentación es mandar un mensaje en cada cambio de estado, y el resultado es que el cliente silencia el número.

Los eventos que justifican un mensaje son los que cambian lo que el cliente tiene que hacer o esperar: pedido confirmado, pago rechazado, envío en camino, entrega hoy, devolución recibida, reembolso aplicado. Seis.

Los que no lo justifican son los internos: cambio de almacén, reasignación de transportista, actualización de inventario, cambio de estado administrativo. Al cliente no le cambian nada y a ti te cuestan reputación de número.

Y hay dos que no dependen del evento sino del permiso: la recuperación de carrito y el aviso de reposición. Las dos son marketing, las dos necesitan consentimiento explícito y las dos se pagan. La recuperación de carritos abandonados funciona muy bien por este canal, y es también la que más rápido quema un número cuando se manda a quien no lo pidió.

Una regla práctica que ahorra discusiones: si el mensaje no cabe en la frase «te escribo porque algo de tu pedido cambió», no es un evento de servicio y necesita permiso.

Y conviene que esos eventos vivan dentro de un recorrido y no sueltos, porque un evento aislado no sabe qué pasó antes.

«Indigitall facilita la gestión de campañas omnicanal, unificando perfiles de clientes y automatizando procesos. Su integración con CRM y herramientas de personalización son destacables.» — Alessandra A. en G2

Alessandra A. nombra las tres piezas en el orden en que hay que montarlas: perfil unificado primero, integración con el CRM después, automatización al final.

Que el evento esté dentro de un recorrido es lo que permite decidir, por ejemplo, no mandar el aviso de envío por WhatsApp si el cliente ya lo recibió por push hace diez minutos.

La línea entre utilidad y marketing no la dibujas tú

Aquí hay algo que conviene saber antes de diseñar las plantillas, porque cambia el costo y el permiso de golpe: la categoría de una plantilla la decide Meta, no tú, y la puede cambiar después de haberla aprobado.

Las guías de plantillas de Meta definen las tres categorías con cuidado. Las de utilidad «enable businesses to follow up on user actions or requests, since these messages are typically triggered by user actions». Las de marketing cubren «a wide range of goals, from generating awareness to driving sales and retargeting customers». Y el sistema hace revisiones automáticas de las plantillas ya aprobadas para identificar las que deberían estar en otra categoría.

La consecuencia práctica es fea y es real: una plantilla que llevaba meses aprobada como utilidad puede pasar a marketing. El día que eso ocurre, el mismo mensaje que mandabas gratis empieza a costar, y además pasa a necesitar consentimiento de marketing para ser legítimo. Si tu operación tenía ese aviso dentro del flujo automático sin comprobar permiso, acabas mandando marketing a quien nunca lo aceptó sin haber cambiado ni una línea de código.

Para una integración eso significa dos cosas concretas. Una, que la comprobación de consentimiento tiene que estar en el flujo aunque el mensaje sea de utilidad, porque la categoría puede cambiar debajo. Y dos, que alguien tiene que mirar el estado de las plantillas de forma periódica, no solo cuando se crean.

Y una regla al escribirlas que reduce mucho el riesgo: una plantilla de utilidad habla del pedido del cliente y de nada más. En cuanto mete una recomendación, una promoción o un «aprovecha que», deja de parecer utilidad, y con razón.

Dicho esto, tener las plantillas ordenadas es lo que hace que el mantenimiento sea llevadero y no un proyecto en sí mismo.

«La plataforma es intuitiva y estable, con soporte proactivo y buenos informes. Sin embargo, la integración con Salesforce Marketing Cloud podría simplificarse.» — Jessica M. en G2

Jessica M. señala dónde se complica una integración, y conviene leerla entera porque la segunda mitad es la que interesa aquí.

Esa segunda frase vale más que cualquier ficha de producto: la fricción de una integración no está en el canal, está en la pieza con la que tiene que hablar. Y esa pieza es distinta en cada tienda, así que es lo primero que hay que preguntar y lo último que aparece en una demo.

¿Qué viaja con la conversación cuando cambia de manos?

El paso de bot a persona es donde se pierde la mitad del valor de la integración, y se pierde por una razón concreta: la persona recibe la conversación sin lo que ya se dijo.

El traspaso tiene que llevar 4 cosas: el historial del hilo, el pedido del que se habla, el motivo por el que se escaló y el tiempo que el cliente lleva esperando. Si falta el cuarto, el agente no sabe si entra a una conversación tranquila o a una que ya se torció, y responde con el tono equivocado.

Tiene que funcionar además en los dos sentidos. Un chatbot con IA que solo sabe entregar conversaciones y no recogerlas obliga a que un humano cierre todas, incluidas las que terminaron solas. Y si la conversación empezó en chat web y siguió en WhatsApp, el contexto tiene que cruzar también ese salto: si no, para el cliente son dos conversaciones y para ti son dos costos.

Hay un detalle de diseño que no es técnico y decide mucho: cuándo se escala. Dos disparadores que funcionan y que conviene dejar escritos son que el cliente pida una persona de forma explícita, y que el bot falle dos veces seguidas en resolver lo mismo. Esperar a la tercera no mejora nada.

Sin el tiempo de espera el agente no sabe a qué conversación está entrando. Y sin la flecha de vuelta, cada conversación que resuelve el bot acaba ocupando igualmente a una persona.

Una marca de panadería tradicional fundada en 1931, con presencia nacional, montó su gestión de pedidos de ecommerce sobre WhatsApp con un modelo híbrido de bot y agente conectado al backend de su tienda en línea y a un contact center con CRM.

Las cifras publicadas de los primeros 15 meses dicen algo más interesante que «funcionó»:

• Más de 17.000 usuarios adoptaron el canal.
• Más de 57.000 conversaciones relacionadas con pedidos entre julio y octubre de 2024.
• 65% de las consultas resueltas por el bot.
• Resolución 40% más rápida que por soporte de correo.
• 77,3% de NPS.
• 30% de aumento en compras repetidas entre usuarios comprometidos.
• 92% de satisfacción entre usuarios mayores con acceso directo a agentes.

Ese último número es el que más enseña sobre integración, y es el que normalmente no se cuenta. El 65% que resuelve el bot y el 92% de los usuarios mayores que llegan directo a una persona son la misma decisión de diseño vista desde dos lados: el sistema sabe cuándo no debe insistir. Eso es una regla de escalado conectada a lo que se sabe del cliente, no una función del bot.

Y el 40% más rápido que el correo no viene de que WhatsApp sea más veloz. Viene de que la conversación llega con el pedido cargado, que es exactamente lo que no ocurre en una bandeja de correo.

La columna del medio es la que explica a las otras dos: automatizar mucho y saber cuándo no automatizar son la misma regla, y las dos dependen de lo que el sistema sabe del cliente.

¿Qué hay que probar antes de abrir el canal?

Seis pruebas, en este orden, y ninguna necesita clientes reales.

1. Compra normal. Pedido confirmado, envío, entrega. Los 3 avisos llegan una sola vez cada uno.
2. Cancelación. El cliente cancela después del aviso de envío. Comprobar que no le sigue llegando el seguimiento.
3. Devolución. Llega la devolución y se aplica el reembolso. Comprobar que ningún mensaje posterior dice «tu pedido va en camino».
4. Baja de consentimiento. El cliente pide dejar de recibir promociones. Aquí el número lo pones tú: decide de antemano en cuánto tiempo tiene que haber llegado esa baja a todos los sistemas, escríbelo como criterio de aceptación del proyecto y pruébalo contra ese número. Cinco minutos es un punto de partida razonable. Comprueba además que sí puede seguir recibiendo avisos de servicio.
5. Evento duplicado. Mandar el mismo evento dos veces a propósito. Si el cliente recibe dos avisos o se crea una ficha nueva, los handlers no son idempotentes.
6. Caída de sincronización. Apagar el endpoint 10 minutos durante una compra y comprobar que la conciliación recupera el aviso perdido.

Las dos últimas son las que casi nunca se prueban y las dos que más caro salen, porque son las únicas que hay que provocar a propósito: las otras cuatro ocurren solas en cualquier compra de prueba. Si tu proveedor no puede enseñarte cómo se comportan esas dos, todavía no tienes una integración: tienes una demo.

Las cuatro primeras se preparan para una demo. Las dos últimas hay que provocarlas, y son las que separan una integración de una demostración.

¿Quién la mantiene cuando cambie el catálogo?

Una integración de WhatsApp no se termina el día que se abre. Cambia el catálogo y las plantillas aprobadas dejan de encajar. Cambia el CRM y el campo que alimentaba la personalización pasa a llamarse distinto. Cambia una regla de negocio y el evento que abría conversación deja de dispararse. Y cambia la versión de una API, que es el que menos se ve venir.

Por eso la última decisión de la integración es quién revisa esas cuatro cosas y cada cuánto. Si la respuesta es «el que lo montó», tienes un problema en cuanto esa persona cambie de puesto.

Lo repetitivo sí se puede dejar montado, y ahí ayuda la automatización de flujos de trabajo. La revisión de plantillas contra catálogo sigue necesitando a alguien mirando, y conviene que tenga fecha en el calendario y no buena voluntad.

Para ver cómo encaja todo esto en la operación completa de una tienda, la página de retail y ecommerce y la de WhatsApp describen las dos capas por separado.

¿Cuánto tarda en estar lista una integración de WhatsApp en una tienda?

Depende mucho menos de la parte del canal que de cuántas de las 7 conexiones de datos ya existen. Si el CRM y el ecommerce ya se hablan, el canal se abre rápido. Si la integración es también la primera vez que esos dos sistemas se conectan, el canal es la parte corta del proyecto y el plazo lo marca la parte de datos.

¿Qué pasa si un evento de mi ecommerce no llega?

Que el cliente no recibe su aviso y nadie se entera, porque un evento que no llegó no deja rastro. La entrega no está garantizada, así que la integración necesita además un proceso de conciliación que compare periódicamente los pedidos contra los avisos enviados y rellene lo que falte.

¿Qué significa que un handler sea idempotente y por qué importa en una tienda?

Que si el mismo evento llega dos veces, el resultado es el mismo que si hubiera llegado una. Importa porque los reintentos son normales: sin idempotencia, un reintento produce dos avisos de envío para el mismo paquete o una ficha de cliente duplicada.

¿Se puede mandar una promoción a alguien que solo dio su número para recibir avisos de pedido?

No. Son dos permisos distintos y la categoría del mensaje lo refleja: el aviso de pedido es utilidad y la promoción es marketing. Mezclarlos es la vía más rápida a que el cliente bloquee el número.

¿Qué tiene que llevar el traspaso de un bot a un agente?

Cuatro cosas: el historial del hilo, el pedido del que se habla, el motivo del escalado y el tiempo que el cliente lleva esperando. Y tiene que funcionar también de vuelta, para que el bot pueda cerrar lo que se resolvió solo.

¿Hace falta un CDP para integrar WhatsApp?

Para mandar mensajes no. Para que la ficha del cliente sobreviva a cuatro puertas de entrada, para que el consentimiento valga en todos los canales y para que el resultado de la conversación vuelva al perfil, sí hace falta una capa que decida quién manda sobre cada dato. Se puede llamar de otra forma, pero el trabajo hay que hacerlo igual.

La hoja de media hora que decide el proyecto

Llena la tabla de los 7 datos con el nombre real de tus sistemas y marca cuáles ya están conectados. Se hace en media hora y te dice si tu proyecto es de canal o de datos, que es la diferencia entre 3 semanas y 3 meses.

Y haz una segunda cosa antes de firmar: pídele a tu proveedor que te enseñe las pruebas 5 y 6 funcionando, el evento duplicado y la caída de sincronización. No la documentación: la prueba. Si existe, el resto de la integración probablemente también.

Si quieres ordenar primero la atención y dejar la parte de venta para después, el punto de partida está en cómo mejorar la atención al cliente con la API de WhatsApp Business, y si lo que buscas es que la conversación alimente el ciclo completo, el caso de uso de ciclo de vida del cliente explica dónde encaja cada canal.

Sobre los autores