Seguimiento de pedidos y carritos abandonados por WhatsApp

Avisar del despacho de un pedido y recordarle a alguien que dejó un carrito son, desde la interfaz, el mismo mensaje. Desde las reglas de Meta son dos cosas distintas: el primero es utilidad e informa sobre una compra que el cliente ya hizo; el segundo es marketing y necesita consentimiento previo. Tratarlos igual es la razón más frecuente por la que una tienda termina con el número degradado.

Los dos usos que dan retorno

Vale la pena empezar por los avisos: no exigen consentimiento adicional más allá de la relación comercial, el cliente los agradece y son los que quitan carga a atención. La recuperación de carritos se añade después, cuando ya tienes una base con opt-in real.

Los avisos del ciclo del pedido

Cada cambio de estado es un mensaje, y todos nacen en tu tienda, no en la conversación:

Dos consideraciones prácticas:

• Casi siempre van con plantilla. El cliente compró en la web, no te escribió por WhatsApp: no hay ventana de 24 horas abierta. Cómo redactar esas plantillas para que Meta las apruebe está en plantillas que Meta aprueba.
• No avises de todo. Cuatro mensajes por pedido es el techo razonable. Una tienda que notifica cada micro-cambio de estado consigue que el cliente silencie el chat, y con él los avisos que sí importaban.

El último mensaje, el de entrega, tiene un beneficio secundario: abre la ventana si el cliente responde. Ahí es donde llegan los reclamos, y llegan a un canal donde tienes todo el contexto en lugar de a un formulario.

Conectar la tienda: la parte donde se duplican los mensajes

El aviso lo dispara tu sistema, y ahí aparece el problema clásico: tu código llama a la API, el mensaje se envía, la respuesta se pierde por un timeout y tu reintento manda el aviso otra vez. El cliente recibe dos veces "tu pedido salió a reparto" y deja de confiar en los avisos.

La protección es la cabecera Idempotency-Key con un valor derivado de la operación:

curl -X POST https://tudominio.com/api/public/v1/messages \
  -H "Authorization: Bearer fjc_live_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: pedido-4512-despacho" \
  -d '{"to": "+51987654321", "type": "text", "text": "Tu pedido 4512 salió a reparto"}'

pedido-4512-despacho identifica el aviso, no el intento: el reintento devuelve la respuesta original en lugar de enviar de nuevo. Un identificador aleatorio por intento no protege de nada, y usar solo pedido-4512 colisiona entre el aviso de pago y el de despacho. El detalle completo, junto con las otras dos vías de integración, está en integrar WhatsApp con tu sistema y en la documentación de la API pública.

"¿Dónde está mi pedido?"

Es la consulta más repetida de cualquier tienda, y la peor respuesta posible es un mensaje genérico pidiendo paciencia.

Se resuelve dentro de la conversación: el flujo pregunta el número de pedido, consulta tu sistema con un paso de llamada a API y responde con el estado real y la fecha estimada. Si el cliente no recuerda el número, el flujo puede buscar por su teléfono, que es el dato que ya tienes.

Cuando las preguntas se vuelven variadas —"¿me llegó el pago de ayer?", "¿cuánto me falta para el envío gratis?"— el flujo determinista se queda corto y conviene un agente de IA con una herramienta que consulte tu sistema. El criterio para decidir entre lo determinista y lo generativo está en flujos, IA o los dos.

Recuperación de carritos, sin quemar el número

Aquí está el matiz que se salta casi todo el mundo: recuperar un carrito es marketing. No importa que el cliente estuviera a un clic de comprar; el mensaje busca vender, y eso implica dos requisitos.

• Consentimiento previo. El cliente tiene que haber aceptado recibir mensajes por WhatsApp, y ese consentimiento se pide en el checkout, con una casilla que no viene marcada por defecto y con texto que dice para qué es.
• Segmentación. Un carrito de hace tres semanas de alguien que nunca compró no es una oportunidad: es un bloqueo esperando. El envío se limita a carritos recientes de gente que interactuó.

Qué funciona sin degradar el número:

1. Uno solo, no una secuencia. Un mensaje a las pocas horas. La cadena de tres recordatorios convierte clientes en bloqueos.
2. Con la información que el cliente necesita, no solo el empujón: qué dejó, si sigue disponible, cuánto cuesta el envío.
3. A quien ya mostró interés. El nivel de interés de la conversación —que se calcula solo a partir de clics, mensajes y compras— es el mejor criterio de corte disponible.
4. Con salida fácil. Si el mensaje no facilita dejar de recibirlos, el cliente usa la única salida que tiene: bloquear tu número.

El pedido que llegó mal

Es el momento en que WhatsApp deja de ser un canal de avisos y se vuelve el sitio donde se salva o se pierde el cliente. Un producto equivocado o dañado llega como respuesta al aviso de entrega, y esa respuesta abre la ventana de 24 horas: puedes resolver con texto libre, fotos incluidas, sin costo de mensajería.

Lo que conviene tener preparado antes de que pase:

• Un flujo corto que recoja lo necesario: número de pedido, qué pasó y una foto. Con eso, quien atienda no tiene que pedir nada más.
• Derivación inmediata a una persona. Un reclamo no se resuelve con opciones predefinidas; el flujo solo recoge y pasa. Se pausa el bot en esa conversación y sigue alguien con el historial completo del pedido delante.
• Un límite de tiempo para responder dentro de la ventana. Si el reclamo entra un viernes por la noche y nadie lo mira hasta el lunes, la ventana se cerró y retomar cuesta una plantilla.

El detalle operativo que marca la diferencia: el historial de la conversación ya contiene los avisos de pago, despacho y entrega. Quien atiende ve la secuencia completa sin buscar en otro sistema.

Qué se puede automatizar y qué no

La regla que resume la tabla: automatiza lo que se puede responder consultando un dato; deriva lo que requiere decidir. Un bot que decide compensaciones acaba prometiendo lo que la tienda no va a cumplir.

Qué medir

• Bloqueos y bajas después de cada campaña. Es la señal temprana; si sube, la segmentación está mal.
• Consultas de estado que resuelve el flujo solo. Mide cuánta carga real le quitaste a atención.
• Avance del nivel de interés entre quienes reciben avisos. Distingue una relación de una lista de notificaciones.

No conviene comparar esos números con referencias de internet: dependen del ticket, del rubro y de cómo llegó la gente. Mide dos semanas, fija tu línea base y compárate contra ti mismo, como está explicado en las métricas que sí mueven la aguja.

Preguntas frecuentes

¿Necesito permiso para avisar del estado de un pedido?

Los avisos de utilidad sobre una compra que el cliente ya hizo forman parte de la relación comercial y son lo que el cliente espera. Aun así, conviene informar en el checkout de que recibirá los avisos por WhatsApp: reduce sorpresas y bloqueos. Lo que sí exige consentimiento explícito es lo promocional.

¿Puedo recuperar carritos de clientes que nunca me escribieron?

Solo si dieron su consentimiento para recibir mensajes por WhatsApp. Sin eso, es un contacto en frío con plantilla de marketing: la política no lo admite y la reacción de los usuarios degrada tu número.

¿Cuántos mensajes por pedido son demasiados?

Cuatro es un techo razonable: pago, despacho, en reparto y entrega. Más que eso empuja al cliente a silenciar la conversación, y entonces pierdes también los avisos importantes.

¿Puedo enviar plantillas desde la API?

En la versión actual el envío por API cubre mensajes de texto, y las plantillas se envían desde el dashboard, incluyendo la difusión a varios contactos. Para los avisos automáticos del ciclo del pedido, esa es la vía cuando la ventana está cerrada.

¿Qué pasa si el cliente responde a un aviso automático?

Su respuesta abre la ventana de 24 horas y la conversación entra a la bandeja como cualquier otra. Es una ventaja: el reclamo llega con el historial completo del pedido delante. Lo que hay que asegurar es que haya alguien atendiendo en el horario en que enviaste.