Si querés bajar consultas de “¿dónde está mi pedido?”, mandá el WhatsApp solo cuando la orden pase a “en reparto”. Esa es la regla que más pesa. El mensaje tiene que salir con el Nº de pedido, una franja horaria de 2 a 4 horas, el link de seguimiento y un canal de soporte. Nada de promos. Nada de horarios exactos.
Yo lo resumiría así:
Un dato simple: pasar de un horario exacto como 15:23 a una franja como 14:00 a 18:00 suele bajar fricción, porque en última milla el margen cambia mucho durante el día. Y poner un tope de 3 o 4 alertas por pedido ayuda a no saturar al cliente.
También hay un punto que no conviene pasar por alto: “despachado” no es lo mismo que “en reparto”. Si avisás antes, el cliente espera de más y el soporte lo siente.
Si yo tuviera que armar el setup base hoy, 14/08/2026, haría esto: unificar estados logísticos, validar teléfonos en E.164 con +54, usar una plantilla limpia de utilidad, sumar deduplicación e idempotencia, y conectar todo a una capa central como Burbuxa para no repetir reglas en cada tienda.
Ese es, en pocas palabras, el contenido del artículo.
Flujo de Alertas WhatsApp: Salida a Reparto Paso a Paso
Antes de definir la plantilla, resolvé tres cosas: el disparador, los datos y las reglas de envío. La alerta solo sirve si sale justo cuando el pedido de verdad está por llegar. Si la mandás antes, generás expectativa al pedo y más consultas al soporte con Shopify.
El disparador tiene que ser el cambio de estado a "en reparto", no un evento previo como "etiqueta creada". Si avisás demasiado temprano, el cliente queda esperando un paquete que todavía ni salió.
La fuente del disparador depende de cómo te entra el estado logístico. La mejor opción es el webhook que llega cuando el pedido pasa a estado "en reparto". Si trabajás con varios transportistas, te conviene usar un middleware para traducir los distintos códigos a un solo evento interno: "en_reparto". El mensaje tiene que salir en automático apenas cambia ese estado.
Con eso resuelto, toca definir qué datos va a usar el mensaje.
El mensaje necesita un grupo chico de campos. Meter demasiada información complica la plantilla y suma chances de error si algún dato viene vacío.
| Campo | Para qué sirve |
|---|---|
| Nombre de pila del cliente | Personalización básica ("Hola, Lucía") |
| Número de pedido | Identificación clara del envío |
| Link de seguimiento | Autogestión en ecommerce sin contactar soporte |
| Ventana horaria estimada | Expectativa concreta sobre cuándo llega |
También validá que el celular tenga código de país, formato internacional E.164 y que sea apto para WhatsApp. Y evitá usar horarios exactos del transportista: cambian seguido y suelen traer más ruido que ayuda.
Un mensaje como "tu pedido llega hoy entre las 14:00 y las 18:00" funciona mejor que "llega a las 15:23". En la última milla, ese nivel de precisión rara vez aguanta el paso del día. Por eso, usá una ventana de 2 a 4 horas.
Para Argentina, usá formato de 24 horas. Bloqueá envíos entre las 21:00 y las 08:00 hora local. Si el carrier marca el pedido como "en reparto" dentro de ese bloque, el sistema tiene que encolar el mensaje para la próxima franja permitida, o no enviarlo si la ventana de entrega ya pasó.
La deduplicación también pesa mucho. Guardá el último estado notificado y la hora de envío de cada pedido. Reenviá solo si cambia el estado operativo. Así evitás que el cliente reciba dos avisos por el mismo reparto.
Con el disparador, los datos y la ventana ya definidos, podés pasar a armar la plantilla aprobada.
Ahora toca pasar de la lógica al texto que suele aprobar Meta. La idea es simple: convertir esa lógica en una plantilla breve, transaccional y sin vueltas.
La plantilla tiene que incluir cinco piezas: estado del envío, referencia del pedido, franja estimada de entrega de hoy, enlace o botón de seguimiento y un canal de soporte. El cuerpo, además, debe ser corto, directo y solo informativo.
Un ejemplo funcional en es-AR es:
Hola {{1}}, tu envío del pedido Nº {{2}} ya está en reparto y se entrega hoy entre las {{3}} y las {{4}} hs. Podés seguir el envío acá: {{5}}. Si tenés algún problema con la entrega, respondé a este mensaje o contactanos en {{6}}.
Usá formato de 24 horas para la franja horaria, por ejemplo "entre las 14:00 y las 18:00 hs", y el término "Nº" para la referencia del pedido. También conviene evitar emojis y frases promocionales. Si la plantilla viene demasiado cargada, puede parecer un mensaje de marketing y eso complica la aprobación.
Cada variable tiene que apuntar a un dato real y estable del pedido. No uses placeholders genéricos como {{info}} o {{dato}}.
En una plantilla de reparto, una asignación práctica sería esta:
{{1}} = nombre del cliente{{2}} = número de pedido{{3}} y {{4}} = inicio y fin de la franja horaria{{5}} = URL de seguimiento{{6}} = contacto de soporteSi alguno de esos campos puede llegar vacío, te conviene tener una versión alternativa de la plantilla. Es mejor eso que enviar un mensaje incompleto.
Un motivo común de rechazo es mezclar promos con la alerta de envío. Si metés descuentos o frases de venta dentro de una plantilla de utilidad, pueden revisarla como marketing. Si querés hacer una oferta después de la entrega, usá otra plantilla. El aviso de salida a reparto tiene que hablar solo del envío.
Poné un tope de 3 o 4 alertas por pedido: confirmado, enviado, en reparto y entregado. No sumes mensajes extra por demoras o intentos fallidos; mejor agrupalos en un solo aviso.
Con la plantilla lista, conectala al evento de tu tienda. Después de eso, seguí con la integración en Shopify, Tiendanube o VTEX.
Ahora toca llevar esa plantilla al evento real de cada plataforma. Y acá hay un punto que suele traer problemas: cada plataforma dispara la alerta con eventos distintos.
En los tres casos, activá el envío solo cuando el estado ya sea visible para el cliente. Si mandás el mensaje antes, la experiencia se rompe.
En Shopify, el disparador más confiable es un webhook cuando el envío pasa a out_for_delivery o in_transit. Ese evento lo actualiza el transportista en tiempo real, no cuando se crea la etiqueta.
Antes de enviar, validá tracking_company, tracking_number y tracking_url. Si falta alguno, mandá el mensaje sin link antes que enviar una variable vacía. Queda mucho mejor un aviso simple que un WhatsApp roto.
También conviene normalizar el teléfono del cliente al formato E.164. Sacá espacios, guiones y ceros iniciales, y agregá +54 al principio. Por ejemplo, 011-1234-5678 pasa a +541112345678.
Tiendanube separa el estado del pedido (open, closed, cancelled) de los estados de envío (UNPACKED, PACKED, DISPATCHED, DELIVERED). Para la alerta de salida a reparto, el disparador correcto es el cambio a DISPATCHED o "En camino".
Usá order/packed o order/fulfilled, no order/updated. Así evitás procesar eventos que no corresponden a una notificación para el comprador.
Si tu integración usa tracking_info, desde ahí podés tomar tanto el código como la URL de seguimiento sin hacer llamadas extra a la API. En cambio, estados internos como "Preparando envío", "Picking" o "Armado de pedido" no deberían disparar ningún WhatsApp.
VTEX usa un modelo de estados interno bastante detallado. El evento que suele corresponder a "salida a reparto" es shipping o un estado personalizado que se configura cuando el operador logístico toma el paquete, no invoiced, que solo indica que la orden fue facturada.
Ese error aparece seguido: mapear invoiced como "en camino". ¿El resultado? El mensaje le llega al cliente antes de que el pedido salga del depósito.
La arquitectura recomendada es: Order Hook → cola de mensajes → envío a la API de WhatsApp. Para evitar duplicados, usá el ID de la orden junto con el tipo de evento como clave de idempotencia.
Si la API de WhatsApp falla, reintentá con backoff exponencial: 30 s, 2 min y 10 min. Pero cerrá la ventana de reintentos a las 2 horas. Después de ese punto, el mensaje ya llega tarde y pierde sentido.
Antes de encolar, convertí el estado interno en una frase natural en es-AR. El cliente tiene que leer "tu pedido ya salió a reparto", no shipping ni ready-for-handling.
Si manejás más de una tienda, conviene llevar la misma lógica en un solo lugar. Así no tenés que repetir reglas en cada plataforma. Burbuxa aplica en una sola capa lo que ya definiste: disparador, deduplicación, ventana horaria y plantilla. En la práctica, eso te deja una sola regla para todos los envíos.
La plataforma sincroniza en tiempo real el estado, el tracking y la fecha estimada desde tu tienda. Entonces, cuando el pedido pasa a "en reparto", el mensaje sale con los datos reales de esa compra, no con información vieja o cargada a mano.
También podés ajustar las plantillas a es-AR dentro de la misma plataforma. Eso incluye fecha en formato 14/08/2026, hora en 24 horas y un tono rioplatense que suena natural para clientes de Argentina.
Con la cuenta conectada, activá solo los eventos que ya definiste en la lógica anterior. La conexión se hace desde las app stores de Shopify y Tiendanube, y de forma nativa en VTEX.
Después, activá únicamente esos eventos y vinculalos con las plantillas aprobadas. Simple: menos desorden, menos chances de mandar mensajes que no corresponden.
Para medir el impacto, la capa de análisis de Burbuxa muestra:
Con esos datos, ajustás la operación antes del cierre.
Con el disparador, la plantilla y la frecuencia ya definidos, el setup mínimo viable queda bastante claro:
No hace falta llenar todo de reglas. Hace falta pocas reglas bien marcadas. El punto de partida es el disparador correcto: el cambio de estado a "en reparto", junto con la actualización del tracking del transportista. A eso le sumás solo datos confiables y al día: nombre del cliente, número de pedido, tracking y ventana estimada de entrega. Mientras menos variables dudosas metas, menos chances tenés de confundir al comprador.
La plantilla aprobada en es-AR tiene que ser transaccional, neutral y sin tono promocional. En la mayoría de los casos, una sola alerta principal por pedido - con una confirmación de entrega opcional - alcanza. Y si la franja horaria es honesta y se comunica en formato de 24 horas, bajás el riesgo de prometer de más.
La adaptación por plataforma mantiene la misma lógica. En Shopify, se trabaja con eventos de fulfillment y señales del transportista. En Tiendanube, con cambios de estado como En camino y los campos de tracking. Y en VTEX, con eventos de logística del OMS o de la integración de órdenes. Cambia el origen del dato, pero no la estructura del mensaje. Si además sumás horarios de silencio y reglas de deduplicación, evitás mensajes repetidos o fuera de hora.
Con esa configuración, la alerta cumple su meta principal: menos consultas al soporte sobre dónde está el pedido, sin sumar ruido.
Si el carrier no informa a tiempo el estado en reparto, el flujo automático de Burbuxa no se adelanta ni manda avisos por su cuenta. Espera la actualización real desde tu plataforma para sincronizarse.
Como monitorea los estados del pedido en tiempo real, no se envía una notificación incorrecta al cliente.
Mientras tanto, tu equipo puede ver el estado al día en la bandeja unificada de Burbuxa, y la IA responde según la información de seguimiento más reciente disponible.
Si un cliente pregunta por su pedido y no tiene el link de seguimiento a mano, Burbuxa lo resuelve en el acto. Como se conecta directo con tu tienda, puede ver en tiempo real el estado actualizado de cada compra.
Cuando el cliente escribe por WhatsApp, la IA detecta cuál es el pedido activo y comparte de forma automática el estado de la entrega. Y si hace falta que intervenga una persona, tu equipo entra con todo el contexto desde la bandeja unificada.
Si un cliente tiene mal cargado su número de WhatsApp, Burbuxa concentra todo en una bandeja unificada. Y como está conectada con tu ecommerce, podés ver al instante su perfil, el historial de compras y los datos de contacto.
Si aparece un error, tu equipo puede corregirlo desde el CRM o pasar la conversación a un agente humano. Lo bueno es que ese agente recibe todo el contexto para revisar la información y actualizar el número sin arrancar de cero.